home *** CD-ROM | disk | FTP | other *** search
/ Simtel MSDOS 1993 May / SIMTEL_0593.ISO / msdos / fido / ftsc_all.z43 / FSC-0039.001 < prev    next >
Text File  |  1990-02-22  |  15KB  |  310 lines
  1. Document: FSC-0039
  2. Version:  001
  3. Date:     02/22/90
  4.  
  5.  
  6.  
  7.                     A Type-2 Packet Extension Proposal
  8.                              Mark A. Howard
  9.                            1:260/340@FidoNet
  10.  
  11.  
  12.  
  13.     Information:
  14.         
  15.         The purpose of this FSC is to focus discussion on particular
  16.         problems in Fidonet(r) and possible methods of solution.
  17.         No proposed solutions in this document are intended as
  18.         standards for Fidonet.  Rather, it is hoped that a general
  19.         consensus will emerge as to the appropriate solution to such
  20.         problems, leading eventually to the adoption of standards.
  21.         Distribution of this document is unlimited.
  22.  
  23.  
  24.  
  25. Introduction
  26. ------------
  27. This document serves two major purposes.  The first is an attempt to define
  28. and document the Type-2 packet which is widely in use in FidoNet today.
  29. Although FTS-0001 defines the structure of a Type-2 packet, the natural
  30. evolution of our network, mostly with regards to addressing methodology,
  31. has made it necessary to utilize hitherto unused portions of the header
  32. to insert Zone and Point information.  Also, it has become apparent that
  33. some of the existing fields are not large enough to accomplish their
  34. original tasks.
  35.  
  36. The second is to propose a simple mechanism to allow FidoNet to begin to
  37. utilize advanced mail packing techniques.  It is quite apparent that while
  38. Type-2 has served us faithfully for some time now, the evolution of our
  39. network in terms of technical and physical complexity has caused us to
  40. consider more efficient and functional ways to pack mail.
  41.  
  42.  
  43. The Type-2 Header (Where's the Zone?)
  44. -------------------------------------
  45. Because no attempt has been made to update FTS-0001, at least two different
  46. methods for inserting the zone information have been adopted, making it
  47. necessary to provide support for both formats in all of the zone aware mail
  48. processors.  The end result is more code, and redundant information in the
  49. packet header.
  50.  
  51. This has presented a problem in logistics, as it is difficult to consider
  52. the project of updating mail processors using one type to use the other.
  53. As sufficient indentification is provided, in the form of the product code,
  54. to determine the expected location of the zone information, and because
  55. code already exists in most of the mail processors to overcome this, this
  56. proposal does not attempt to suggest that one method be used over the
  57. other, rather the intent is to attempt to document the extensions in use,
  58. and the products involved.
  59.  
  60. See the accompanying chart and cross-reference.
  61.  
  62.  
  63. The Product Code
  64. ----------------
  65. Based upon the current rate of requests for product codes from the FTSC,
  66. it is probable that the Product Code byte will not be large enough to
  67. accomodate all of the codes required.  While it is not reasonable to
  68. expect that all Type-2 processors will eventually check the hi-order byte
  69. proposed here, it is likely that 'current' mail processors will.  This
  70. can be nothing but benefical, as it will force users to upgrade their
  71. mail processors to a product which will as a minimum, support Type-2
  72. with Zone and Point extensions, and quite possibly, processors that will
  73. utilize more advanced mail packing techniques, making Type-2 extinct once
  74. and for all.
  75.  
  76.  
  77. The Capability Word  (How do we GET there from here?)
  78. -----------------------------------------------------
  79. Everybody would like to see more efficient and functional ways to pack and
  80. exchange mail.  Several Type-3 message bundle proposals exist, but none
  81. really address a problem which must be solved first.  The problem is that
  82. since FidoNet is a hobbyist network, no demands can be placed on any one
  83. sysop to upgrade or change their bundling software.  Because of this, it
  84. is necessary to consider strategies which allow for the existence of Type-2
  85. bundlers in the network topology.
  86.  
  87. Considerable advantages can be realized, however, between systems that
  88. consent to use advanced bundling techniques.  One way to do this is to
  89. simply send netmail to all of your connecting systems, saying "Hey, I've
  90. got a Type-3 bundler now, how about you?"  This could become quite
  91. tiresome, and does not represent much of an improvement on the current
  92. situation.
  93.  
  94. What would be desirable is a network that would 'upgrade itself'.  Given a
  95. situation where mail processors of various capabilities will exist in a
  96. network topology, the goal is to provide a mechanism whereby two links can
  97. determine and utilize the most efficient bundling method to use, in a
  98. manner transparent to the sysop.
  99.  
  100. For instance, let's say that the FTSC releases the Type-7 All New Singing
  101. and Dancing bundle format.  Well, your current version of SlingToss can
  102. only support Types 2, 3, and 5.  One of your downlinks gets a new version
  103. of MailMangle which can support Types 2, 3, 4, and 7.  Well, it is quite
  104. obvious that since you and he are exchanging 4 megs of mail each night,
  105. and it's an overseas call, that it would be in your interest to obtain a
  106. new version of SlingToss which can support Type 7.
  107.  
  108. Note that this is *optional*.  Because both processors can support Type-3,
  109. they will continue to exchange Type-3 mail quite happily, even though
  110. MailMangle is happily advertising the availability of Type-7.  Even your
  111. downlinks which are still using stone-age Type-2 processors will be fine,
  112. as SlingToss will always export Type-2 bundles when no higher capability
  113. can be determined.
  114.  
  115. So, after dashing off the check to the author, your new version of
  116. SlingToss comes in the mail!  You rush over to your system, and install it.
  117. The next time SlingToss exports mail to the MailMangle system, it says
  118. "Hey!  I can now support Type 2, 3, 5, and 7!  So, whattya got?"  This is
  119. no skin off MailMangle's nose, he's had Type-7 for quite a while, and he
  120. begins to export Type-7 bundles to SlingToss.  "It's about time.", he says.
  121.  
  122. Now, this scenario is made possible by implementing a 'Capability Word' in
  123. the present and future packet headers.  The Capability Update mechanism
  124. depends on several assumptions:
  125.  
  126. 1) Any Advanced Capability Bundler *MUST* be capable of receiving and
  127.    faithfully processing Type-2 bundles.  Hopefully, the inbound packets
  128.    will be in the new format proposed by this document, but then again,
  129.    this is not an exact science.  What this means is that it is likely
  130.    that some packets may arrive with the Capability Word (CW) set to 0.
  131.    In this case, Type-2 is assumed, assuring compatibility.  The only
  132.    caveat is that it is conceivable that some obscure mail processor
  133.    uses the location proposed for the CW for other arcane purposes.  In
  134.    this event, it is quite likely that you will be receiving netmail from
  135.    this node soon, at which time you can configure your Advanced
  136.    Capability Bundler to unconditionally send a Type-2 bundle to this
  137.    node.
  138.  
  139. 2) An Advanced Capability Bundler, hereafter referred to as a Type-N
  140.    Bundler, must have a method to store and maintain the node-by-node
  141.    capability information.  This can be done many ways, and in fact
  142.    several processors already have begun to maintain node information
  143.    outside of that found in AREAS.BBS, mostly to implement pre-arranged
  144.    alternate compression methods.  In a text configuration file, you
  145.    might see the following:
  146.  
  147.    ;       Address      Comp    Send  LastCW ; Comments
  148.    Node    1:260/340    ZIP     Auto  7      ; Auto detect & upgrade
  149.    Node    1:135/20     LZH     3     2,3,7  ; Always send Type-3
  150.    Node    1:           ARC     2     0      ; Stone-Age processor
  151.    Node    1:135/4      ---     Auto  7      ; Sent me netmail
  152.    Node    1:           ---     0     0      ; Don't send CW
  153.  
  154.    In this example, the fields are:
  155.  
  156.    Address - downlink address.  Note that this is not necessarily
  157.              relative to echomail, only, it is possible to append
  158.              information to the node database as netmail packets are
  159.              receieved from different addresses.
  160.  
  161.    Comp    - desired mail compression method.
  162.  
  163.    Send    - Auto - automatically determined maximum common packing
  164.                     method to use.  Automatically update to LastCW
  165.                     when packing.
  166.  
  167.    LastCW  - Last CW received from remote system.
  168.  
  169.  
  170. 3) A Type-N Bundle will always advertise it's capabilities in the CW
  171.    regardless of the type being sent.  As shown in the above example,
  172.    it allows Type-N processors to automatically track the capability
  173.    of your system.  Again, in cases where a stone-age processor is
  174.    being used, this field will be ignored, and in the unusual event
  175.    that it is not ignored, and is somehow harmful to the far system,
  176.    the Type-N processor can be configured to send a CW of 0.
  177.  
  178. The format of the Capability Word is designed to support up to 15 future
  179. bundle types, and is bit-mapped to facilitate the easy determination of
  180. the maximum common level supported between two nodes:
  181.  
  182.                msb           Capability Word               lsb
  183. Node Supports  ------------FTSC Type Supported----------------
  184.  
  185.                 * 16 15 14 13 12 11 10  9  8  7  6  5  4  3  2
  186.  
  187. 2, 3, and 7     0  0  0  0  0  0  0  0  0  0  1  0  0  0  1  1
  188. 2, 3, and 5     0  0  0  0  0  0  0  0  0  0  0  0  1  0  1  1
  189. 2 (this FSC)    0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  1
  190. Stone Age       0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
  191.  
  192.                 * - reserved for future use
  193.  
  194. In this example, the Type-N bundler would AND the two words, obtaining a
  195. word expressing the Types which are in common to both systems.  The most
  196. significant Type will be used, by default, but note that this assumes that
  197. new bundling Types will be increasingly more efficient or in some way more
  198. beneficial.  Because this may not always be the case, there should be a
  199. method provided, as illustrated above, to override the automatic upgrade
  200. should this become the case.
  201.  
  202. It might seem somewhat limiting to only consider the possibility of 15
  203. different future bundling methods, but it is my opinion that the careful
  204. use of a 'Sub-Type' byte in the packet header can allow for the variations
  205. on a single theme, and that proposals for new formats should be evaluated
  206. by the FTSC to determine whether sufficient benefit can be realized in
  207. the implementation of the given format, prior to assigning a new type
  208. code.
  209.  
  210.  
  211. Mailers
  212. -------
  213. It is quite clear to me that should this concept take hold, that the
  214. logical place to store node capability data is in the local nodelist
  215. database, or an index-associated data file.  As above, it is necessary
  216. to generate Type-2 packets for whatever purpose, unless it is known
  217. by prior association, that the far mailer can accept other types of
  218. packets.  It is also quite reasonable to assume that a nodelist flag
  219. could be assigned to advertise the CW for a given node, which the
  220. native mailer nodelist compiler could then immediately determine the
  221. preferred bundling method for any given node in FidoNet.
  222.  
  223. The approach suggested previously in this document suggests the use of
  224. a text configuration file, but it is quite obvious that many benefits
  225. can be realized through the use of the nodelist, including the use of
  226. additional flags to indicate the preferred compression method, etc.
  227.  
  228.  
  229. Summary
  230. -------
  231. This document has been created in an attempt to define a method to allow
  232. the future expansion and enhancement of FidoNet technology mail processors
  233. and mailers, and in a way that is the least disruptive to existing mail
  234. operations.  The intent is to provide for an environment that is as open,
  235. and extensible as possible.
  236.  
  237. The mechanism described should allow many different types of processors
  238. (FTSC-registered) to exist in the network at once, and to provide an
  239. environment which is designed to operate at it's maximum efficiency
  240. wherever possible or practical.
  241.  
  242.  
  243. Thanks
  244. ------
  245. To Ward Christensen, creator of XModem and BYE.
  246.  
  247.    Tom Jennings, who started this whole mess.
  248.  
  249.    Joaquim Homrighausen, for lots of good ideas, and motivation.  Here's
  250.                          another Lamborghini to work on.
  251.  
  252.    Wynn Wagner, Oliver McDonald, Roeland Meyer, Andrew Farmer, Claude
  253.    Warren, Jan Vroonhof, Bob Hartman, and Vince Perriello, who all
  254.    contributed in some way to the creation of this document, mostly
  255.    through their messages in NET_DEV.
  256.  
  257.  
  258.  
  259. Type-2 Packet Format (proposed, but currently in use)
  260. -----------------------------------------------------
  261.   Field    Ofs Siz Type  Description                Expected value(s)
  262.   -------  --- --- ----  -------------------------- -----------------
  263.   OrgNode  0x0   2 Word  Origination node address   0-65535
  264.   DstNode    2   2 Word  Destination node address   1-65535
  265.   Year       4   2  Int  Year packet generated      19??-2???
  266.   Month      6   2  Int  Month  "        "          0-11 (0=Jan)
  267.   Day        8   2  Int  Day    "        "          1-31
  268.   Hour       A   2  Int  Hour   "        "          0-23
  269.   Min        C   2  Int  Minute "        "          0-59
  270.   Sec        E   2  Int  Second "        "          0-59
  271.   Baud      10   2  Int  Baud Rate (not in use)     ????
  272.   PktVer    12   2  Int  Packet Version             Always 2
  273.   OrgNet    14   2 Word  Origination net address    1-65535
  274.   DstNet    16   2 Word  Destination net address    1-65535
  275.   PrdCodL   18   1 Byte  FTSC Product Code     (lo) 1-255
  276. * PVMajor   19   1 Byte  FTSC Product Rev   (major) 1-255
  277.   Password  1A   8 Char  Packet password            A-Z,0-9
  278. * QOrgZone  22   2  Int  Orig Zone (ZMailQ,QMail)   1-65535
  279. * QDstZone  24   2  Int  Dest Zone (ZMailQ,QMail)   1-65535
  280.   Filler    26   4 Byte  Spare Change               ?
  281. * PrdCodH   2A   1 Byte  FTSC Product Code     (hi) 1-255
  282. * PVMinor   2B   1 Byte  FTSC Product Rev   (minor) 1-255
  283. * CapWord   2C   2 Word  Capability Word            BitField
  284. * OrigZone  2E   2  Int  Origination Zone           1-65535
  285. * DestZone  30   2  Int  Destination Zone           1-65535
  286. * OrigPoint 32   2  Int  Origination Point          1-65535
  287. * DestPoint 34   2  Int  Destination Point          1-65535
  288. * ProdData  36   4 Long  Product-specific data      Whatever
  289.   PktTerm   3A   2 Word  Packet terminator          0000
  290.  
  291. * - extensions to FTS-0001
  292.  
  293. Ofs, Siz are in hex, other values are decimal.
  294.  
  295.  
  296. Zone/Point Aware Mail Processors (probably a partial list)
  297. ----------------------------------------------------------
  298.   Prod
  299.   Code Name - Uses QOrg/QDstZone Orig/DestZone Orig/DestPoint
  300.   ---- ----------- ------------- ------------- --------------
  301.   0x0C  FrontDoor  Reads/Updates      Yes           Yes
  302.   0x1A  DBridge        ?????          Yes           Yes
  303.   0x23  XRS        Reads/Updates      Yes           Yes
  304.   0x29  QMail           Yes          ?????      Not point-aware
  305.   0x35  ZMailQ          Yes          ?????      Not point-aware
  306.   0x3F  TosScan    Reads/Updates      Yes           Yes
  307.  
  308.  
  309.  
  310.