diff --git a/html/ftsc/fsc-0035.html b/html/ftsc/fsc-0035.html
index f8999636..238e765c 100755
--- a/html/ftsc/fsc-0035.html
+++ b/html/ftsc/fsc-0035.html
@@ -1,79 +1,80 @@
-
-
-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.
-
-
- Go Back
-
-
-
-
+
+
+
+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.
+
-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
-
-
-
-
-
-
+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
+
+
+
+
+
+
+
+Go Back
+
+
+
+
diff --git a/html/ftsc/fsc-0046.html b/html/ftsc/fsc-0046.html
index 09688a5d..242cc3c6 100755
--- a/html/ftsc/fsc-0046.html
+++ b/html/ftsc/fsc-0046.html
@@ -1,227 +1,228 @@
-
-
-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" ---
-
-
- Go Back
-
-
-
-
+
+
+
+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" ---
+
+
+ Go Back
+
+
+
+
diff --git a/html/ftsc/fsc-0048.html b/html/ftsc/fsc-0048.html
index c43b8505..ae541cd0 100755
--- a/html/ftsc/fsc-0048.html
+++ b/html/ftsc/fsc-0048.html
@@ -1,417 +1,418 @@
-
-
-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)
-
-
+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)
+
+
+
+Go Back
+
+
+
+
diff --git a/html/ftsc/fsc-0049.html b/html/ftsc/fsc-0049.html
index d4787917..29152754 100755
--- a/html/ftsc/fsc-0049.html
+++ b/html/ftsc/fsc-0049.html
@@ -1,103 +1,104 @@
-
-
-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.
-
-
- Go Back
-
-
-
-
+
+
+
+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.
+
+
+Go Back
+
+
+
+
diff --git a/html/ftsc/fsc-0050.html b/html/ftsc/fsc-0050.html
index a1a7cb0e..d4671104 100755
--- a/html/ftsc/fsc-0050.html
+++ b/html/ftsc/fsc-0050.html
@@ -1,98 +1,99 @@
-
-
-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:
-
- 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
-
-
- Go Back
-
-
-
-
+
+
+
+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
+
+
+Go Back
+
+
+
+
diff --git a/html/ftsc/fsc-0053.html b/html/ftsc/fsc-0053.html
index fe764e7a..0c5419ad 100755
--- a/html/ftsc/fsc-0053.html
+++ b/html/ftsc/fsc-0053.html
@@ -1,187 +1,188 @@
-
-
-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 (^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.
-
-
- Go Back
-
-
-
-
-
+
+
+
+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.
+
-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 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 : 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 . In step 3, the Calling system does not terminate
- sequences with as it is explicitly transmitted after possible
- protocol start characters. In step 4, the Calling system once again
- terminate all sequences with a .
-
-
- STEP 2A, RECEIVE EMSI HANDSHAKE
-
- At this point, all sequences are terminated with a .
-
- +-+------------------------------------------------------------------+
- :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 .
-
- +-+------------------------------------------------------------------+
- :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
- ---------------------------------------------------------------------
- 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
- ---------------------------------------------------------------------
- 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
- ---------------------------------------------------------------------
- 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
- ---------------------------------------------------------------------
- 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
- ---------------------------------------------------------------------
- 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
- excluding the CRC and terminating .
-
- 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 and fields to prevent
- accidental EMSI_NAK sequences, etc.
-
-
- =====================================================================
- EMSI ACK **EMSI_ACK
- ---------------------------------------------------------------------
- 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
- ---------------------------------------------------------------------
- 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-.
-
- 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
- ---------------------------------------------------------------------
- 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
- ---------------------------------------------------------------------
- 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
- ---------------------------------------------------------------------
- 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
- ---------------------------------------------------------------------
- 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
- ---------------------------------------------------------------------
- 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
- ---------------------------------------------------------------------
- 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
- ---------------------------------------------------------------------
- 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
- ---------------------------------------------------------------------
- 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
- ---------------------------------------------------------------------
- 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 .
-
- (*) 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 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.
-
-
- Go Back
-
-
-
-
+
+
+
+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
+ ---------------------------------------------------------------------
+ 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
+ ---------------------------------------------------------------------
+ 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
+ ---------------------------------------------------------------------
+ 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
+ ---------------------------------------------------------------------
+ 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
+ ---------------------------------------------------------------------
+ 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
+ excluding the CRC and terminating .
+
+ 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 and fields to prevent
+ accidental EMSI_NAK sequences, etc.
+
+
+ =====================================================================
+ EMSI ACK **EMSI_ACK
+ ---------------------------------------------------------------------
+ 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
+ ---------------------------------------------------------------------
+ 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-.
+
+ 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
+ ---------------------------------------------------------------------
+ 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
+ ---------------------------------------------------------------------
+ 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
+ ---------------------------------------------------------------------
+ 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
+ ---------------------------------------------------------------------
+ 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
+ ---------------------------------------------------------------------
+ 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
+ ---------------------------------------------------------------------
+ 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><lt;crc32><lt;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.
+
-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=]
-
- 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[=]
-
- 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
-
- where 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[=]
-
- 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, [=]
-
- 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
-
- where 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
-
- 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 */
- 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 ,
-
- 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 Simulate request from another system
- %RESCAN Rescan conferences linked in current request
- %COMPRESS Change compression method
- %PWD Change ConfMgr password
- %PAUSE Suspend link
- %RESUME Resume link
- %RECEIPT , 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.
-
-
-
- Go Back
-
-
-
-
+
+
+
+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.
+
+
-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 ". 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
-
- 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:
-
- ">
-
- In order to conform to RFC-822, the Message-ID must have the format:
-
-
-
- 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
-
-
- 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 []
- sendme []
-
- 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 [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
-
- 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 .) 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]
-
- Go Back
-
-
-
-
+
+
+
+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]
+
+Go Back
+
+
+
+
diff --git a/html/ftsc/fsc-0062.html b/html/ftsc/fsc-0062.html
index aacd685a..3fe3fecf 100755
--- a/html/ftsc/fsc-0062.html
+++ b/html/ftsc/fsc-0062.html
@@ -1,363 +1,364 @@
-
-
-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
-
-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.
-
-
- Go Back
-
-
-
-
+
+
+
+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.
+
-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 (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:
-
- (Fido) ^MSGID: "LZKkoe$1982 98a" 45678bcd
- to (Usenet) Message-ID: <-LZKkoe-1982-98a--45678bcd@fidonet.org>
-
-
-
-
- Go Back
-
-
-
-
+
+
+
+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>
+
+
+
-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 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 and characters.
- TLN Escape the @ 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 : (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
-
-
-
- Go Back
-
-
-
-
+
+
+
+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
+
+
- | 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-
-
-
- Go Back
-
-
-
-
+
+
+
+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-
+
+
+Go Back
+
+
+
+
diff --git a/html/ftsc/fsc-0088.html b/html/ftsc/fsc-0088.html
index 8231eaf1..8aedda87 100755
--- a/html/ftsc/fsc-0088.html
+++ b/html/ftsc/fsc-0088.html
@@ -1,326 +1,327 @@
-
-
-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
-
-
- Go Back
-
-
-
-
+
+
+
+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
+
- | 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
-
-
-
- Go Back
-
-
-
-
+
+
+
+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
+
+
+
+Go Back
+
+
+
+
diff --git a/html/ftsc/fsc-0092.html b/html/ftsc/fsc-0092.html
index 74462c06..2ba446e2 100755
--- a/html/ftsc/fsc-0092.html
+++ b/html/ftsc/fsc-0092.html
@@ -1,243 +1,244 @@
-
-
-New control lines for forwarded messages.
-
-
-
-
-
- | Document: FSC-0092
- | Version: 001
- | Date: September 12th 1996
- | Author: Michael Hohner
-
-
- New control lines
- for forwarded messages
-
- by
- Michael Hohner
- 2:2490/2520.17
-
- September 1996
-
- Status of this document:
-
- This document proposes a standard for the Fidonet(tm) community
- and for other networks using Fido technology. It may be freely
- distributed if unchanged.
-
- You can reach the author at one of the addresses listed at the end
- of the document.
-
-
- Abstract:
-
- Most fidonet message editors offer a "forward" function. Using
- this function a user A can sort of "redirect" a message from user B
- to another user C, maybe because A is not the correct recipient or
- because C is a better person to answer the message. The name and
- address of B are usually included in the forward in free-text format.
- The message text is included in non-quoted format.
-
- A problem arises when the final recipient C wants to reply to sender B
- of the forwarded message. The forward contains the intermediate user A
- as the sender. So user C must insert the name and address of B
- manually, using the information contained in the message text. The
- message editor of C can't do this automatically because of the
- free-text format. The editor will also use incorrect quote initials,
- which is at least irritating.
-
- This document introduces 6 new control lines which contain the header
- information of the original message. With these control lines the
- message editor can use the original header information automatically.
-
-
- Specifications:
-
- There are 7 new control lines: FWDFROM, FWDTO, FWDORIG, FWDDEST,
- FWDSUBJ, FWDAREA, FWDMSGID. As all control lines they start with an
- ASCII 01 character followed by the control line name followed by
- whitespace followed by the control line's content followed by ASCII 13.
-
- Please note that all these control lines do not have a colon (like the
- control lines in FTS-0001). This would be just waste of space.
-
- FWDFROM
- -------
-
- This control line contains the name of the original sender as found in
- the FROM field of the original message. Leading and trailing
- whitespace should be removed. This control line should be omitted
- altogether if the FROM field is empty.
-
- FWDTO
- -----
-
- This control line contains the name of the original recipient as found
- in the TO field of the original message. Leading and trailing
- whitespace should be removed. This control line should be omitted
- altogether if the TO field is empty.
-
- FWDORIG
- -------
-
- This control line contains the address of the original sender as found
- in the ORIG field of the original message. The usual 5D ASCII notation
- (zone:net/node.point@domain) should be used. This control line should
- be omitted altogether if the address is not known.
-
- FWDDEST
- -------
-
- This control line contains the address of the original recipient as
- found in the DEST field of the original message. The usual 5D ASCII
- notation (zone:net/node.point@domain) should be used. This control line
- should be omitted altogether if the address is not known or unsure
- (as it is the case with forwarded echomail messages).
-
- FWDSUBJ
- -------
-
- This control line contains the subject line of the original message.
- This control line should be omitted altogether if the SUBJ field is
- empty.
- This control line should by made optional for security reasons. Echo
- manager passwords are too easily revealed with it.
-
-
- FWDAREA
- -------
-
- This control line contains the name of the echomail area where the
- original message was forwarded from. It should be omitted altogether
- if the original message was not forwarded from an echomail area.
-
- FWDMSGID
- --------
-
- This control line contains the MSGID control line of the original
- message. It should be omitted altogether if a MSGID control line is not
- present in the original message.
-
-
- Usage:
-
- When the "forward" function of the message editor is invoked, the
- editor program should generate the proposed control lines from the
- header of the original message. If the original message already was
- a forwarded one (indicated by the presence of at least a FWDORIG
- control line), the editor should keep all FWD* control lines and should
- not add any FWD* control lines. This preserves the FWD* control lines
- of the first forwarder, containing the header data of the author of
- the original message.
-
- The editor should not generate FWD* control lines, if the message isn't
- to be forwarded. A mail forwarding robot may also generate these
- control lines, if it not just readdresses the message.
-
- When the "reply" function of the editor is invoked the program should
- use the control lines' contents instead of the header information. The
- control lines should not be included in the reply.
-
- Since it may not be immediately clear whether the user wants to reply
- to the forwarder or to the original sender, the editor should offer a
- means to ignore the proposed control lines and start a "normal" reply
- instead, e.g. by two distinct functions, user preference or dialog.
-
-
- Pseudo code:
-
- forwarding_message:
- if is_forwarded_message then
- don't change FWD* control lines
- else
- add FWD* control lines
-
- quoting_message:
- if is_forwarded_message then
- if reply_to_forwarder then
- use header data (normal quoting)
- else
- use FWD* control lines
- remove FWD* control lines from reply
- else
- use header data (normal quoting)
-
- other_functions:
- remove/ignore FWD* control lines
-
-
- Example:
-
- Message from Joe User to my boss node:
-
- From: Joe User 1:234/567
- To: Harry Herrmannsdoerfer 2:2490/2520
- Subj: Some questions
- @MSGID: 1:234/567 12345678
- Text: Hello Harry!
- ...
-
- Harry forwards the message to me:
-
- From: Harry Herrmannsdoerfer 2:2490/2520
- To: Michael Hohner 2:2490/2520.17
- Subj: Joe's message
- @FWDFROM Joe User
- @FWDORIG 1:234/567
- @FWDTO Harry Herrmannsdoerfer
- @FWDDEST 2:2490/2520
- @FWDSUBJ Some questions
- @FWDMSGID 1:234/567 12345678
- Text: Hi Michael!
- ...
-
- My answer using the new control lines:
-
- From: Michael Hohner 2:2490/2520.17
- To: Joe User 1:234/567
- Subj: Some questions
- @REPLY: 1:234/567 12345678
- Text: Hi Joe!
-
- JU> ...
- ...
-
-
- Compatiblity:
-
- Editor programs which are not prepared for the proposed control lines
- usually just ignore them and remove them from a reply. A reply goes
- to the forwarder. Nothing gained and nothing lost.
-
-
- Implementations:
-
- This proposal is implemented in the author's Fidonet editor
- "FleetStreet for OS/2" (versions 1.17 and above).
-
-
- Contacting the author:
-
- The author may be contacted electronically at the following addresses:
-
- Fidonet: 2:2490/2520.17
- Internet: miho@osn.de
- CompuServe: 100425,1754
-
- Suggestions, comments and corrections are always welcome.
-
-
-
- Go Back
-
-
-
-
+
+
+
+New control lines for forwarded messages.
+
+
+
+
+
+ | Document: FSC-0092
+ | Version: 001
+ | Date: September 12th 1996
+ | Author: Michael Hohner
+
+
+ New control lines
+ for forwarded messages
+
+ by
+ Michael Hohner
+ 2:2490/2520.17
+
+ September 1996
+
+ Status of this document:
+
+ This document proposes a standard for the Fidonet(tm) community
+ and for other networks using Fido technology. It may be freely
+ distributed if unchanged.
+
+ You can reach the author at one of the addresses listed at the end
+ of the document.
+
+
+ Abstract:
+
+ Most fidonet message editors offer a "forward" function. Using
+ this function a user A can sort of "redirect" a message from user B
+ to another user C, maybe because A is not the correct recipient or
+ because C is a better person to answer the message. The name and
+ address of B are usually included in the forward in free-text format.
+ The message text is included in non-quoted format.
+
+ A problem arises when the final recipient C wants to reply to sender B
+ of the forwarded message. The forward contains the intermediate user A
+ as the sender. So user C must insert the name and address of B
+ manually, using the information contained in the message text. The
+ message editor of C can't do this automatically because of the
+ free-text format. The editor will also use incorrect quote initials,
+ which is at least irritating.
+
+ This document introduces 6 new control lines which contain the header
+ information of the original message. With these control lines the
+ message editor can use the original header information automatically.
+
+
+ Specifications:
+
+ There are 7 new control lines: FWDFROM, FWDTO, FWDORIG, FWDDEST,
+ FWDSUBJ, FWDAREA, FWDMSGID. As all control lines they start with an
+ ASCII 01 character followed by the control line name followed by
+ whitespace followed by the control line's content followed by ASCII 13.
+
+ Please note that all these control lines do not have a colon (like the
+ control lines in FTS-0001). This would be just waste of space.
+
+ FWDFROM
+ -------
+
+ This control line contains the name of the original sender as found in
+ the FROM field of the original message. Leading and trailing
+ whitespace should be removed. This control line should be omitted
+ altogether if the FROM field is empty.
+
+ FWDTO
+ -----
+
+ This control line contains the name of the original recipient as found
+ in the TO field of the original message. Leading and trailing
+ whitespace should be removed. This control line should be omitted
+ altogether if the TO field is empty.
+
+ FWDORIG
+ -------
+
+ This control line contains the address of the original sender as found
+ in the ORIG field of the original message. The usual 5D ASCII notation
+ (zone:net/node.point@domain) should be used. This control line should
+ be omitted altogether if the address is not known.
+
+ FWDDEST
+ -------
+
+ This control line contains the address of the original recipient as
+ found in the DEST field of the original message. The usual 5D ASCII
+ notation (zone:net/node.point@domain) should be used. This control line
+ should be omitted altogether if the address is not known or unsure
+ (as it is the case with forwarded echomail messages).
+
+ FWDSUBJ
+ -------
+
+ This control line contains the subject line of the original message.
+ This control line should be omitted altogether if the SUBJ field is
+ empty.
+ This control line should by made optional for security reasons. Echo
+ manager passwords are too easily revealed with it.
+
+
+ FWDAREA
+ -------
+
+ This control line contains the name of the echomail area where the
+ original message was forwarded from. It should be omitted altogether
+ if the original message was not forwarded from an echomail area.
+
+ FWDMSGID
+ --------
+
+ This control line contains the MSGID control line of the original
+ message. It should be omitted altogether if a MSGID control line is not
+ present in the original message.
+
+
+ Usage:
+
+ When the "forward" function of the message editor is invoked, the
+ editor program should generate the proposed control lines from the
+ header of the original message. If the original message already was
+ a forwarded one (indicated by the presence of at least a FWDORIG
+ control line), the editor should keep all FWD* control lines and should
+ not add any FWD* control lines. This preserves the FWD* control lines
+ of the first forwarder, containing the header data of the author of
+ the original message.
+
+ The editor should not generate FWD* control lines, if the message isn't
+ to be forwarded. A mail forwarding robot may also generate these
+ control lines, if it not just readdresses the message.
+
+ When the "reply" function of the editor is invoked the program should
+ use the control lines' contents instead of the header information. The
+ control lines should not be included in the reply.
+
+ Since it may not be immediately clear whether the user wants to reply
+ to the forwarder or to the original sender, the editor should offer a
+ means to ignore the proposed control lines and start a "normal" reply
+ instead, e.g. by two distinct functions, user preference or dialog.
+
+
+ Pseudo code:
+
+ forwarding_message:
+ if is_forwarded_message then
+ don't change FWD* control lines
+ else
+ add FWD* control lines
+
+ quoting_message:
+ if is_forwarded_message then
+ if reply_to_forwarder then
+ use header data (normal quoting)
+ else
+ use FWD* control lines
+ remove FWD* control lines from reply
+ else
+ use header data (normal quoting)
+
+ other_functions:
+ remove/ignore FWD* control lines
+
+
+ Example:
+
+ Message from Joe User to my boss node:
+
+ From: Joe User 1:234/567
+ To: Harry Herrmannsdoerfer 2:2490/2520
+ Subj: Some questions
+ @MSGID: 1:234/567 12345678
+ Text: Hello Harry!
+ ...
+
+ Harry forwards the message to me:
+
+ From: Harry Herrmannsdoerfer 2:2490/2520
+ To: Michael Hohner 2:2490/2520.17
+ Subj: Joe's message
+ @FWDFROM Joe User
+ @FWDORIG 1:234/567
+ @FWDTO Harry Herrmannsdoerfer
+ @FWDDEST 2:2490/2520
+ @FWDSUBJ Some questions
+ @FWDMSGID 1:234/567 12345678
+ Text: Hi Michael!
+ ...
+
+ My answer using the new control lines:
+
+ From: Michael Hohner 2:2490/2520.17
+ To: Joe User 1:234/567
+ Subj: Some questions
+ @REPLY: 1:234/567 12345678
+ Text: Hi Joe!
+
+ JU> ...
+ ...
+
+
+ Compatiblity:
+
+ Editor programs which are not prepared for the proposed control lines
+ usually just ignore them and remove them from a reply. A reply goes
+ to the forwarder. Nothing gained and nothing lost.
+
+
+ Implementations:
+
+ This proposal is implemented in the author's Fidonet editor
+ "FleetStreet for OS/2" (versions 1.17 and above).
+
+
+ Contacting the author:
+
+ The author may be contacted electronically at the following addresses:
+
+ Fidonet: 2:2490/2520.17
+ Internet: miho@osn.de
+ CompuServe: 100425,1754
+
+ Suggestions, comments and corrections are always welcome.
+
+
- | 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 -
-
-
- Go Back
-
-
-
-
+
+
+
+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 -
+
+
+Go Back
+
+
+
+
diff --git a/html/ftsc/fsp-1001.html b/html/ftsc/fsp-1001.html
index 9faa08a6..5f983ac3 100755
--- a/html/ftsc/fsp-1001.html
+++ b/html/ftsc/fsp-1001.html
@@ -1,210 +1,211 @@
-
-
-Timezone information in FTN messages.
-
-
-
-
-
-**********************************************************************
-FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication: FSP-1001
-Revision: 2
-Title: Timezone information in FTN messages
-Author: Odinn Sorensen, 2:236/77
-Revision Date: 27 September 1997
-Expiry Date: 13 September 1999
-----------------------------------------------------------------------
-Contents:
- 1. Scope
- 2. Current practice
- 3. Kludge specification
- 4. Timezone table
- 5. Examples
-----------------------------------------------------------------------
-
-
-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
---------
-
- Current practice for Fidonet Technology Network (FTN) messages is to
- store dates in local time. Timezone information (if known) is
- usually lost. This document specifies a standard for storage of
- timezone information in FTN messages, in the form of a kludge named
- TZUTC.
-
-
-1. Scope
---------
-
- This standard is specified for FTN messages in any form where
- timezone information is not integrated in the message storage or
- transport format. Specifically any form where the information would
- be lost if not stored in a kludge, such as in FTS-1 stored messages
- or packets.
-
-
-2. Current practice
--------------------
-
- Some kludges already exist to specify the timezone of messages,
- notably "TZUTC" and "TZUTCINFO". Other kludges may exist.
-
- To the authors knowledge, no official specification exists for any
- of these kludges.
-
- From observations of these kludges in actual messages, TZUTC and
- TZUTCINFO are identical except for the name. TZUTCINFO is probably
- named after the JAM msgbase subfield of the same name.
-
- This document adopts and documents the TZUTC kludge because it is
- the shortest of them.
-
-
-3. Kludge specification
------------------------
-
- Messages which conform to this specification must add the kludge:
-
- ^aTZUTC:
-
- The offset has the format <[-]hhmm>, where hhmm is the number of
- hours and minutes that local time is offset from UTC. If local time
- is WEST of UTC (Greenwich), then the offset is NEGATIVE. See the
- table below for typical offsets.
-
- Note that the hh in a timezone 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 timezones.
-
- 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 TZUTC need to be changed to reflect this.
-
- When this kludge is present in a message, the "date written" field
- in the stored message is guaranteed to be in local time for the
- given timezone. Note that this specification does not specify the
- timezone for any other date fields. Other date fields (such as "date
- received, arrived, processed, etc.") are usually in local time for
- the system on which the messages are stored.
-
-
-4. Timezone table
------------------
-
- This table gives examples of typical timezones.
-
- -1000 Alaska-Hawaii Standard Time
- -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 Greenwich Mean Time
- 0100 Central European Time
- 0100 British Summer Time
- 0200 Central European Summer Time
- 0200 Eastern European Time
- 0800 Australian Western 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
-
-
-5. Examples
------------
-
- ^aTZUTC: 0000
- ^aTZUTC: 0200
- ^aTZUTC: -0700
-
-
-6. Redundancy
--------------
-
- If the TZUTC data duplicates a field in a storage format in such a
- way that no information is lost in conversion to or from the field,
- then it is recommended that the kludge is not stored in the message.
- However, implementations are allowed to store the TZUTC even when
- redundant.
-
-
-A. References
--------------
-
- [FTS-1] "A Basic FidoNet(r) Technical Standard Revision 16", Randy
- Bush. September 1995.
-
- [JAM] "The JAM message base proposal", Joaquim Homrighausen, Andrew
- Milner, Mats Birch and Mats Wallin. July 1993.
-
-
-B. Author contact data
-----------------------
-
- Odinn Sorensen
- Fidonet: 2:236/77
- E-mail: odinn@goldware.dk
- WWW: http://www.goldware.dk
-
-
-C. History
-----------
-
- Rev.1, 970913: First release.
- Rev.2, 970927: Updated the timezone table. Added section about
- redundancy. Clarified what happens when local time
- changes. Clarified some of what the specification
- doesn't cover.
-
-
-**********************************************************************
-
-
- Go Back
-
-
-
-
+
+
+
+Timezone information in FTN messages.
+
+
+
+
+
+**********************************************************************
+FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
+**********************************************************************
+
+Publication: FSP-1001
+Revision: 2
+Title: Timezone information in FTN messages
+Author: Odinn Sorensen, 2:236/77
+Revision Date: 27 September 1997
+Expiry Date: 13 September 1999
+----------------------------------------------------------------------
+Contents:
+ 1. Scope
+ 2. Current practice
+ 3. Kludge specification
+ 4. Timezone table
+ 5. Examples
+----------------------------------------------------------------------
+
+
+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
+--------
+
+ Current practice for Fidonet Technology Network (FTN) messages is to
+ store dates in local time. Timezone information (if known) is
+ usually lost. This document specifies a standard for storage of
+ timezone information in FTN messages, in the form of a kludge named
+ TZUTC.
+
+
+1. Scope
+--------
+
+ This standard is specified for FTN messages in any form where
+ timezone information is not integrated in the message storage or
+ transport format. Specifically any form where the information would
+ be lost if not stored in a kludge, such as in FTS-1 stored messages
+ or packets.
+
+
+2. Current practice
+-------------------
+
+ Some kludges already exist to specify the timezone of messages,
+ notably "TZUTC" and "TZUTCINFO". Other kludges may exist.
+
+ To the authors knowledge, no official specification exists for any
+ of these kludges.
+
+ From observations of these kludges in actual messages, TZUTC and
+ TZUTCINFO are identical except for the name. TZUTCINFO is probably
+ named after the JAM msgbase subfield of the same name.
+
+ This document adopts and documents the TZUTC kludge because it is
+ the shortest of them.
+
+
+3. Kludge specification
+-----------------------
+
+ Messages which conform to this specification must add the kludge:
+
+ ^aTZUTC: <current offset from UTC>
+
+ The offset has the format <[-]hhmm>, where hhmm is the number of
+ hours and minutes that local time is offset from UTC. If local time
+ is WEST of UTC (Greenwich), then the offset is NEGATIVE. See the
+ table below for typical offsets.
+
+ Note that the hh in a timezone 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 timezones.
+
+ 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 TZUTC need to be changed to reflect this.
+
+ When this kludge is present in a message, the "date written" field
+ in the stored message is guaranteed to be in local time for the
+ given timezone. Note that this specification does not specify the
+ timezone for any other date fields. Other date fields (such as "date
+ received, arrived, processed, etc.") are usually in local time for
+ the system on which the messages are stored.
+
+
+4. Timezone table
+-----------------
+
+ This table gives examples of typical timezones.
+
+ -1000 Alaska-Hawaii Standard Time
+ -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 Greenwich Mean Time
+ 0100 Central European Time
+ 0100 British Summer Time
+ 0200 Central European Summer Time
+ 0200 Eastern European Time
+ 0800 Australian Western 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
+
+
+5. Examples
+-----------
+
+ ^aTZUTC: 0000
+ ^aTZUTC: 0200
+ ^aTZUTC: -0700
+
+
+6. Redundancy
+-------------
+
+ If the TZUTC data duplicates a field in a storage format in such a
+ way that no information is lost in conversion to or from the field,
+ then it is recommended that the kludge is not stored in the message.
+ However, implementations are allowed to store the TZUTC even when
+ redundant.
+
+
+A. References
+-------------
+
+ [FTS-1] "A Basic FidoNet(r) Technical Standard Revision 16", Randy
+ Bush. September 1995.
+
+ [JAM] "The JAM message base proposal", Joaquim Homrighausen, Andrew
+ Milner, Mats Birch and Mats Wallin. July 1993.
+
+
+B. Author contact data
+----------------------
+
+ Odinn Sorensen
+ Fidonet: 2:236/77
+ E-mail: odinn@goldware.dk
+ WWW: http://www.goldware.dk
+
+
+C. History
+----------
+
+ Rev.1, 970913: First release.
+ Rev.2, 970927: Updated the timezone table. Added section about
+ redundancy. Clarified what happens when local time
+ changes. Clarified some of what the specification
+ doesn't cover.
+
+
+**********************************************************************
+
-**********************************************************************
-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.
-
-
-**********************************************************************
-
-
- Go Back
-
-
-
-
+
+
+
+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.
+
+
+**********************************************************************
+
+
+Go Back
+
+
+
+
diff --git a/html/ftsc/fsp-1003.html b/html/ftsc/fsp-1003.html
index f7ed6040..00b039aa 100755
--- a/html/ftsc/fsp-1003.html
+++ b/html/ftsc/fsp-1003.html
@@ -1,116 +1,117 @@
-
-
-Suggested use of Nodelist Fields.
-
-
-
-
-
-**********************************************************************
-FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication: FSP-1003
-Revision: 1
-Title: Suggested use of Nodelist Fields
-Author: Lee Kindness
-Revision Date: 15 May 1997
-Expiry Date: 15 May 1999
-----------------------------------------------------------------------
-Contents:
- 1. Field 3, Node Name
- 2. Field 4, Location
- 3. Field 5, Sysop Name
-----------------------------------------------------------------------
-
-
-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.
-
-
-Introduction
-------------
-
- This document makes recommendations on the use of various fields in
- the distribution nodelist (St. Louis nodelist format", fts-0005).
- Naturally it is the choice of the *C's if they want to use them.
- Remember the fts-0005 requirements should still be adhered to.
-
-
-1. Field 3, Node Name
----------------------
-
- The node name field should be no more than 20 characters long. For
- comparison in nodelist.122'1997 the minimum entry was 1, maximum 51!
- and the average was 14.
-
- For zone entries this field should contain a description of the
- zones area, (eg North America, Europe). For region entries it should
- contain the country/state, for host entries the local area name and
- for hub entries a description of the area the hub serves.
-
-
-2. Field 4, Location
---------------------
-
- This field contains the location of the node. It should usually be
- expressed as the primary local location (town, suburb, city, etc.)
- plus an 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, UK, etc.).
-
- For zone and region entries this field should also have the julian
- day of segment creation appended to it (eg "Somearea_(122)") to aid
- checks on the validity of the nodelist.
-
-
-3. Field 5, Sysop Name
-----------------------
-
- This field contains the name of the system operator. Entries such as
- "postmaster" and "uucp" should not be used. Aliases should not be
- permitted in this field (as they give Fidonet a 'less respectable'
- image).
-
-
-A. Author contact data
-----------------------
-
- Lee Kindness
- Fidonet: n/a
- E-mail: wangi@earthling.net
- WWW: http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
-
-
-B. History
-----------
-
- Rev.1, 971101: First release as FSP, based on the Fidonews 14/20
- article. Transformed into FSP document by Odinn
- Sorensen.
-
-
-**********************************************************************
-
-
- Go Back
-
-
-
-
+
+
+
+Suggested use of Nodelist Fields.
+
+
+
+
+
+**********************************************************************
+FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
+**********************************************************************
+
+Publication: FSP-1003
+Revision: 1
+Title: Suggested use of Nodelist Fields
+Author: Lee Kindness
+Revision Date: 15 May 1997
+Expiry Date: 15 May 1999
+----------------------------------------------------------------------
+Contents:
+ 1. Field 3, Node Name
+ 2. Field 4, Location
+ 3. Field 5, Sysop Name
+----------------------------------------------------------------------
+
+
+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.
+
+
+Introduction
+------------
+
+ This document makes recommendations on the use of various fields in
+ the distribution nodelist (St. Louis nodelist format", fts-0005).
+ Naturally it is the choice of the *C's if they want to use them.
+ Remember the fts-0005 requirements should still be adhered to.
+
+
+1. Field 3, Node Name
+---------------------
+
+ The node name field should be no more than 20 characters long. For
+ comparison in nodelist.122'1997 the minimum entry was 1, maximum 51!
+ and the average was 14.
+
+ For zone entries this field should contain a description of the
+ zones area, (eg North America, Europe). For region entries it should
+ contain the country/state, for host entries the local area name and
+ for hub entries a description of the area the hub serves.
+
+
+2. Field 4, Location
+--------------------
+
+ This field contains the location of the node. It should usually be
+ expressed as the primary local location (town, suburb, city, etc.)
+ plus an 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, UK, etc.).
+
+ For zone and region entries this field should also have the julian
+ day of segment creation appended to it (eg "Somearea_(122)") to aid
+ checks on the validity of the nodelist.
+
+
+3. Field 5, Sysop Name
+----------------------
+
+ This field contains the name of the system operator. Entries such as
+ "postmaster" and "uucp" should not be used. Aliases should not be
+ permitted in this field (as they give Fidonet a 'less respectable'
+ image).
+
+
+A. Author contact data
+----------------------
+
+ Lee Kindness
+ Fidonet: n/a
+ E-mail: wangi@earthling.net
+ WWW: http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
+
+
+B. History
+----------
+
+ Rev.1, 971101: First release as FSP, based on the Fidonews 14/20
+ article. Transformed into FSP document by Odinn
+ Sorensen.
+
+
+**********************************************************************
+
-**********************************************************************
-FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication: FSP-1004
-Revision: 1
-Title: Standard Fidonet Addressing
-Author: Lee Kindness
-Revision Date: 15 May 1997
-Expiry Date: 15 May 1999
-----------------------------------------------------------------------
-Contents:
- 1. Standard Fidonet Addressing
- 2. Internet Gateway Addressing
- 3. Routing Address Syntax
-----------------------------------------------------------------------
-
-
-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.
-
-
-Introduction
-------------
-
- This document describes the standard form of addressing in Fidonet
- today along with the common method of addressing via internet
- gateways. In addition it proposes an extended addressing syntax,
- useful for routing purposes. This is a draft for comments and
- suggestions.
-
-
-1. Standard Fidonet Addressing
-------------------------------
-
- Fidonet addressing uses the following format:
-
- ZZ:NN/FF.PP@DO
-
- where the fields refer to...
-
- ZZ - Zone Number: The zone the node is part of.
- Min: 1 Max: 32767
- If 'ZZ:' is missing then assume 1 as the zone.
-
- NN - Net Number: The network the node is a member of.
- Min: 1 Max: 32767
- Must be present.
-
- FF - Node Number: The actual node number.
- Min: -1 Max: 32767
- Must be present.
-
- PP - Point Number: If the system is a point rather than a node then
- this is their point number off the node.
- Min: 0 Max: 32767
- If '.PP' is missing then assume 0 (ie not a
- point) as the point number.
-
- DO - Domain: The name of the 'Fidonet Technology Network'.
- Maximum length of 8 characters. The domain
- should not include periods, thus 'fidonet.org'
- is invalid (should be fidonet).
- If '@DO' is missing then fidonet can be assumed.
-
- The following are all valid examples:
- 1:234/5.6@fidonet (a '5D' address) => 1:234/5.6@fidonet
- 2:34/6.78 (a '4D' address) => 2:34/6.78@fidonet
- 4:610/34 (a '3D' address) => 4:610/34.0@fidonet
- 123/45 (a '2D' address) => 1:123/45.0@fidonet
- 955:95/2@othernet (another FTN) => 955:95/2.0@othernet
- 2:259/-1 (node application) => 2:259/-1.0@fidonet
-
- The limits on each various part of the address are a result of
- fts-0005 (zone, net, node, point), fsc-0045 (domain) and Policy 4
- (-1 node address for node application).
-
-
-2. Internet Gateway Addressing
-------------------------------
-
- An internet user can send email/netmail to a fidonet user via one of
- the fidonet->internet gateway systems (it's out-with the scope of
- this document to describe the semantics of posting). The internet
- user would send an email to a Fidonet user by using an email address
- of the following syntax:
-
- user.name@pPP.fFF.nNN.zZZ.gateway.domain
-
- where the fields refer to...
-
- user.name - Name: Name of the user the email is being sent
- to, spaces replaced by periods.
-
- PP - Point Number: As Fidonet address (FA)
- If '.pPP' is missing 0 is assumed.
-
- FF - Node Number: As FA
- Must be present.
-
- NN - Net Number: As FA
- Must be present.
-
- ZZ - Zone Number: As FA
- Must be present.
-
- gate.way - Gateway: Internet domain of the gateway, for
- example 'fidonet.org'.
- Must be present.
-
- The following are all valid examples (assuming 'fidonet.org' is an
- internet gateway):
-
- joe.bloggs@p6.f5.n234.z1.fidonet.org => 1:234/5.6@fidonet
- harry.cat@p78.f6.n34.z2.fidonet.org => 2:34/6.78@fidonet
- i.be.jolly@f34.n610.z4.fidonet.org => 4:610/34.0@fidonet
-
- and if 'foo.bar.org.uk' is a gateway for 'othernet':
-
- louise.hat@f2.n95.z955.foo.bar.org.uk => 955:95/2.0@othernet
-
-
-3. Routing Address Syntax
--------------------------
-
- The two previous address types (Fidonet and Internet->Fidonet
- gateway) are common practice, this however is a suggested standard
- of addressing for routing tables. The routing address has the
- following syntax:
-
- DD:ZZ:RR:NN:HH:FF:PP
-
- where the fields refer to:
-
- DD - Domain: As FA
- Must be present, even if blank (ie a leading
- ':') to ensure we always have 6 ':'s in an
- address to aid pattern matching.
-
- ZZ - Zone Number: As FA
- Must be present.
-
- RR - Region Number: The region (from fts-0005 nodelist) that the
- following network is in.
- Min: 1 Max: 32767
- Must be present.
-
- NN - Net Number: As FA
- Must be present.
-
- HH - Hub: The hub (from fts-0005 nodelist) that the node
- is under, or 0 (host hub).
- Min: 1 Max: 32767
- Must be present.
-
- FF - Node Number: As FA
- Must be present.
-
- PP - Point Number: As FA
- Must be present.
-
- ':' has been chosen as the separator as it is not a POSIX regular
- expression character or globing character (where as '.' is) and thus
- always easy use of wildcards on the address. The following points
- should be noted:
-
- 1. All addresses have 6 ':'s
- 2. The domain is at the front, the address gets more specific to
- the right
- 3. Nodes have 0 as their point number
- 4. A zone net has identical zone, region and net fields
- 5. A region net has identical region and net fields
-
- Example fidonet addresses converted to routing addresses:
-
- fidonet:2:25:259:0:7:0 => 2:259/7.0@fidonet, region 25, hub 0
- fidonet:1:1:1:0:23:0 => 1:1/23.0@fidonet, zone 1 net
- :955:9551:95:300:45:0 => 955:95/45.0, region 9551, hub 300
- fidonet:2:25:25:0:0:0 => 2:25/0.0@fidonet, R25C
- cnet:12:34:341:100:1:7 => 12:341/1.7@cnet, region 34, hub 100
- :2:25:259:300:300:0 => 2:259/300.0, region 25, hub 300
-
- Example POSIX regular expression patterns on routing addresses:
-
- [a-z]*:[0-9]+:[0-9]+:[0-9]+:[0-9]+:[0-9]+:[0-9]+ (any address)
- [a-z]*(:[0-9]+)+ (any address)
- fidonet:2:25:[0-9]+:[0-9]+:[0-9]+:[0-9]+ (region 25 node)
- fidonet:2:25(:[0-9]+)+ (region 25 node)
- fidonet:1:12:125(:[0-9]+)+ (all net 1:125 nodes)
- fidonet:1:12:125:200(:[0-9]+)+ (all hub 1:125/200 downlinks)
- fidonet:1:12:125:200:2:[0-9]+ (all 1:125/2 points)
- fidonet:1:12:125:[0-9]+:(25|34|56):0
- (nodes 1:125/25.0, 1:125/34.0 and 1:125/56.0)
-
- Example 'DOS style' patterns on routing addresses:
-
- *:*:*:*:*:*:* (any address)
- fidonet:2:25:*:*:*:* (region 25 node)
- fidonet:1:12:125:*:*:* (all net 1:125 nodes)
- fidonet:1:12:125:200:*:* (all hub 1:125/200 downlinks)
- fidonet:1:12:125:200:2:* (all 1:125/2 points)
- fidonet:1:12:125:*:3*:0 (any net 1:125 nodes starting with 3)
- fidonet:1:12:125:*:3?:0 (net 1:125 nodes 30 thru 39)
-
- The standard doesn't define which standard of pattern matching to
- use, only the format of the addresses. These routing addresses would
- be used in routing tables and configurations.
-
-
-A. Author contact data
-----------------------
-
- Lee Kindness
- Fidonet: n/a
- E-mail: wangi@earthling.net
- WWW: http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
-
-
-B. History
-----------
-
- Rev.1, 971101: First release as FSP, based on the Fidonews 14/20
- article. Transformed into FSP document by Odinn
- Sorensen.
-
-
-**********************************************************************
-
-
- Go Back
-
-
-
-
+
+
+
+Standard FidoNet Addressing.
+
+
+
+
+
+**********************************************************************
+FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
+**********************************************************************
+
+Publication: FSP-1004
+Revision: 1
+Title: Standard Fidonet Addressing
+Author: Lee Kindness
+Revision Date: 15 May 1997
+Expiry Date: 15 May 1999
+----------------------------------------------------------------------
+Contents:
+ 1. Standard Fidonet Addressing
+ 2. Internet Gateway Addressing
+ 3. Routing Address Syntax
+----------------------------------------------------------------------
+
+
+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.
+
+
+Introduction
+------------
+
+ This document describes the standard form of addressing in Fidonet
+ today along with the common method of addressing via internet
+ gateways. In addition it proposes an extended addressing syntax,
+ useful for routing purposes. This is a draft for comments and
+ suggestions.
+
+
+1. Standard Fidonet Addressing
+------------------------------
+
+ Fidonet addressing uses the following format:
+
+ ZZ:NN/FF.PP@DO
+
+ where the fields refer to...
+
+ ZZ - Zone Number: The zone the node is part of.
+ Min: 1 Max: 32767
+ If 'ZZ:' is missing then assume 1 as the zone.
+
+ NN - Net Number: The network the node is a member of.
+ Min: 1 Max: 32767
+ Must be present.
+
+ FF - Node Number: The actual node number.
+ Min: -1 Max: 32767
+ Must be present.
+
+ PP - Point Number: If the system is a point rather than a node then
+ this is their point number off the node.
+ Min: 0 Max: 32767
+ If '.PP' is missing then assume 0 (ie not a
+ point) as the point number.
+
+ DO - Domain: The name of the 'Fidonet Technology Network'.
+ Maximum length of 8 characters. The domain
+ should not include periods, thus 'fidonet.org'
+ is invalid (should be fidonet).
+ If '@DO' is missing then fidonet can be assumed.
+
+ The following are all valid examples:
+ 1:234/5.6@fidonet (a '5D' address) => 1:234/5.6@fidonet
+ 2:34/6.78 (a '4D' address) => 2:34/6.78@fidonet
+ 4:610/34 (a '3D' address) => 4:610/34.0@fidonet
+ 123/45 (a '2D' address) => 1:123/45.0@fidonet
+ 955:95/2@othernet (another FTN) => 955:95/2.0@othernet
+ 2:259/-1 (node application) => 2:259/-1.0@fidonet
+
+ The limits on each various part of the address are a result of
+ fts-0005 (zone, net, node, point), fsc-0045 (domain) and Policy 4
+ (-1 node address for node application).
+
+
+2. Internet Gateway Addressing
+------------------------------
+
+ An internet user can send email/netmail to a fidonet user via one of
+ the fidonet->internet gateway systems (it's out-with the scope of
+ this document to describe the semantics of posting). The internet
+ user would send an email to a Fidonet user by using an email address
+ of the following syntax:
+
+ user.name@pPP.fFF.nNN.zZZ.gateway.domain
+
+ where the fields refer to...
+
+ user.name - Name: Name of the user the email is being sent
+ to, spaces replaced by periods.
+
+ PP - Point Number: As Fidonet address (FA)
+ If '.pPP' is missing 0 is assumed.
+
+ FF - Node Number: As FA
+ Must be present.
+
+ NN - Net Number: As FA
+ Must be present.
+
+ ZZ - Zone Number: As FA
+ Must be present.
+
+ gate.way - Gateway: Internet domain of the gateway, for
+ example 'fidonet.org'.
+ Must be present.
+
+ The following are all valid examples (assuming 'fidonet.org' is an
+ internet gateway):
+
+ joe.bloggs@p6.f5.n234.z1.fidonet.org => 1:234/5.6@fidonet
+ harry.cat@p78.f6.n34.z2.fidonet.org => 2:34/6.78@fidonet
+ i.be.jolly@f34.n610.z4.fidonet.org => 4:610/34.0@fidonet
+
+ and if 'foo.bar.org.uk' is a gateway for 'othernet':
+
+ louise.hat@f2.n95.z955.foo.bar.org.uk => 955:95/2.0@othernet
+
+
+3. Routing Address Syntax
+-------------------------
+
+ The two previous address types (Fidonet and Internet->Fidonet
+ gateway) are common practice, this however is a suggested standard
+ of addressing for routing tables. The routing address has the
+ following syntax:
+
+ DD:ZZ:RR:NN:HH:FF:PP
+
+ where the fields refer to:
+
+ DD - Domain: As FA
+ Must be present, even if blank (ie a leading
+ ':') to ensure we always have 6 ':'s in an
+ address to aid pattern matching.
+
+ ZZ - Zone Number: As FA
+ Must be present.
+
+ RR - Region Number: The region (from fts-0005 nodelist) that the
+ following network is in.
+ Min: 1 Max: 32767
+ Must be present.
+
+ NN - Net Number: As FA
+ Must be present.
+
+ HH - Hub: The hub (from fts-0005 nodelist) that the node
+ is under, or 0 (host hub).
+ Min: 1 Max: 32767
+ Must be present.
+
+ FF - Node Number: As FA
+ Must be present.
+
+ PP - Point Number: As FA
+ Must be present.
+
+ ':' has been chosen as the separator as it is not a POSIX regular
+ expression character or globing character (where as '.' is) and thus
+ always easy use of wildcards on the address. The following points
+ should be noted:
+
+ 1. All addresses have 6 ':'s
+ 2. The domain is at the front, the address gets more specific to
+ the right
+ 3. Nodes have 0 as their point number
+ 4. A zone net has identical zone, region and net fields
+ 5. A region net has identical region and net fields
+
+ Example fidonet addresses converted to routing addresses:
+
+ fidonet:2:25:259:0:7:0 => 2:259/7.0@fidonet, region 25, hub 0
+ fidonet:1:1:1:0:23:0 => 1:1/23.0@fidonet, zone 1 net
+ :955:9551:95:300:45:0 => 955:95/45.0, region 9551, hub 300
+ fidonet:2:25:25:0:0:0 => 2:25/0.0@fidonet, R25C
+ cnet:12:34:341:100:1:7 => 12:341/1.7@cnet, region 34, hub 100
+ :2:25:259:300:300:0 => 2:259/300.0, region 25, hub 300
+
+ Example POSIX regular expression patterns on routing addresses:
+
+ [a-z]*:[0-9]+:[0-9]+:[0-9]+:[0-9]+:[0-9]+:[0-9]+ (any address)
+ [a-z]*(:[0-9]+)+ (any address)
+ fidonet:2:25:[0-9]+:[0-9]+:[0-9]+:[0-9]+ (region 25 node)
+ fidonet:2:25(:[0-9]+)+ (region 25 node)
+ fidonet:1:12:125(:[0-9]+)+ (all net 1:125 nodes)
+ fidonet:1:12:125:200(:[0-9]+)+ (all hub 1:125/200 downlinks)
+ fidonet:1:12:125:200:2:[0-9]+ (all 1:125/2 points)
+ fidonet:1:12:125:[0-9]+:(25|34|56):0
+ (nodes 1:125/25.0, 1:125/34.0 and 1:125/56.0)
+
+ Example 'DOS style' patterns on routing addresses:
+
+ *:*:*:*:*:*:* (any address)
+ fidonet:2:25:*:*:*:* (region 25 node)
+ fidonet:1:12:125:*:*:* (all net 1:125 nodes)
+ fidonet:1:12:125:200:*:* (all hub 1:125/200 downlinks)
+ fidonet:1:12:125:200:2:* (all 1:125/2 points)
+ fidonet:1:12:125:*:3*:0 (any net 1:125 nodes starting with 3)
+ fidonet:1:12:125:*:3?:0 (net 1:125 nodes 30 thru 39)
+
+ The standard doesn't define which standard of pattern matching to
+ use, only the format of the addresses. These routing addresses would
+ be used in routing tables and configurations.
+
+
+A. Author contact data
+----------------------
+
+ Lee Kindness
+ Fidonet: n/a
+ E-mail: wangi@earthling.net
+ WWW: http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
+
+
+B. History
+----------
+
+ Rev.1, 971101: First release as FSP, based on the Fidonews 14/20
+ article. Transformed into FSP document by Odinn
+ Sorensen.
+
+
+**********************************************************************
+
-**********************************************************************
-FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication: FSP-1005
-Revision: 6
-Title: Zone 2 nodelist flags
-Author: Frank Ellermann, 2:240/5815.1
-Revision Date: 27 November 1997
-Expiry Date: 27 November 1999
----------------------------------------------------------------------
-Contents:
- 1. Introduction
- 2. FTS-0005 flags
- 3. User flags
- 4. Approved zone 2 user flags
- 5. Flag implications
- 6. Invalid combinations
- 7. Baud rate field
- 8. Thanks to...
----------------------------------------------------------------------
-
-
-1. Introduction
----------------
- This document informs about known differences of FidoNet zone 2
- nodelist flags from FTS-0005.003. The ultimate sources for these
- informations are the current Z2 nodelist epilogue and the setup
- for flag corrections at Z2C, but it may be difficult to get these
- sources for readers in other zones.
-
-| All changes since version 5 are marked by a bar at the left edge.
- It is (again) possible to list V32b and V42b in zone 2, upper case
- V32B or V42B is not more enforced. Currently new flags needed for
- IP-connectivity are under test in zone 2 (only internally), e.g.
-
- -> VM VModem, default port 3141, dummy country code 000-
- -> IFC IFCico, default port 60179, dummy country code 000-
- -> BND BinkP, default port 24544, dummy country code 000-
- -> IP general IP connectivity, dummy country code 000-
- -> TELN Telnet dummy country code 000-
-
-
-2. FTS-0005 flags
------------------
- The following flags are used as specified in FTS-0005.003:
-
- CM Continuous Mail, node accepts mail 24 hours a day
- MO Mailer Only (no BBS)
- LO Listed Only, node accepts calls only from listed
- node numbers in the current FidoNet nodelist
-
- -> V21 ITU-T V21 300 bps full duplex (obsolete)
- V22 ITU-T V22 1200 bps full duplex (obsolescent)
-
-| In zone 2 the value 1200 in the baud rate field implies V22. Only
-| two nodes not supporting at least V22bis, ISDN, or IP still exist
-| in the zone 2 segment. Flag V22 is almost obsolete, and V21 is
-| already removed in Z2. Both flags should be dropped from the next
-| FTS-0005 version.
-
- V29 ITU-T V29 9600 bps half duplex (obsolescent)
- -> V33 ITU-T V33 14400 bps half duplex (obsolete)
-
- V33 cannot be used in connecting FidoNet nodes over public dial-up
- lines and is most probably a historical error in FTS-0005. A very
- similar argument is applicable on V29, all nodes flying this flag
- support at least V32. Today only one node in Z2 still flies V29,
- and V33 is already removed in Z2. Both flags should be dropped in
- the next FTS-0005 version.
-
- V32 ITU-T V32 9600 bps full duplex
- V32b ITU-T V32bis 14400 bps full duplex (implies V32)
-| V34 ITU-T V34 28800 bps full duplex (33600 bps option)
-
- FTS-0005 specifies V32b and V42b (capital V and small b), current
- nodelist practice in FidoNet shows all combinations of small and
- capital letters for flags. This was no problem before FSC-0062
- introduced case-sensitive flags. The best solution is to stick to
- the current practice and treat all old flags as case-insensitive.
-
- H96 Hayes V9600
- HST USR Courier HST up to 9600 (implies MNP)
- H14 USR Courier HST up to 14400 (implies HST)
- -> H16 USR Courier HST up to 16800 (implies H14 and V42b)
- MAX Microcom AX/96xx series (almost obsolete)
- PEP Packet Ensemble Protocol
- CSP Compucom Speedmodem
- -> ZYX Zyxel series 16800 bps (implies V32b and V42b)
- -> V32T V.32 Terbo 19200 bps (implies V32b)
- VFC V.Fast Class 28800 bps (should imply V32b and V42b)
-
- If a flag directly or indirectly implies other flags, then these
- other flags are not shown in a nodelist entry, because this would
- be redundant. Unfortunately the rules for redundancies in zone 2
- and FTS-0005 are different. Zone 2 continued to avoid redundancy
- with most "new" flags, but FTS-0005.003 specified no redundancies
- for "new" flags like ZYX, H16, V32T, or VFC. "New" flags in this
- context are flags approved by FidoNet International Coordinators
- since 1989, when FTS-0005.TXT, the predecesssor of FTS-0005.003,
- was published.
-
- For details see the chapter "implications" below, for now only
- note, that in zone 2 H16 implies V42b, ZYX implies V32b and V42b,
- and V32T implies V32b.
-
- Zone 1 and zone 2 have introduced a user flag Z19 approved by the
- corresponding Zone Coordinator. User flags are discussed later,
- for now only note, that in zone 2 ZYX is specified as Zyxel 16k8,
- while FTS-0005.003 not knowing Z19 specifies ZYX as generic flag
- for all Zyxel protocol speeds.
-
- Today only one node in FidoNet still really flies MAX, this flag
- is obsolete and should be dropped from FTS-0005. The flags CSP
- (7 nodes worldwide) and H96 should be marked as obsolescent.
-
-| MNP Microcom Networking Protocol 2-4 error correction
-| V42 ITU-T LAP-M error correction w/ fallback to MNP 2-4
-| V42b ITU-T V.42bis BTLZ data compression over V.42 LAP-M
-
- The next version of FTS-0005 should adopt the better V42b and
- MNP definitions of the zone 3 nodelist epilogue. FTS-0005.003
- specifies an implication of V42 by V42b, but the exact meaning of
- the flag MNP is unclear. Most probably this flag was meant to
-| indicate support of MNP 2-4, and in this sense V42 implies MNP.
-
-| Note the difference between the flag V42b (implying V42) and the
-| standard V.42bis (not necessarily based on LAP-M as data link
-| layer protocol), without this difference the flag V42b would be
-| ambiguous for combined modem and ISDN node entries.
-
- MN No compression supported in insecure inbound
-
- XA Bark and WaZOO file/update requests
- XB Bark file/update requests, WaZOO file requests
- XC Bark file requests, WaZOO file/update requests
- XP Bark file/update requests
- XR Bark and WaZOO file requests
- XW WaZOO file requests
- XX WaZOO file/update requests
-
- These flags are equivalent in FTS-0005 and in the zone 2 segment.
-
- Gx..x Gateway to domain 'x..x'
-
- Valid values for this flag are assigned by the Fido International
- Coordinator, FTS-0005.003 explicitly mentions GUUCP. In zone 2
- only GUUCP gateways are flagged.
-
- #01 Zone 5 mail hour (01:00 - 02:00 UTC) w/ Bell 212A
- #02 Zone 2 mail hour (02:30 - 03:30 UTC) w/ Bell 212A
- -> #08 Zone 4 mail hour (08:00 - 09:00 UTC) w/ Bell 212A
- #09 Zone 1 mail hour (09:00 - 10:00 UTC) w/ Bell 212A
- #18 Zone 3 mail hour (18:00 - 19:00 UTC) w/ Bell 212A
- #20 Zone 6 mail hour (20:00 - 21:00 UTC) w/ Bell 212A
-
- The variants !01, !02, !08, !09, !18, and !20 indicate missing
- Bell 212A support. In zone 2 #02 or !02 would be obviously
- redundant.
-
- Today less than four 1200 modems (V22 or Bell 212A) are listed.
- A future version of FTS-0005 should drop !mn variants together
- with V21 and V22 flags.
-
- Further most non-CM systems flagging #mn or !mn today probably
- want to show additional online times instead of additional mail
- hours. As soon as FSC-0062 flags have been approved by the IC
- or adopted as FTS by the FTSC, the following version of FTS-0005
- should mark #mn as obsolescent and recommend the more flexible
- FSC-0062 flags (see below).
-
-
-3. User flags
--------------
- An example for one of several problems in zone 2 with user flags:
-
- ...,U,Z19,V110H,V120L,V120H,X75,ENC,NEC
-
- These flags indicate a modern Zyxel ISDN-modem and two additional
- user flags ENC and NEC. This possible user flags string contains
- 34 characters, but at most 32 characters are allowed in FTS-0005.
-
- ...,U,Z19,V110L,V110H,X75,ISDNA,ISDNB,ISDNC
-
- During the period for the replacement of old by new ISDN flags
- (several months !) many nodes listed both old and new flags for
- maximal compatibility, and no problems with nodelist compilers
- or mailers caused by too long user flags strings were reported.
-
- Therefore the length limit in FTS-0005 is probably unnecessary
- and at least inconsequent: Other nodelist fields like the system
- name are unlimited, so why only restrict the user flags string ?
- To help developpers an upper limit of e.g. 255 characters for a
- nodelist line and 63 characters for fields 3 to 6 would be more
- useful.
-
- The next problem with user flag strings as specified in FTS-0005
- is their introduction by the letter U with no comma following:
-
- Nodelist compilers could parse ...,UISDN,USR in user flags ISDN
- and USR. But USR cannot be approved as "real" flag, because the
- combination ...,USR,UISDN would then be parsed in SR and UISDN.
-
- Other side effects of the FTS-0005 specification are additional
- difficulties in finding flags. Almost all flags are separated
- by a comma, only the first user flag can be an exception to this
- simple rule. If the order of user flags has no meaning, then...
-
- ...,UV120L,V120H
- ...,UV120H,V120L
-
- ... are equivalent. A "simple" solution of this problem could be
- to treat UV120L as synonym for V120L, and UV120H as synonym for
- V120H. Similar problems show up, if user flags are counted, etc.
-
- Obviously a nodelist compiler looking for user flags has always
- to consider the case "user flag separated by comma". In zone 2
- this idea was simply extended to the first user flag:
-
- All flags are separated by commas. Flags not yet approved by the
- International Coordinator or the FTSC (i.e. user flags only used
- experimentally or locally) are separated by a new pseudo flag U.
-
- -> U pseudo flag to the left of at least one user flag
-
- All flags following this pseudo flag U are user flags, all flags
- before this pseudo flag are "real" flags specified in FTS-0005 or
- approved by the International Coordinator.
-
- Because this definition should be compatible with any reasonable
- software implementation based on FTS-0005.003, and simplifies the
- handling of user flags significantly, a future FTS-0005 version
- will hopefully adopt it.
-
-
-4. Approved zone 2 user flags
------------------------------
- In zone 2 user flags have to be approved by the Zone Coordinator.
- Currently the following zone 2 user flags exist:
-
- -> V110L ITU-T V.110 19k2 async 'Low' (former ISDNA)
- -> V110H ITU-T V.110 38k4 async 'High' (former ISDNB)
- -> V120L ITU-T V.120 56k6 async, N1 = 259, W = 7, modulo 8
- -> V120H ITU-T V.120 64k async, N1 = 259, W = 7, modulo 8
- -> X75 ITU-T X.75 SLP (single link procedure),
- 64kbit/s B channel; layer 2 max. framesize N1 = 2048,
- window size W = 2, frame numbering modulo 8;
- layer 3 transparent (no packet layer)
- -> ISDN Other configuration, used only if none of above fits
-
- These ISDN flags follow the specification in FSC-0091.
-
- -> Tyz Online time flags as specified in FSC-0062
-
- 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 20:00, w 20:30, X 23:00, x 23:30.
-
- For example TuB shows an online period from 20:30 until 1:00 UTC.
-
- -> Z19 Zyxel series 19200 bps (implies ZYX)
- -> X2C x2 client w/ 56000 bps (should imply V34 and V42b)
- -> X2S x2 server w/ 64000 bps (should imply V34 and V42b)
-
- -> K12 Systems offering all educational K12-conferences
- -> ENC The node accepts inbound encrypted mail
-
- -> NC Network Coordinator (only if the NC is not the host)
- -> NEC Net Echomail Coordinator (at most one per net)
- -> REC Region Echomail Coordinator (at most one per region)
-
- Redundant AKAs used to indicate echomail coordination in zone 2
- are no longer permitted. One *EC flag is valid for all AKAs of
- a given sysop.
-
-
-5. Flag implications
---------------------
- Flag implications directly or indirectly specified in FTS-0005:
-
- HST => MNP
- H14 => MNP HST
- H16 => MNP HST H14
- V42b => V42 (MNP ?)
- V32b => V32
-
- Flag implications specified in the zone 2 nodelist epilogue:
-
- HST => MNP
- H14 => HST MNP
- -> H16 => V42 MNP V42b H14 HST
- -> V42b => V42 MNP
- -> ZYX => V42 MNP V42b V32 V32b
- -> Z19 => V42 MNP V42b V32 V32b ZYX
- V32b => V32
- -> V32T => V32 V32b
-
- -> V110L => ISDN
- -> V110H => ISDN
- -> V120L => ISDN
- -> V120H => ISDN
- -> X75 => ISDN
-
- The latter ISDN flag redundancies are a consequence of FSC-0091.
- Maybe some of the following implications could be added in zone 2:
-
- VFC => V32 V32b MNP V42 V42b
- X2C => V34 MNP V42 V42b
- X2S => V34 MNP V42 V42b
-
- Flag implications (i.e. not listing redundant flags) have several
- advantages: Some old nodelist tools are unable to handle too long
- lines. Old flags like HST, MNP, V42, or V32 vanish automatically,
- if they are implied by H16, V42b, V32b, or better. Redundancies
- defined globally for the whole nodelist help to avoid flag errors.
-
-
-6. Invalid combinations
------------------------
- All file request flags exclude each other (at most 1 is possible):
- XA, XB, XC, XP, XR, XW, and XX. For flag checkers only supporting
- implications a good approximation based on FTS-0005 definitions is
-
-| XA => XW XR XP XB XC XX,
-| XB => XW XR XP,
-| XC => XW XR XX,
-| XR => XW,
-| XX => XW.
-
- Further X2C cannot be combined with X2S, and FSC-62 Tyz-flags are
- not possible with CM. Also Tyz with y = z is of course incorrect.
-
- Some modem protocols are "proprietary" in a sense, that all today
- known modems can fly at most one of the corresponding modem flags:
- MAX, CSP, H96, PEP, HST, H14, H16, ZYX, and Z19.
-
- A few "old" modem protocol flags are known to be invalid if used
- together with "new" protocol flags, i.e. each "old" flag excludes
- all "new" flags and vice versa:
-
- "Old" in this sense are MAX, CSP, H96, HST, H14, V32, and PEP.
- "New" in this sense are X2S, X2C, V34, VFC, V32T, and H16.
-
- For Z2 add ZYX as "old" and Z19 as "new". A simple REXX script to
- test some known inconsistencies is available as NLSCHECK.REX at
- the site of the author. While erroneously listing redundant flags
- causes no harm, other errors like combining V34 with HST or Z19
- with H16 indicate serious problems, which can result in connection
- failures or other damage.
-
-
-7. Baud rate field
-------------------
- The baud rate field 7 in the nodelist as specified in FTS-0005 is
- nearly useless today: Except from a few remaining 1200 and 2400
- nodes almost all nodelist entries show either 9600 for all modem
- protocols better than V22bis or 300 for ISDN (or IP) only nodes.
- No more V21 or Bell 103 modems are listed for more than 2 years.
-
- The baud rate values 19200 and 38400 specified in FTS-0005.003
- have not been used in the FidoNet nodelist. So all a reasonable
- nodelist compiler can do today, is treat 300 as indicator for
- ISDN or IP only, and treat unknown or missing values in field 7
- like 9600.
-
- A new meaning for field 7 as speed field could be really useful.
- An example is ZYX, if we would have 16800, 19200, 28800, and 33600
- as speed values, then their combination with ZYX is all we need
- technically, Z19 would be unnecessary. Another example is HST,
- flags H14 and H16 are unnecessary, if HST is combined with 9600,
- 14400, 16800, 28800, or better. Variants of PEP could be shown in
- the speed field without new flags. "Enhanced V32.terbo" could be
- shown by 21600.
-
- Most important: V34 may have the famous bug not allowing connects
- from new "V34+", unless the caller disabled symbol rate 3429. If
- "V34+" is indicated by speed 33600 or better, then an appropriate
- setup for all kinds of V34 connects is possible.
-
- A future version of FTS-0005 hopefully allows the following speed
- values in field 7:
-
- 300 reserved for ISDN or IP only (for historical reasons)
- 1200 obsolete (either V.22 in Z2 / Z3, or Bell 212A in Z1)
- 2400 implies V22bis, qualifies as least common denominator
- 9600 default, used with PEP, V32, HST, H96, (CSP), (MAX)
- 12000 rare variant of V32
- 14400 used with V32b or HST (obsoleting H14)
- 16800 used with ZYX or HST (obsoleting H16)
- 19200 used with V32T or ZYX (obsoleting Z19)
- 21600 rare variant of V32T (no "H21" needed)
- 28800 used with VFC or V34
- 33600 used with V34 (no V34+ or V34b needed)
-| 56000 used with X2C, X2S, or V.PCM
-
- Allowing more than 12 speed values or allowing speed values above
- 64000 could break existing software (MakeNL, V7). Therefore the
- next step in FidoNet could be, to add 12000, 14400, 16800, 19200,
- 21600, 28800, 33600, and 56000, where 19200 is already specified
- in FTS-5 since 1989.
-
-
-8. Thanks to...
----------------
- Ben Baker St. Louis nodelist format
- Rick Moore FTS-0005.TXT
- David Nugent FTS-0005.003 and NLTOOLS
- Jonny Bergdahl ERRFLAGS 2.6
- Ward Dossche Zone 2 nodelist epilogue
- David J. Thomas FSC-0062.003 (FRL-0062)
- Jan Ceuleers FSC-0075.001 (FRL-0075)
- Arjen Lentz FSC-0091.001 (FRL-0091)
- Leonard Erickson CHECKNL 2.14 and many discussions in NET_DEV
- Jim Barchuk LNDL 2.7
- Marius Ellen FASTV7 2.04
-| Jan Vermeulen, Ian Smith, Gisbert Rudolph, Carlos Fernandez Sanz,
-| Tom Schlangen, Craig Ford, Pedro Lima, and many others...
-
-
-**********************************************************************
-
-
- Go Back
-
-
-
-
+
+
+
+Zone 2 nodelist flags.
+
+
+
+
+
+**********************************************************************
+FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
+**********************************************************************
+
+Publication: FSP-1005
+Revision: 6
+Title: Zone 2 nodelist flags
+Author: Frank Ellermann, 2:240/5815.1
+Revision Date: 27 November 1997
+Expiry Date: 27 November 1999
+---------------------------------------------------------------------
+Contents:
+ 1. Introduction
+ 2. FTS-0005 flags
+ 3. User flags
+ 4. Approved zone 2 user flags
+ 5. Flag implications
+ 6. Invalid combinations
+ 7. Baud rate field
+ 8. Thanks to...
+---------------------------------------------------------------------
+
+
+1. Introduction
+---------------
+ This document informs about known differences of FidoNet zone 2
+ nodelist flags from FTS-0005.003. The ultimate sources for these
+ informations are the current Z2 nodelist epilogue and the setup
+ for flag corrections at Z2C, but it may be difficult to get these
+ sources for readers in other zones.
+
+| All changes since version 5 are marked by a bar at the left edge.
+ It is (again) possible to list V32b and V42b in zone 2, upper case
+ V32B or V42B is not more enforced. Currently new flags needed for
+ IP-connectivity are under test in zone 2 (only internally), e.g.
+
+ -> VM VModem, default port 3141, dummy country code 000-
+ -> IFC IFCico, default port 60179, dummy country code 000-
+ -> BND BinkP, default port 24544, dummy country code 000-
+ -> IP general IP connectivity, dummy country code 000-
+ -> TELN Telnet dummy country code 000-
+
+
+2. FTS-0005 flags
+-----------------
+ The following flags are used as specified in FTS-0005.003:
+
+ CM Continuous Mail, node accepts mail 24 hours a day
+ MO Mailer Only (no BBS)
+ LO Listed Only, node accepts calls only from listed
+ node numbers in the current FidoNet nodelist
+
+ -> V21 ITU-T V21 300 bps full duplex (obsolete)
+ V22 ITU-T V22 1200 bps full duplex (obsolescent)
+
+| In zone 2 the value 1200 in the baud rate field implies V22. Only
+| two nodes not supporting at least V22bis, ISDN, or IP still exist
+| in the zone 2 segment. Flag V22 is almost obsolete, and V21 is
+| already removed in Z2. Both flags should be dropped from the next
+| FTS-0005 version.
+
+ V29 ITU-T V29 9600 bps half duplex (obsolescent)
+ -> V33 ITU-T V33 14400 bps half duplex (obsolete)
+
+ V33 cannot be used in connecting FidoNet nodes over public dial-up
+ lines and is most probably a historical error in FTS-0005. A very
+ similar argument is applicable on V29, all nodes flying this flag
+ support at least V32. Today only one node in Z2 still flies V29,
+ and V33 is already removed in Z2. Both flags should be dropped in
+ the next FTS-0005 version.
+
+ V32 ITU-T V32 9600 bps full duplex
+ V32b ITU-T V32bis 14400 bps full duplex (implies V32)
+| V34 ITU-T V34 28800 bps full duplex (33600 bps option)
+
+ FTS-0005 specifies V32b and V42b (capital V and small b), current
+ nodelist practice in FidoNet shows all combinations of small and
+ capital letters for flags. This was no problem before FSC-0062
+ introduced case-sensitive flags. The best solution is to stick to
+ the current practice and treat all old flags as case-insensitive.
+
+ H96 Hayes V9600
+ HST USR Courier HST up to 9600 (implies MNP)
+ H14 USR Courier HST up to 14400 (implies HST)
+ -> H16 USR Courier HST up to 16800 (implies H14 and V42b)
+ MAX Microcom AX/96xx series (almost obsolete)
+ PEP Packet Ensemble Protocol
+ CSP Compucom Speedmodem
+ -> ZYX Zyxel series 16800 bps (implies V32b and V42b)
+ -> V32T V.32 Terbo 19200 bps (implies V32b)
+ VFC V.Fast Class 28800 bps (should imply V32b and V42b)
+
+ If a flag directly or indirectly implies other flags, then these
+ other flags are not shown in a nodelist entry, because this would
+ be redundant. Unfortunately the rules for redundancies in zone 2
+ and FTS-0005 are different. Zone 2 continued to avoid redundancy
+ with most "new" flags, but FTS-0005.003 specified no redundancies
+ for "new" flags like ZYX, H16, V32T, or VFC. "New" flags in this
+ context are flags approved by FidoNet International Coordinators
+ since 1989, when FTS-0005.TXT, the predecesssor of FTS-0005.003,
+ was published.
+
+ For details see the chapter "implications" below, for now only
+ note, that in zone 2 H16 implies V42b, ZYX implies V32b and V42b,
+ and V32T implies V32b.
+
+ Zone 1 and zone 2 have introduced a user flag Z19 approved by the
+ corresponding Zone Coordinator. User flags are discussed later,
+ for now only note, that in zone 2 ZYX is specified as Zyxel 16k8,
+ while FTS-0005.003 not knowing Z19 specifies ZYX as generic flag
+ for all Zyxel protocol speeds.
+
+ Today only one node in FidoNet still really flies MAX, this flag
+ is obsolete and should be dropped from FTS-0005. The flags CSP
+ (7 nodes worldwide) and H96 should be marked as obsolescent.
+
+| MNP Microcom Networking Protocol 2-4 error correction
+| V42 ITU-T LAP-M error correction w/ fallback to MNP 2-4
+| V42b ITU-T V.42bis BTLZ data compression over V.42 LAP-M
+
+ The next version of FTS-0005 should adopt the better V42b and
+ MNP definitions of the zone 3 nodelist epilogue. FTS-0005.003
+ specifies an implication of V42 by V42b, but the exact meaning of
+ the flag MNP is unclear. Most probably this flag was meant to
+| indicate support of MNP 2-4, and in this sense V42 implies MNP.
+
+| Note the difference between the flag V42b (implying V42) and the
+| standard V.42bis (not necessarily based on LAP-M as data link
+| layer protocol), without this difference the flag V42b would be
+| ambiguous for combined modem and ISDN node entries.
+
+ MN No compression supported in insecure inbound
+
+ XA Bark and WaZOO file/update requests
+ XB Bark file/update requests, WaZOO file requests
+ XC Bark file requests, WaZOO file/update requests
+ XP Bark file/update requests
+ XR Bark and WaZOO file requests
+ XW WaZOO file requests
+ XX WaZOO file/update requests
+
+ These flags are equivalent in FTS-0005 and in the zone 2 segment.
+
+ Gx..x Gateway to domain 'x..x'
+
+ Valid values for this flag are assigned by the Fido International
+ Coordinator, FTS-0005.003 explicitly mentions GUUCP. In zone 2
+ only GUUCP gateways are flagged.
+
+ #01 Zone 5 mail hour (01:00 - 02:00 UTC) w/ Bell 212A
+ #02 Zone 2 mail hour (02:30 - 03:30 UTC) w/ Bell 212A
+ -> #08 Zone 4 mail hour (08:00 - 09:00 UTC) w/ Bell 212A
+ #09 Zone 1 mail hour (09:00 - 10:00 UTC) w/ Bell 212A
+ #18 Zone 3 mail hour (18:00 - 19:00 UTC) w/ Bell 212A
+ #20 Zone 6 mail hour (20:00 - 21:00 UTC) w/ Bell 212A
+
+ The variants !01, !02, !08, !09, !18, and !20 indicate missing
+ Bell 212A support. In zone 2 #02 or !02 would be obviously
+ redundant.
+
+ Today less than four 1200 modems (V22 or Bell 212A) are listed.
+ A future version of FTS-0005 should drop !mn variants together
+ with V21 and V22 flags.
+
+ Further most non-CM systems flagging #mn or !mn today probably
+ want to show additional online times instead of additional mail
+ hours. As soon as FSC-0062 flags have been approved by the IC
+ or adopted as FTS by the FTSC, the following version of FTS-0005
+ should mark #mn as obsolescent and recommend the more flexible
+ FSC-0062 flags (see below).
+
+
+3. User flags
+-------------
+ An example for one of several problems in zone 2 with user flags:
+
+ ...,U,Z19,V110H,V120L,V120H,X75,ENC,NEC
+
+ These flags indicate a modern Zyxel ISDN-modem and two additional
+ user flags ENC and NEC. This possible user flags string contains
+ 34 characters, but at most 32 characters are allowed in FTS-0005.
+
+ ...,U,Z19,V110L,V110H,X75,ISDNA,ISDNB,ISDNC
+
+ During the period for the replacement of old by new ISDN flags
+ (several months !) many nodes listed both old and new flags for
+ maximal compatibility, and no problems with nodelist compilers
+ or mailers caused by too long user flags strings were reported.
+
+ Therefore the length limit in FTS-0005 is probably unnecessary
+ and at least inconsequent: Other nodelist fields like the system
+ name are unlimited, so why only restrict the user flags string ?
+ To help developpers an upper limit of e.g. 255 characters for a
+ nodelist line and 63 characters for fields 3 to 6 would be more
+ useful.
+
+ The next problem with user flag strings as specified in FTS-0005
+ is their introduction by the letter U with no comma following:
+
+ Nodelist compilers could parse ...,UISDN,USR in user flags ISDN
+ and USR. But USR cannot be approved as "real" flag, because the
+ combination ...,USR,UISDN would then be parsed in SR and UISDN.
+
+ Other side effects of the FTS-0005 specification are additional
+ difficulties in finding flags. Almost all flags are separated
+ by a comma, only the first user flag can be an exception to this
+ simple rule. If the order of user flags has no meaning, then...
+
+ ...,UV120L,V120H
+ ...,UV120H,V120L
+
+ ... are equivalent. A "simple" solution of this problem could be
+ to treat UV120L as synonym for V120L, and UV120H as synonym for
+ V120H. Similar problems show up, if user flags are counted, etc.
+
+ Obviously a nodelist compiler looking for user flags has always
+ to consider the case "user flag separated by comma". In zone 2
+ this idea was simply extended to the first user flag:
+
+ All flags are separated by commas. Flags not yet approved by the
+ International Coordinator or the FTSC (i.e. user flags only used
+ experimentally or locally) are separated by a new pseudo flag U.
+
+ -> U pseudo flag to the left of at least one user flag
+
+ All flags following this pseudo flag U are user flags, all flags
+ before this pseudo flag are "real" flags specified in FTS-0005 or
+ approved by the International Coordinator.
+
+ Because this definition should be compatible with any reasonable
+ software implementation based on FTS-0005.003, and simplifies the
+ handling of user flags significantly, a future FTS-0005 version
+ will hopefully adopt it.
+
+
+4. Approved zone 2 user flags
+-----------------------------
+ In zone 2 user flags have to be approved by the Zone Coordinator.
+ Currently the following zone 2 user flags exist:
+
+ -> V110L ITU-T V.110 19k2 async 'Low' (former ISDNA)
+ -> V110H ITU-T V.110 38k4 async 'High' (former ISDNB)
+ -> V120L ITU-T V.120 56k6 async, N1 = 259, W = 7, modulo 8
+ -> V120H ITU-T V.120 64k async, N1 = 259, W = 7, modulo 8
+ -> X75 ITU-T X.75 SLP (single link procedure),
+ 64kbit/s B channel; layer 2 max. framesize N1 = 2048,
+ window size W = 2, frame numbering modulo 8;
+ layer 3 transparent (no packet layer)
+ -> ISDN Other configuration, used only if none of above fits
+
+ These ISDN flags follow the specification in FSC-0091.
+
+ -> Tyz Online time flags as specified in FSC-0062
+
+ 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 20:00, w 20:30, X 23:00, x 23:30.
+
+ For example TuB shows an online period from 20:30 until 1:00 UTC.
+
+ -> Z19 Zyxel series 19200 bps (implies ZYX)
+ -> X2C x2 client w/ 56000 bps (should imply V34 and V42b)
+ -> X2S x2 server w/ 64000 bps (should imply V34 and V42b)
+
+ -> K12 Systems offering all educational K12-conferences
+ -> ENC The node accepts inbound encrypted mail
+
+ -> NC Network Coordinator (only if the NC is not the host)
+ -> NEC Net Echomail Coordinator (at most one per net)
+ -> REC Region Echomail Coordinator (at most one per region)
+
+ Redundant AKAs used to indicate echomail coordination in zone 2
+ are no longer permitted. One *EC flag is valid for all AKAs of
+ a given sysop.
+
+
+5. Flag implications
+--------------------
+ Flag implications directly or indirectly specified in FTS-0005:
+
+ HST => MNP
+ H14 => MNP HST
+ H16 => MNP HST H14
+ V42b => V42 (MNP ?)
+ V32b => V32
+
+ Flag implications specified in the zone 2 nodelist epilogue:
+
+ HST => MNP
+ H14 => HST MNP
+ -> H16 => V42 MNP V42b H14 HST
+ -> V42b => V42 MNP
+ -> ZYX => V42 MNP V42b V32 V32b
+ -> Z19 => V42 MNP V42b V32 V32b ZYX
+ V32b => V32
+ -> V32T => V32 V32b
+
+ -> V110L => ISDN
+ -> V110H => ISDN
+ -> V120L => ISDN
+ -> V120H => ISDN
+ -> X75 => ISDN
+
+ The latter ISDN flag redundancies are a consequence of FSC-0091.
+ Maybe some of the following implications could be added in zone 2:
+
+ VFC => V32 V32b MNP V42 V42b
+ X2C => V34 MNP V42 V42b
+ X2S => V34 MNP V42 V42b
+
+ Flag implications (i.e. not listing redundant flags) have several
+ advantages: Some old nodelist tools are unable to handle too long
+ lines. Old flags like HST, MNP, V42, or V32 vanish automatically,
+ if they are implied by H16, V42b, V32b, or better. Redundancies
+ defined globally for the whole nodelist help to avoid flag errors.
+
+
+6. Invalid combinations
+-----------------------
+ All file request flags exclude each other (at most 1 is possible):
+ XA, XB, XC, XP, XR, XW, and XX. For flag checkers only supporting
+ implications a good approximation based on FTS-0005 definitions is
+
+| XA => XW XR XP XB XC XX,
+| XB => XW XR XP,
+| XC => XW XR XX,
+| XR => XW,
+| XX => XW.
+
+ Further X2C cannot be combined with X2S, and FSC-62 Tyz-flags are
+ not possible with CM. Also Tyz with y = z is of course incorrect.
+
+ Some modem protocols are "proprietary" in a sense, that all today
+ known modems can fly at most one of the corresponding modem flags:
+ MAX, CSP, H96, PEP, HST, H14, H16, ZYX, and Z19.
+
+ A few "old" modem protocol flags are known to be invalid if used
+ together with "new" protocol flags, i.e. each "old" flag excludes
+ all "new" flags and vice versa:
+
+ "Old" in this sense are MAX, CSP, H96, HST, H14, V32, and PEP.
+ "New" in this sense are X2S, X2C, V34, VFC, V32T, and H16.
+
+ For Z2 add ZYX as "old" and Z19 as "new". A simple REXX script to
+ test some known inconsistencies is available as NLSCHECK.REX at
+ the site of the author. While erroneously listing redundant flags
+ causes no harm, other errors like combining V34 with HST or Z19
+ with H16 indicate serious problems, which can result in connection
+ failures or other damage.
+
+
+7. Baud rate field
+------------------
+ The baud rate field 7 in the nodelist as specified in FTS-0005 is
+ nearly useless today: Except from a few remaining 1200 and 2400
+ nodes almost all nodelist entries show either 9600 for all modem
+ protocols better than V22bis or 300 for ISDN (or IP) only nodes.
+ No more V21 or Bell 103 modems are listed for more than 2 years.
+
+ The baud rate values 19200 and 38400 specified in FTS-0005.003
+ have not been used in the FidoNet nodelist. So all a reasonable
+ nodelist compiler can do today, is treat 300 as indicator for
+ ISDN or IP only, and treat unknown or missing values in field 7
+ like 9600.
+
+ A new meaning for field 7 as speed field could be really useful.
+ An example is ZYX, if we would have 16800, 19200, 28800, and 33600
+ as speed values, then their combination with ZYX is all we need
+ technically, Z19 would be unnecessary. Another example is HST,
+ flags H14 and H16 are unnecessary, if HST is combined with 9600,
+ 14400, 16800, 28800, or better. Variants of PEP could be shown in
+ the speed field without new flags. "Enhanced V32.terbo" could be
+ shown by 21600.
+
+ Most important: V34 may have the famous bug not allowing connects
+ from new "V34+", unless the caller disabled symbol rate 3429. If
+ "V34+" is indicated by speed 33600 or better, then an appropriate
+ setup for all kinds of V34 connects is possible.
+
+ A future version of FTS-0005 hopefully allows the following speed
+ values in field 7:
+
+ 300 reserved for ISDN or IP only (for historical reasons)
+ 1200 obsolete (either V.22 in Z2 / Z3, or Bell 212A in Z1)
+ 2400 implies V22bis, qualifies as least common denominator
+ 9600 default, used with PEP, V32, HST, H96, (CSP), (MAX)
+ 12000 rare variant of V32
+ 14400 used with V32b or HST (obsoleting H14)
+ 16800 used with ZYX or HST (obsoleting H16)
+ 19200 used with V32T or ZYX (obsoleting Z19)
+ 21600 rare variant of V32T (no "H21" needed)
+ 28800 used with VFC or V34
+ 33600 used with V34 (no V34+ or V34b needed)
+| 56000 used with X2C, X2S, or V.PCM
+
+ Allowing more than 12 speed values or allowing speed values above
+ 64000 could break existing software (MakeNL, V7). Therefore the
+ next step in FidoNet could be, to add 12000, 14400, 16800, 19200,
+ 21600, 28800, 33600, and 56000, where 19200 is already specified
+ in FTS-5 since 1989.
+
+
+8. Thanks to...
+---------------
+ Ben Baker St. Louis nodelist format
+ Rick Moore FTS-0005.TXT
+ David Nugent FTS-0005.003 and NLTOOLS
+ Jonny Bergdahl ERRFLAGS 2.6
+ Ward Dossche Zone 2 nodelist epilogue
+ David J. Thomas FSC-0062.003 (FRL-0062)
+ Jan Ceuleers FSC-0075.001 (FRL-0075)
+ Arjen Lentz FSC-0091.001 (FRL-0091)
+ Leonard Erickson CHECKNL 2.14 and many discussions in NET_DEV
+ Jim Barchuk LNDL 2.7
+ Marius Ellen FASTV7 2.04
+| Jan Vermeulen, Ian Smith, Gisbert Rudolph, Carlos Fernandez Sanz,
+| Tom Schlangen, Craig Ford, Pedro Lima, and many others...
+
+
+**********************************************************************
+
-**********************************************************************
-FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication: FSP-1006
-Revision: 1
-Title: Kludge for specifying addition e-mail reply addresses
-Author: Ramon van der Winkel, 1:320/42.46
- ramon@wsd.wline.se
-Revision Date: 12 December 1997
-Expiry Date: 12 December 1999
-----------------------------------------------------------------------
-Contents:
- 1. Scope
- 2. Background
- 3. Format
- 4. Implementation notes
- 5. Example
-----------------------------------------------------------------------
-
-
-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
---------
-
- An Internet message can have several reply addresses. After gating
- to FidoNet, the recipient is only presented with one of the reply
- addresses. The others are lost. This is a suggestion for an
- additional kludge to FSC-0035 to change that.
-
-
-1. Scope
---------
-
- This standard is specified for FTN netmail messages sent by a
- FidoNet-to-Internet gateway to a recipient. Message editors will
- have to support this to allow the user to select the reply address
- to use.
-
-
-2. Background
--------------
-
- An Internet message has three headers to indicate where to send a
- reply. These are, in order of priority, Reply-To:, Sender: and
- From:. When a message is distributed by a mailing list, then one of
- the headers could contain the e-mail address of the poster and one
- of the other headers the address of the mailing list.
-
- When the message is gated to FidoNet, the gateway currently selects
- of the reply addresses and creates the message so that a reply will
- return at the gateway and sent to this one address. The other
- addresses are lost.
-
- The FSC-0035 kludges REPLYTO and REPLYADDR allow for one return
- address only. This is a proposal for an additional kludge inserted
- by the gateway to specify an addtional reply address. The message
- editor used by the recipient will present a list of all reply
- addresses and allows the user to select the appropriate address.
-
- This way, the user can send a message back to the mailing list (for
- distribution), or to the e-mail address of the poster only.
-
-
-3. Format
----------
-
- Following the REPLYTO and REPLYADDR kludges, one or more kludges
- with the name REPLYALSO can be inserted, each listing one possible
- reply address.
-
- @REPLYALSO
-
- Where is in the form of
-
- ramon@wsd.wline.se
- or
- wsd.wline.se!ramon
-
- Each line MUST contain one address only.
-
-
-4. Implementation notes
------------------------
-
- Gateways supporting the REPLYALSO kludge MUST put the the reply
- address with the highest priority in the REPLYADDR kludge. The order
- of priority is Reply-To:, Sender: and From: header. The other
- addresses may be listed in any priority.
-
-
-5. Example
-----------
-
- From: odinn@goldware.dk, 1:320/42
- To: Ramon van der Winkel, 1:320/42.46
- Subj: Another test
- ---------------------------------------
- @INTL 1:320/42 1:320/42
- @TOPT 46
- @MSGID: wgmid$<123455@goldware.dk> 45AB23CD
- @REPLYTO UUCP 1:320/42
- @REPLYADDR odinn@goldware.dk
- @REPLYALSO newftsc-l@brazerko.com
- This message was distributed by the mailing list "New FTSC"
- at brazerko.com.
-
- ...
-
-
-A. Author contact data
-----------------------
-
- Ramon van der Winkel
- Fidonet: 1:320/42.46
- E-mail: ramon@wsd.wline.se
- WWW: http://www2.sbbs.se/hp/ramon
-
-
-B. History
-----------
-
- Rev.1, 971212: First release.
-
-
-**********************************************************************
-
-
- Go Back
-
-
-
-
+
+
+
+Kludge for specifying addition e-mail reply addresses.
+
+
+
+
+
+**********************************************************************
+FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
+**********************************************************************
+
+Publication: FSP-1006
+Revision: 1
+Title: Kludge for specifying addition e-mail reply addresses
+Author: Ramon van der Winkel, 1:320/42.46
+ ramon@wsd.wline.se
+Revision Date: 12 December 1997
+Expiry Date: 12 December 1999
+----------------------------------------------------------------------
+Contents:
+ 1. Scope
+ 2. Background
+ 3. Format
+ 4. Implementation notes
+ 5. Example
+----------------------------------------------------------------------
+
+
+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
+--------
+
+ An Internet message can have several reply addresses. After gating
+ to FidoNet, the recipient is only presented with one of the reply
+ addresses. The others are lost. This is a suggestion for an
+ additional kludge to FSC-0035 to change that.
+
+
+1. Scope
+--------
+
+ This standard is specified for FTN netmail messages sent by a
+ FidoNet-to-Internet gateway to a recipient. Message editors will
+ have to support this to allow the user to select the reply address
+ to use.
+
+
+2. Background
+-------------
+
+ An Internet message has three headers to indicate where to send a
+ reply. These are, in order of priority, Reply-To:, Sender: and
+ From:. When a message is distributed by a mailing list, then one of
+ the headers could contain the e-mail address of the poster and one
+ of the other headers the address of the mailing list.
+
+ When the message is gated to FidoNet, the gateway currently selects
+ of the reply addresses and creates the message so that a reply will
+ return at the gateway and sent to this one address. The other
+ addresses are lost.
+
+ The FSC-0035 kludges REPLYTO and REPLYADDR allow for one return
+ address only. This is a proposal for an additional kludge inserted
+ by the gateway to specify an addtional reply address. The message
+ editor used by the recipient will present a list of all reply
+ addresses and allows the user to select the appropriate address.
+
+ This way, the user can send a message back to the mailing list (for
+ distribution), or to the e-mail address of the poster only.
+
+
+3. Format
+---------
+
+ Following the REPLYTO and REPLYADDR kludges, one or more kludges
+ with the name REPLYALSO can be inserted, each listing one possible
+ reply address.
+
+ @REPLYALSO <e-mail address>
+
+ Where <e-mail address> is in the form of
+
+ ramon@wsd.wline.se
+ or
+ wsd.wline.se!ramon
+
+ Each line MUST contain one address only.
+
+
+4. Implementation notes
+-----------------------
+
+ Gateways supporting the REPLYALSO kludge MUST put the the reply
+ address with the highest priority in the REPLYADDR kludge. The order
+ of priority is Reply-To:, Sender: and From: header. The other
+ addresses may be listed in any priority.
+
+
+5. Example
+----------
+
+ From: odinn@goldware.dk, 1:320/42
+ To: Ramon van der Winkel, 1:320/42.46
+ Subj: Another test
+ ---------------------------------------
+ @INTL 1:320/42 1:320/42
+ @TOPT 46
+ @MSGID: wgmid$<123455@goldware.dk> 45AB23CD
+ @REPLYTO UUCP 1:320/42
+ @REPLYADDR odinn@goldware.dk
+ @REPLYALSO newftsc-l@brazerko.com
+ This message was distributed by the mailing list "New FTSC"
+ at brazerko.com.
+
+ ...
+
+
+A. Author contact data
+----------------------
+
+ Ramon van der Winkel
+ Fidonet: 1:320/42.46
+ E-mail: ramon@wsd.wline.se
+ WWW: http://www2.sbbs.se/hp/ramon
+
+
+B. History
+----------
+
+ Rev.1, 971212: First release.
+
+
+**********************************************************************
+
-**********************************************************************
-FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication: FSP-1007
-Revision: 1
-Title: Multiple recipient address specification to gateway
-Author: Ramon van der Winkel, 1:320/42.46
- ramon@wsd.wline.se
-Revision Date: 12 December 1997
-Expiry Date: 12 December 1999
-----------------------------------------------------------------------
-Contents:
- 1. Scope
- 2. Background
- 3. Format
- 4. Implementation notes for gateways
- 5. Example
-----------------------------------------------------------------------
-
-
-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
---------
-
- Private messages within FidoNet only have one recipient address.
- Multiple copies of the same message have to be sent to a FidoNet-
- to-Internet gateway in order to address multiple recipients. This is
- a proposal to indicate the addresses of multiple recipients in the
- body of the message sent to the gateway.
-
-
-1. Scope
---------
-
- This standard is specified for FTN netmail messages sent to a
- FidoNet-to-Internet gateway. Users are able to add this information
- manually, although message editors could support this and make it
- transparent to the user.
-
-
-2. Background
--------------
-
- Three types of recipient addresses can be specified on the Internet
- and are reflected in this suggestion: To, Cc and Bcc. "To" are the
- primary recipient(s) of the message. "Cc" is short for Carbon Copy
- and lists the recipients that are intended to receive the message as
- "informational". The last option "Bcc" is short for Blind Carbon
- Copy. Recipients lists as Bcc recipients will not show up in the
- headers of the Internet message, but get a copy anyway.
-
-
-3. Format
----------
-
- Immediately following the kludge lines, one or more of the following
- lines can be inserted in the message. If a To: line is present, then
- these lines follow the To: line.
-
- GW-To: [,[...]]
- GW-Cc: [,[...]]
- GW-Bcc: [,[...]]
-
- Where is in the form of
-
- ramon@wsd.wline.se
- or
- wsd.wline.se!ramon
-
- Multiple addresses can be specified on the same line, separated by a
- comma with optionally spaces around the comma. There is no limit
- regarding the length of the line. The line must be terminated by a
- single carriage return.
-
- The GW-To: line replaces the To: lines.
-
- The reason for GW-Cc is that "Cc:" by itself is expanded by some
- editors and used to generate multiple copies of a message.
-
-
-4. Implementation notes for gateways
-------------------------------------
-
- Gateways supporting this format add the e-mail addresses mentioned
- in any of these three headers to the envelope file and create on
- outbound (probably UUCP or SMTP) body text message. Rules for the
- maximum length of envelope files (if any) apply.
-
- The headers section of the RFC822 message will list the e-mail
- addresses under the To: and Cc: headers. A Bcc: header must not be
- added!
-
-
-5. Example
-----------
-
- From: Ramon van der Winkel, 1:320/42.46
- To: UUCP, 1:320/42
- Subj: New header test
- ---------------------------------------
- @INTL 1:320/42 1:320/42
- @FMPT 46
- GW-To: groupElist@newftsc.org
- GW-Cc: odinn@goldware.dk
- GW-Bcc: groupAadmin@newftsc.org
- Hi!
-
- This is a test
-
- Ramon
-
-
-A. Author contact data
-----------------------
-
- Ramon van der Winkel
- Fidonet: 1:320/42.46
- E-mail: ramon@wsd.wline.se
- WWW: http://www2.sbbs.se/hp/ramon
-
-
-B. History
-----------
-
- Rev.1, 971212: First release.
-
-
-**********************************************************************
-
-
- Go Back
-
-
-
-
+
+
+
+Multiple recipient address specification to gateway.
+
+
+
+
+
+**********************************************************************
+FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
+**********************************************************************
+
+Publication: FSP-1007
+Revision: 1
+Title: Multiple recipient address specification to gateway
+Author: Ramon van der Winkel, 1:320/42.46
+ ramon@wsd.wline.se
+Revision Date: 12 December 1997
+Expiry Date: 12 December 1999
+----------------------------------------------------------------------
+Contents:
+ 1. Scope
+ 2. Background
+ 3. Format
+ 4. Implementation notes for gateways
+ 5. Example
+----------------------------------------------------------------------
+
+
+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
+--------
+
+ Private messages within FidoNet only have one recipient address.
+ Multiple copies of the same message have to be sent to a FidoNet-
+ to-Internet gateway in order to address multiple recipients. This is
+ a proposal to indicate the addresses of multiple recipients in the
+ body of the message sent to the gateway.
+
+
+1. Scope
+--------
+
+ This standard is specified for FTN netmail messages sent to a
+ FidoNet-to-Internet gateway. Users are able to add this information
+ manually, although message editors could support this and make it
+ transparent to the user.
+
+
+2. Background
+-------------
+
+ Three types of recipient addresses can be specified on the Internet
+ and are reflected in this suggestion: To, Cc and Bcc. "To" are the
+ primary recipient(s) of the message. "Cc" is short for Carbon Copy
+ and lists the recipients that are intended to receive the message as
+ "informational". The last option "Bcc" is short for Blind Carbon
+ Copy. Recipients lists as Bcc recipients will not show up in the
+ headers of the Internet message, but get a copy anyway.
+
+
+3. Format
+---------
+
+ Immediately following the kludge lines, one or more of the following
+ lines can be inserted in the message. If a To: line is present, then
+ these lines follow the To: line.
+
+ GW-To: <e-mail address>[,<e-mail address>[...]]
+ GW-Cc: <e-mail address>[,<e-mail address>[...]]
+ GW-Bcc: <e-mail address>[,<e-mail address>[...]]
+
+ Where <e-mail address> is in the form of
+
+ ramon@wsd.wline.se
+ or
+ wsd.wline.se!ramon
+
+ Multiple addresses can be specified on the same line, separated by a
+ comma with optionally spaces around the comma. There is no limit
+ regarding the length of the line. The line must be terminated by a
+ single carriage return.
+
+ The GW-To: line replaces the To: lines.
+
+ The reason for GW-Cc is that "Cc:" by itself is expanded by some
+ editors and used to generate multiple copies of a message.
+
+
+4. Implementation notes for gateways
+------------------------------------
+
+ Gateways supporting this format add the e-mail addresses mentioned
+ in any of these three headers to the envelope file and create on
+ outbound (probably UUCP or SMTP) body text message. Rules for the
+ maximum length of envelope files (if any) apply.
+
+ The headers section of the RFC822 message will list the e-mail
+ addresses under the To: and Cc: headers. A Bcc: header must not be
+ added!
+
+
+5. Example
+----------
+
+ From: Ramon van der Winkel, 1:320/42.46
+ To: UUCP, 1:320/42
+ Subj: New header test
+ ---------------------------------------
+ @INTL 1:320/42 1:320/42
+ @FMPT 46
+ GW-To: groupElist@newftsc.org
+ GW-Cc: odinn@goldware.dk
+ GW-Bcc: groupAadmin@newftsc.org
+ Hi!
+
+ This is a test
+
+ Ramon
+
+
+A. Author contact data
+----------------------
+
+ Ramon van der Winkel
+ Fidonet: 1:320/42.46
+ E-mail: ramon@wsd.wline.se
+ WWW: http://www2.sbbs.se/hp/ramon
+
+
+B. History
+----------
+
+ Rev.1, 971212: First release.
+
+
+**********************************************************************
+
+
+Go Back
+
+
+
+
diff --git a/html/ftsc/fsp-1008.html b/html/ftsc/fsp-1008.html
index ba98118d..0eedb418 100755
--- a/html/ftsc/fsp-1008.html
+++ b/html/ftsc/fsp-1008.html
@@ -1,275 +1,276 @@
-
-
-New control lines for forwarding messages.
-
-
-
-
-
-**********************************************************************
-FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication: FSP-1008
-Revision: 2
-Title: New control lines for forwarded messages
-Author: Michael Hohner, 2:2490/2520.17
-Revision Date: 29 December 1997
-Expiry Date: 29 December 1999
-----------------------------------------------------------------------
-Contents:
- 1. Specifications
- 2. Usage
- 3. Compatiblity
- 4. Known implementations
-----------------------------------------------------------------------
-
-
-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.
-
- This revision is an update to FRL-0092.001. The basic specifications
- are unchanged.
-
-
-Abstract
---------
-
- Most fidonet message editors offer a "forward" function. Using this
- function a user A ("forwarder") can sort of "redirect" a message
- from user B ("author") to another user C ("final recipient"), maybe
- because the forwarder is not the correct recipient, or because the
- final recipient is a better person to answer the message. The name
- and address of the author are usually included in the forward in
- free-text format. The message text is included in non-quoted format.
-
- A problem arises when the final recipient wants to reply to the
- author of the forwarded message. The forward contains the forwarder
- as the sender. So the final recipient must insert the name and
- address of the author manually, using the information contained in
- the message text. The message editor of the final recipient can't do
- this automatically because of the free-text format. The editor will
- also use incorrect quote initials, which is at least irritating.
-
- This document introduces 7 new control lines which contain the
- header information of the original message. With these control lines
- the message editor can use the original header information
- automatically.
-
-
-1. Specifications
------------------
-
- There are 7 new control lines: FWDFROM, FWDTO, FWDORIG, FWDDEST,
- FWDSUBJ, FWDAREA, FWDMSGID. As all control lines they start with an
- ASCII 01 character (SOH) followed by the control line name followed
- by whitespace followed by the control line's content followed by
- ASCII 13 (CR).
-
- Please note that all these control lines do not have a colon (like
- the control lines in FTS-0001). This would be just waste of space.
-
- FWDFROM
- -------
-
- This control line contains the name of the original sender as found
- in the FROM field of the original message. Leading and trailing
- whitespace should be removed. This control line should be omitted
- altogether if the FROM field is empty.
-
- FWDTO
- -----
-
- This control line contains the name of the original recipient as
- found in the TO field of the original message. Leading and trailing
- whitespace should be removed. This control line should be omitted
- altogether if the TO field is empty.
-
- FWDORIG
- -------
-
- This control line contains the address of the original sender as
- found in the ORIG field of the original message. The usual 5D ASCII
- notation (zone:net/node.point@domain) should be used. This control
- line should be omitted altogether if the address is not known.
-
- FWDDEST
- -------
-
- This control line contains the address of the original recipient as
- found in the DEST field of the original message. The usual 5D ASCII
- notation (zone:net/node.point@domain) should be used. This control
- line should be omitted altogether if the address is not known or
- unsure (as it is the case with forwarded echomail messages).
-
- FWDSUBJ
- -------
-
- This control line contains the subject line of the original message.
- This control line should be omitted altogether if the SUBJ field is
- empty.
-
- This control line should by made optional for security reasons. Echo
- manager passwords are too easily revealed with it.
-
- FWDAREA
- -------
-
- This control line contains the name of the echomail area where the
- original message was forwarded from. It should be omitted altogether
- if the original message was not forwarded from an echomail area.
-
- FWDMSGID
- --------
-
- This control line contains the MSGID control line of the original
- message. It should be omitted altogether if a MSGID control line is
- not present in the original message.
-
-
-2. Usage
---------
-
- When the "forward" function of the message editor is invoked, the
- editor program should generate the proposed control lines from the
- header of the original message. If the original message already was
- a forwarded one (indicated by the presence of at least a FWDORIG
- control line), the editor should keep all FWD* control lines and
- should not add any FWD* control lines. This preserves the FWD*
- control lines of the first forwarder, containing the header data of
- the author of the original message.
-
- The editor should not generate FWD* control lines, if the message
- isn't to be forwarded. A mail forwarding robot may also generate
- these control lines, if it not just readdresses the message.
-
- When the "reply" function of the editor is invoked the program
- should use the control lines' contents instead of the header
- information. The control lines should not be included in the reply.
-
- Since it may not be immediately clear whether the user wants to
- reply to the forwarder or to the original sender, the editor should
- offer a means to ignore the proposed control lines and start a
- "normal" reply instead, e.g. by two distinct functions, by user
- preference or a dialog.
-
-
- Pseudo code:
-
- forwarding_message:
- if is_forwarded_message then
- don't change FWD* control lines
- else
- add FWD* control lines
-
- quoting_message:
- if is_forwarded_message then
- if reply_to_forwarder then
- use header data (normal quoting)
- else
- use FWD* control lines
- remove FWD* control lines from reply
- else
- use header data (normal quoting)
-
- other_functions:
- remove/ignore FWD* control lines
-
-
- Example:
-
- Message from Joe User to my boss node:
-
- From: Joe User 1:234/567
- To: Harry Herrmannsdoerfer 2:2490/2520
- Subj: Some questions
- @MSGID: 1:234/567 12345678
- Text: Hello Harry!
- ...
-
- Harry forwards the message to me:
-
- From: Harry Herrmannsdoerfer 2:2490/2520
- To: Michael Hohner 2:2490/2520.17
- Subj: Joe's message
- @FWDFROM Joe User
- @FWDORIG 1:234/567
- @FWDTO Harry Herrmannsdoerfer
- @FWDDEST 2:2490/2520
- @FWDSUBJ Some questions
- @FWDMSGID 1:234/567 12345678
- Text: Hi Michael!
- ...
-
- My answer using the new control lines:
-
- From: Michael Hohner 2:2490/2520.17
- To: Joe User 1:234/567
- Subj: Some questions
- @REPLY: 1:234/567 12345678
- Text: Hi Joe!
-
- JU> ...
- ...
-
-
-3. Compatiblity
----------------
-
- Editor programs which are not prepared for these proposed control
- lines usually just ignore them and remove them from a reply. A reply
- goes to the forwarder. Nothing gained and nothing lost.
-
-
-4. Known implementations
-------------------------
-
- This proposal is implemented in the author's Fidonet editor
- "FleetStreet for OS/2" (versions 1.17 and newer).
-
- Also implemented in Odinn Sorensens Fidonet editor "GoldED"
- (versions 3.00.Alpha5 and newer).
-
-
-A. Contacting the author
-------------------------
-
- The author may be contacted electronically at the following
- addresses:
-
- Fidonet: 2:2490/2520.17
- Internet: miho@osn.de
-
- Suggestions, comments and corrections are always welcome.
-
-
-B. History
-----------
-
- Rev.1, 19960912: First release as FSC-0092.001.
- Rev.2, 19971229: Submitted as FSP.
-
-
-**********************************************************************
-
-
- Go Back
-
-
-
-
+
+
+
+New control lines for forwarding messages.
+
+
+
+
+
+**********************************************************************
+FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
+**********************************************************************
+
+Publication: FSP-1008
+Revision: 2
+Title: New control lines for forwarded messages
+Author: Michael Hohner, 2:2490/2520.17
+Revision Date: 29 December 1997
+Expiry Date: 29 December 1999
+----------------------------------------------------------------------
+Contents:
+ 1. Specifications
+ 2. Usage
+ 3. Compatiblity
+ 4. Known implementations
+----------------------------------------------------------------------
+
+
+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.
+
+ This revision is an update to FRL-0092.001. The basic specifications
+ are unchanged.
+
+
+Abstract
+--------
+
+ Most fidonet message editors offer a "forward" function. Using this
+ function a user A ("forwarder") can sort of "redirect" a message
+ from user B ("author") to another user C ("final recipient"), maybe
+ because the forwarder is not the correct recipient, or because the
+ final recipient is a better person to answer the message. The name
+ and address of the author are usually included in the forward in
+ free-text format. The message text is included in non-quoted format.
+
+ A problem arises when the final recipient wants to reply to the
+ author of the forwarded message. The forward contains the forwarder
+ as the sender. So the final recipient must insert the name and
+ address of the author manually, using the information contained in
+ the message text. The message editor of the final recipient can't do
+ this automatically because of the free-text format. The editor will
+ also use incorrect quote initials, which is at least irritating.
+
+ This document introduces 7 new control lines which contain the
+ header information of the original message. With these control lines
+ the message editor can use the original header information
+ automatically.
+
+
+1. Specifications
+-----------------
+
+ There are 7 new control lines: FWDFROM, FWDTO, FWDORIG, FWDDEST,
+ FWDSUBJ, FWDAREA, FWDMSGID. As all control lines they start with an
+ ASCII 01 character (SOH) followed by the control line name followed
+ by whitespace followed by the control line's content followed by
+ ASCII 13 (CR).
+
+ Please note that all these control lines do not have a colon (like
+ the control lines in FTS-0001). This would be just waste of space.
+
+ FWDFROM
+ -------
+
+ This control line contains the name of the original sender as found
+ in the FROM field of the original message. Leading and trailing
+ whitespace should be removed. This control line should be omitted
+ altogether if the FROM field is empty.
+
+ FWDTO
+ -----
+
+ This control line contains the name of the original recipient as
+ found in the TO field of the original message. Leading and trailing
+ whitespace should be removed. This control line should be omitted
+ altogether if the TO field is empty.
+
+ FWDORIG
+ -------
+
+ This control line contains the address of the original sender as
+ found in the ORIG field of the original message. The usual 5D ASCII
+ notation (zone:net/node.point@domain) should be used. This control
+ line should be omitted altogether if the address is not known.
+
+ FWDDEST
+ -------
+
+ This control line contains the address of the original recipient as
+ found in the DEST field of the original message. The usual 5D ASCII
+ notation (zone:net/node.point@domain) should be used. This control
+ line should be omitted altogether if the address is not known or
+ unsure (as it is the case with forwarded echomail messages).
+
+ FWDSUBJ
+ -------
+
+ This control line contains the subject line of the original message.
+ This control line should be omitted altogether if the SUBJ field is
+ empty.
+
+ This control line should by made optional for security reasons. Echo
+ manager passwords are too easily revealed with it.
+
+ FWDAREA
+ -------
+
+ This control line contains the name of the echomail area where the
+ original message was forwarded from. It should be omitted altogether
+ if the original message was not forwarded from an echomail area.
+
+ FWDMSGID
+ --------
+
+ This control line contains the MSGID control line of the original
+ message. It should be omitted altogether if a MSGID control line is
+ not present in the original message.
+
+
+2. Usage
+--------
+
+ When the "forward" function of the message editor is invoked, the
+ editor program should generate the proposed control lines from the
+ header of the original message. If the original message already was
+ a forwarded one (indicated by the presence of at least a FWDORIG
+ control line), the editor should keep all FWD* control lines and
+ should not add any FWD* control lines. This preserves the FWD*
+ control lines of the first forwarder, containing the header data of
+ the author of the original message.
+
+ The editor should not generate FWD* control lines, if the message
+ isn't to be forwarded. A mail forwarding robot may also generate
+ these control lines, if it not just readdresses the message.
+
+ When the "reply" function of the editor is invoked the program
+ should use the control lines' contents instead of the header
+ information. The control lines should not be included in the reply.
+
+ Since it may not be immediately clear whether the user wants to
+ reply to the forwarder or to the original sender, the editor should
+ offer a means to ignore the proposed control lines and start a
+ "normal" reply instead, e.g. by two distinct functions, by user
+ preference or a dialog.
+
+
+ Pseudo code:
+
+ forwarding_message:
+ if is_forwarded_message then
+ don't change FWD* control lines
+ else
+ add FWD* control lines
+
+ quoting_message:
+ if is_forwarded_message then
+ if reply_to_forwarder then
+ use header data (normal quoting)
+ else
+ use FWD* control lines
+ remove FWD* control lines from reply
+ else
+ use header data (normal quoting)
+
+ other_functions:
+ remove/ignore FWD* control lines
+
+
+ Example:
+
+ Message from Joe User to my boss node:
+
+ From: Joe User 1:234/567
+ To: Harry Herrmannsdoerfer 2:2490/2520
+ Subj: Some questions
+ @MSGID: 1:234/567 12345678
+ Text: Hello Harry!
+ ...
+
+ Harry forwards the message to me:
+
+ From: Harry Herrmannsdoerfer 2:2490/2520
+ To: Michael Hohner 2:2490/2520.17
+ Subj: Joe's message
+ @FWDFROM Joe User
+ @FWDORIG 1:234/567
+ @FWDTO Harry Herrmannsdoerfer
+ @FWDDEST 2:2490/2520
+ @FWDSUBJ Some questions
+ @FWDMSGID 1:234/567 12345678
+ Text: Hi Michael!
+ ...
+
+ My answer using the new control lines:
+
+ From: Michael Hohner 2:2490/2520.17
+ To: Joe User 1:234/567
+ Subj: Some questions
+ @REPLY: 1:234/567 12345678
+ Text: Hi Joe!
+
+ JU> ...
+ ...
+
+
+3. Compatiblity
+---------------
+
+ Editor programs which are not prepared for these proposed control
+ lines usually just ignore them and remove them from a reply. A reply
+ goes to the forwarder. Nothing gained and nothing lost.
+
+
+4. Known implementations
+------------------------
+
+ This proposal is implemented in the author's Fidonet editor
+ "FleetStreet for OS/2" (versions 1.17 and newer).
+
+ Also implemented in Odinn Sorensens Fidonet editor "GoldED"
+ (versions 3.00.Alpha5 and newer).
+
+
+A. Contacting the author
+------------------------
+
+ The author may be contacted electronically at the following
+ addresses:
+
+ Fidonet: 2:2490/2520.17
+ Internet: miho@osn.de
+
+ Suggestions, comments and corrections are always welcome.
+
+
+B. History
+----------
+
+ Rev.1, 19960912: First release as FSC-0092.001.
+ Rev.2, 19971229: Submitted as FSP.
+
+
+**********************************************************************
+
-**********************************************************************
-FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication: FSP-1009
-Revision: 1
-Title: Year 2000 issues in FTN software
-Author: Michael Hohner, 2:2490/2520.17
-Revision Date: 29 December 1997
-Expiry Date: 29 December 1999
-----------------------------------------------------------------------
-Contents:
- 1. Introduction
- 2. Generating Fidonet timestamps
- 3. Interpreting Fidonet timestamps
-----------------------------------------------------------------------
-
-
-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
---------
-
- The year 2000 causes problems in many computer programs which use
- two-digit year numbers. Current Fidonet software faces the very same
- problems. This FSP specifies procedures which enable FTN software to
- run without problems after the year 2000.
-
-
-1. Introduction
----------------
-
- Software using two-digit year numbers may cause problems in the year
- 2000. When the year number rolls over from "99" to "00", some
- software may interpret the resulting year number as "1900" instead
- of "2000". Such programs may contain code like this:
-
- calendar_year = year_number + 1900; /* wrong! */
-
- Fidonet software faces the very same problem: the year number in
- packed messages (see FTS-0001) has only two digits. Some programs
- interpreting this number incorrectly may decide that messages from
- the year 1900 are too old and discard them. Other programs probably
- just display a wrong calendar year.
-
- The long-term solution would be a transition to four-digit year
- numbers. However, this would require new data formats and cause
- every existing software to fail. So a short-term solution is
- required, resulting in only minimal changes in software. This FSP
- contains guidelines for proper year-number interpretation. The
- author encourages all FTN software authors to check their software
- for possible year-2000 problems (and release fixed versions during
- the next three years).
-
-
-2. Generating Fidonet timestamps
---------------------------------
-
- This should not cause much headache. However, some software may use
- the following algorithm:
-
- year_number = calendar_year - 1900 /* wrong! */
-
- This will result in a three-digit year number in 2000 and lead to
- incorrect Fidonet timestamps.
-
- One correct algorithm is:
-
- year_number = calendar_year mod 100 /* correct! */
-
-
-3. Interpreting Fidonet timestamps
-----------------------------------
-
- We can make use of the fact that Fidonet didn't exist before 1980,
- i.e. no messages were created before 1980. So any year number
- smaller than 80 can't mean "year 19xx", but can only mean "year
- 20xx". One algorithm for correct year number interpretation is:
-
- if year_number < 80 then
- calendar_year = 2000 + year_number
- else
- calendar_year = 1900 + year_number
-
- Fidonet software should only use the calendar year for further
- processing, not the year number from the timestamp.
-
- This solution will work until 2080, giving us another 80+ years to
- finally let some innovation happen in Fidonet.
-
-
-A. Contacting the author
-------------------------
-
- The author may be contacted electronically at the following
- addresses:
-
- Fidonet: 2:2490/2520.17
- Internet: miho@osn.de
-
- Suggestions, comments and corrections are always welcome.
-
-
-B. History
-----------
-
- Rev.1, 19971229: Submitted as FSP.
-
-
-**********************************************************************
-
-
- Go Back
-
-
-
-
+
+
+
+Year 2000 issues in FTN software.
+
+
+
+
+
+**********************************************************************
+FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
+**********************************************************************
+
+Publication: FSP-1009
+Revision: 1
+Title: Year 2000 issues in FTN software
+Author: Michael Hohner, 2:2490/2520.17
+Revision Date: 29 December 1997
+Expiry Date: 29 December 1999
+----------------------------------------------------------------------
+Contents:
+ 1. Introduction
+ 2. Generating Fidonet timestamps
+ 3. Interpreting Fidonet timestamps
+----------------------------------------------------------------------
+
+
+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
+--------
+
+ The year 2000 causes problems in many computer programs which use
+ two-digit year numbers. Current Fidonet software faces the very same
+ problems. This FSP specifies procedures which enable FTN software to
+ run without problems after the year 2000.
+
+
+1. Introduction
+---------------
+
+ Software using two-digit year numbers may cause problems in the year
+ 2000. When the year number rolls over from "99" to "00", some
+ software may interpret the resulting year number as "1900" instead
+ of "2000". Such programs may contain code like this:
+
+ calendar_year = year_number + 1900; /* wrong! */
+
+ Fidonet software faces the very same problem: the year number in
+ packed messages (see FTS-0001) has only two digits. Some programs
+ interpreting this number incorrectly may decide that messages from
+ the year 1900 are too old and discard them. Other programs probably
+ just display a wrong calendar year.
+
+ The long-term solution would be a transition to four-digit year
+ numbers. However, this would require new data formats and cause
+ every existing software to fail. So a short-term solution is
+ required, resulting in only minimal changes in software. This FSP
+ contains guidelines for proper year-number interpretation. The
+ author encourages all FTN software authors to check their software
+ for possible year-2000 problems (and release fixed versions during
+ the next three years).
+
+
+2. Generating Fidonet timestamps
+--------------------------------
+
+ This should not cause much headache. However, some software may use
+ the following algorithm:
+
+ year_number = calendar_year - 1900 /* wrong! */
+
+ This will result in a three-digit year number in 2000 and lead to
+ incorrect Fidonet timestamps.
+
+ One correct algorithm is:
+
+ year_number = calendar_year mod 100 /* correct! */
+
+
+3. Interpreting Fidonet timestamps
+----------------------------------
+
+ We can make use of the fact that Fidonet didn't exist before 1980,
+ i.e. no messages were created before 1980. So any year number
+ smaller than 80 can't mean "year 19xx", but can only mean "year
+ 20xx". One algorithm for correct year number interpretation is:
+
+ if year_number < 80 then
+ calendar_year = 2000 + year_number
+ else
+ calendar_year = 1900 + year_number
+
+ Fidonet software should only use the calendar year for further
+ processing, not the year number from the timestamp.
+
+ This solution will work until 2080, giving us another 80+ years to
+ finally let some innovation happen in Fidonet.
+
+
+A. Contacting the author
+------------------------
+
+ The author may be contacted electronically at the following
+ addresses:
+
+ Fidonet: 2:2490/2520.17
+ Internet: miho@osn.de
+
+ Suggestions, comments and corrections are always welcome.
+
+
+B. History
+----------
+
+ Rev.1, 19971229: Submitted as FSP.
+
+
+**********************************************************************
+
-**********************************************************************
-FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication: FSP-1010
-Revision: 1
-Title: Via kludge specification
-Author: Colin Turner,
- Joaquim Homrighausen
-Revision Date: 26 April 1999
-Expiry Date: 26 April 2001
-----------------------------------------------------------------------
-Contents:
- 1. Current practice
- 2. Kludge specification
- 3. Examples
- 4. Deprecated formats
-----------------------------------------------------------------------
-
-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
---------
-
- Current practice for Fidonet Technology Network (FTN) NetMail
- messages is to track their progress through the network and
- programs by using control lines. These control lines are in
- the form of a kludge named Via.
-
-
-1. Current practice
--------------------
-
- As NetMail messages are routed through a FidoNet Technology Network
- or as they are processed on a system, Via control lines are used to
- track their progress.
-
- A single NetMail message may have any number of Via control lines.
-
- The Via control lines 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 line by a single ASCII <CR>
- character (0Dh).
-
- A Via control line is typically added:
-
- when a netmail packer packs the NetMail for transmission to
- another system;
-
- when a netmail tracker inspects a NetMail.
-
-2. Kludge specification
------------------------
-
- The Via control line 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
- 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 kludge. This may or may not include a
- domain indicator.
-
- @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.
-
- 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 kludge to Universal
- Time (GMT or UTC) and use the "UTC" Time Zone indicator, where
- possible.
-
- The Time Zone field may only be ommitted 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.
-
- Program Name
- ------------
-
- This field is mandatory, and must follow the format used in the PID
- control line (detailed in FSC-46).
-
- Version
- -------
-
- This field is mandatory, and must follow the format used in the PID
- control line (detailed in FSC-46).
-
- Serial Number
- -------------
-
- This field is optional, and must follow the format used in the PID
- control line (detailed in FSC-46).
-
- Note that unlike many kludges, the "Via" text of the kludge itself
- is in mixed, and not all upper case.
-
-3. Examples
------------
-
- Example of valid usage are
-
- ^AVia 2:443/13 @19990305.043212.UTC O/T-Track+ 2.69
- ^AVia 2:443/13@fidonet @19980331.231202.UTC FrontDoor 2.32.mL
- ^AVia 2:443/13.0 @19990101.002102.UTC FastEcho 1.46.1 21321
- ^AVia 2:443/13 @19990323.230132 FakeMail 1.2
- ^AVia 2:2480/18@fidonet @19990307.182128.47.UTC ITrack+ 1.3/G6 FP000069
-
-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 implentations 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 seperate 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. Author contact data
-----------------------
-
- Colin Turner
- Fidonet: 2:443/13
- E-mail: ct@piglets.com
- WWW: http://www.piglets.com
-
- Joaquim Homrighausen
- Fidonet: 2:201/330
- E-mail: joho@defsol.se
- WWW: http://www.defsol.se
-
-
-C. History
-----------
-
- Rev.1, 990426: First release.
-
-**********************************************************************
-
- Go Back
-
-
+
+
+
+FTSC Document FSP-1010, Revision 001
+
+
+**********************************************************************
+FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
+**********************************************************************
+
+Publication: FSP-1010
+Revision: 1
+Title: Via kludge specification
+Author: Colin Turner,
+ Joaquim Homrighausen
+Revision Date: 26 April 1999
+Expiry Date: 26 April 2001
+----------------------------------------------------------------------
+Contents:
+ 1. Current practice
+ 2. Kludge specification
+ 3. Examples
+ 4. Deprecated formats
+----------------------------------------------------------------------
+
+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
+--------
+
+ Current practice for Fidonet Technology Network (FTN) NetMail
+ messages is to track their progress through the network and
+ programs by using control lines. These control lines are in
+ the form of a kludge named Via.
+
+
+1. Current practice
+-------------------
+
+ As NetMail messages are routed through a FidoNet Technology Network
+ or as they are processed on a system, Via control lines are used to
+ track their progress.
+
+ A single NetMail message may have any number of Via control lines.
+
+ The Via control lines 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 line by a single ASCII <CR>
+ character (0Dh).
+
+ A Via control line is typically added:
+
+ when a netmail packer packs the NetMail for transmission to
+ another system;
+
+ when a netmail tracker inspects a NetMail.
+
+2. Kludge specification
+-----------------------
+
+ The Via control line 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
+ 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 kludge. This may or may not include a
+ domain indicator.
+
+ @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.
+
+ 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 kludge to Universal
+ Time (GMT or UTC) and use the "UTC" Time Zone indicator, where
+ possible.
+
+ The Time Zone field may only be ommitted 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.
+
+ Program Name
+ ------------
+
+ This field is mandatory, and must follow the format used in the PID
+ control line (detailed in FSC-46).
+
+ Version
+ -------
+
+ This field is mandatory, and must follow the format used in the PID
+ control line (detailed in FSC-46).
+
+ Serial Number
+ -------------
+
+ This field is optional, and must follow the format used in the PID
+ control line (detailed in FSC-46).
+
+ Note that unlike many kludges, the "Via" text of the kludge itself
+ is in mixed, and not all upper case.
+
+3. Examples
+-----------
+
+ Example of valid usage are
+
+ ^AVia 2:443/13 @19990305.043212.UTC O/T-Track+ 2.69
+ ^AVia 2:443/13@fidonet @19980331.231202.UTC FrontDoor 2.32.mL
+ ^AVia 2:443/13.0 @19990101.002102.UTC FastEcho 1.46.1 21321
+ ^AVia 2:443/13 @19990323.230132 FakeMail 1.2
+ ^AVia 2:2480/18@fidonet @19990307.182128.47.UTC ITrack+ 1.3/G6 FP000069
+
+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 implentations 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 seperate 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. Author contact data
+----------------------
+
+ Colin Turner
+ Fidonet: 2:443/13
+ E-mail: ct@piglets.com
+ WWW: http://www.piglets.com
+
+ Joaquim Homrighausen
+ Fidonet: 2:201/330
+ E-mail: joho@defsol.se
+ WWW: http://www.defsol.se
+
+
+C. History
+----------
+
+ Rev.1, 990426: First release.
+
+**********************************************************************
+
-**********************************************************************
-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.
-
- Go Back
-
-
+
+
+
+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.
+
+Go Back
+
+
diff --git a/html/ftsc/fta-1005.html b/html/ftsc/fta-1005.html
index 0cd34d52..43011f1e 100755
--- a/html/ftsc/fta-1005.html
+++ b/html/ftsc/fta-1005.html
@@ -1,268 +1,269 @@
-
-
-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.
-
-
-**********************************************************************
-
-
- Go Back
-
-
-
-
+
+
+
+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.
+
+
+**********************************************************************
+
-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 (, 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 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 - destination point address
- o FMPT - origin point address
- o INTL - 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
-
+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
+
-
- Go Back
-
-
-
-
+
+
+
+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-
+
- | 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:
-
-
-
- is a 1 letter command, one of A, C, or D.
-
- 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.
-
-
-
- Go Back
-
-
-
-
+
+
+
+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.
+
+
-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:
-
- !
-
-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:
-
- [!][<+/->
-
- Go Back
-
-
-
-
+
+
+
+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 | |
+ `-----+----------+-------------------------+-------------------------+-----'
+
-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 - 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
-
+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
+
-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 - 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 | 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 | 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.
-
-
- Go Back
-
-
-
-
+
+
+
+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.
+
-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.
-
-
-
- Go Back
-
-
-
-
+
+
+
+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.
+
+
-**********************************************************************
-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.
-
-**********************************************************************
-
-
- Go Back
-
-
-
-
+
+
+
+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.
+
+**********************************************************************
+
+
+Go Back
+
+
+
+
diff --git a/html/ftsc/fts-5000.html b/html/ftsc/fts-5000.html
index dae9ae2e..36e9af05 100644
--- a/html/ftsc/fts-5000.html
+++ b/html/ftsc/fts-5000.html
@@ -1,4 +1,5 @@
+
The Distribution Nodelist.
@@ -446,7 +447,7 @@ C. History
- Go Back
+Go Back
diff --git a/html/ftsc/fts-5001.html b/html/ftsc/fts-5001.html
index a1bbfac1..050bd72f 100644
--- a/html/ftsc/fts-5001.html
+++ b/html/ftsc/fts-5001.html
@@ -1,4 +1,5 @@
+
The Distribution Nodelist.
@@ -396,7 +397,7 @@ B. History
- Go Back
+Go Back
diff --git a/html/ftsc/ftscprod.html b/html/ftsc/ftscprod.html
index 09161b20..f1a5796f 100755
--- a/html/ftsc/ftscprod.html
+++ b/html/ftsc/ftscprod.html
@@ -1,311 +1,312 @@
-
-
-FTSC Product ID List.
-
-
-
-
-
Go Back