bbs/deb-mbse
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fixed HTML codes in Fidonet documents

Browse Source
This commit is contained in:
Michiel Broek 2002-02-16 21:38:40 +00:00
parent 1fb610f935
commit 0aa608b565
42 changed files with 18330 additions and 18508 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

159
html/ftsc/fsc-0035.html
View File

@ -1,79 +1,80 @@
<HTML>
<HEAD>
<TITLE>Transparant Gateways to and from FidoNet.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Transparent Gateways to and from FidoNet <tm>
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.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Transparant Gateways to and from FidoNet.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Transparent Gateways to and from FidoNet <tm>
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.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

725
html/ftsc/fsc-0039.html
View File

@ -1,362 +1,363 @@
<HTML>
<HEAD>
<TITLE>A Type-2 Packet Extension Proposal.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>A Type-2 Packet Extension Proposal.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

455
html/ftsc/fsc-0046.html
View File

@ -1,227 +1,228 @@
<HTML>
<HEAD>
<TITLE>A Product Identiefier for FidoNet Message Handlers.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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: <pID> <version>[ <serial#>]<CR>
Sample
^APID: FM 2.11.b<CR>
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" ---
</PRE>
<HR>
<PRE>
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" ---
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>A Product Identiefier for FidoNet Message Handlers.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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: <pID> <version>[ <serial#>]<CR>
Sample
^APID: FM 2.11.b<CR>
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" ---
</PRE>
<HR>
<PRE>
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" ---
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>

835
html/ftsc/fsc-0048.html
View File

@ -1,417 +1,418 @@
<HTML>
<HEAD>
<TITLE>A Proposed Type-2 Packet Extension.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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)
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>A Proposed Type-2 Packet Extension.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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 ----&gt; higher packets YES ---&gt; Generate higher
NO we support? packet
| NO
\|/ |
+-----&lt;----------------------+
|
Fill header with all info
|
\|/
|
Are we sending from a point? (origPoint != 0) YES --+
| |
NO |
| \|/
| set AuxNet = OrigNet
\|/ set OrigNet = -1
| |
+-----&lt;----------------------------------------+
|
Add Messages
|
Terminate packet
|
Send packet
Receiving Type-2+ bundles
=========================
Receive Packet
|
Packettype = 2 NO -------------&gt; Process Type-Other
YES
|
|
CWcopies match NO --------+------&gt; 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
| |
+------&lt;-----------------------------------+
|
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)
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

207
html/ftsc/fsc-0049.html
View File

@ -1,103 +1,104 @@
<HTML>
<HEAD>
<TITLE>A Proposal for Passing Domain Information During an FST-0006 Session.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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.
</PRE>
<A HREF="./"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>A Proposal for Passing Domain Information During an FST-0006 Session.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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.
</PRE>
<A HREF="./"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

197
html/ftsc/fsc-0050.html
View File

@ -1,98 +1,99 @@
<HTML>
<HEAD>
<TITLE>A Character Set Identifier For FidoNet Message Editors.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>A Character Set Identifier For FidoNet Message Editors.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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: &lt;Character set identifier&gt;
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
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

375
html/ftsc/fsc-0053.html
View File

@ -1,187 +1,188 @@
<HTML>
<HEAD>
<TITLE>Specifications for the ^aFLAGS field.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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 <SOH>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.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Specifications for the ^aFLAGS field.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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 <SOH>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 &lt;SOH&gt; (^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.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

2157
html/ftsc/fsc-0056.html
View File

File diff suppressed because it is too large Load Diff

1067
html/ftsc/fsc-0057.html
View File

File diff suppressed because it is too large Load Diff

3245
html/ftsc/fsc-0059.html
View File

File diff suppressed because it is too large Load Diff

727
html/ftsc/fsc-0062.html
View File

@ -1,363 +1,364 @@
<HTML>
<HEAD>
<TITLE>A Proposed Nodelist flag indicating Online Times of a Node.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| 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 &times;
}
=== 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.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>A Proposed Nodelist flag indicating Online Times of a Node.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| 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 &lt;stdio.h&gt;
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", &amp;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", &amp;onhour, &amp;onmin);
sscanf(offtime, "%d:%d", &amp;offhour, &amp;offmin);
if(onmin&gt;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&gt;0 &amp;&amp; onmin&lt;31) flag[1] += 'a'-'A';
if(offmin&gt;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&gt;23) {
times.on_hour -= 'a'-'A';
times.on_min=30;
}
times.off_hour=timeflag[2]-'A';
if(times.off_hour&gt;23) {
times.off_hour -= 'a'-'A';
times.off_min=30;
}
return &times;
}
=== 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.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

245
html/ftsc/fsc-0070.html
View File

@ -1,122 +1,123 @@
<HTML>
<HEAD>
<TITLE>Improving FidoNet/UseNet gating and Dupe Checking.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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>
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Improving FidoNet/UseNet gating and Dupe Checking.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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 &lt;control-A&gt; (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: &lt;92_feb_10_19192012901@prep.ai.mit.edu&gt;
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 "&lt;" and "&gt;".
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: &lt;2-300-400-12345AbC@fidonet.org&gt;
(Fido) ^MSGID: 15:300/400.50@somenet abcd6789
to (Usenet) Message-ID: &lt;15-300-400-50-somenet-abcd6789@fidonet.org&gt;
(Fido) ^MSGID: Internet.Domain.org aBcD1234
to (Usenet) Message-ID: &lt;Internet-Domain-org-aBcD1234@fidonet.org&gt;
(Fido) ^MSGID: "LZKkoe$1982 98a" 45678bcd
to (Usenet) Message-ID: &lt;-LZKkoe-1982-98a--45678bcd@fidonet.org&gt;
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

3851
html/ftsc/fsc-0072.html
View File

File diff suppressed because it is too large Load Diff

611
html/ftsc/fsc-0087.html
View File

@ -1,305 +1,306 @@
<HTML>
<HEAD>
<TITLE>File Forwarding in Fidonet Technology Networks.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| 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-
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>File Forwarding in Fidonet Technology Networks.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| 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-
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

653
html/ftsc/fsc-0088.html
View File

@ -1,326 +1,327 @@
<HTML>
<HEAD>
<TITLE>Compatibility and Link Qualifier Extensions for EMSI Sessions</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| 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
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Compatibility and Link Qualifier Extensions for EMSI Sessions</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| 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
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

121
html/ftsc/fsc-0091.html
View File

@ -1,60 +1,61 @@
<HTML>
<HEAD>
<TITLE>ISDN nodelist flags (rev.002).</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| 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
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>ISDN nodelist flags (rev.002).</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| 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 -&gt; V110L
ISDNB -&gt; V110H
ISDNC -&gt; X75
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

487
html/ftsc/fsc-0092.html
View File

@ -1,243 +1,244 @@
<HTML>
<HEAD>
<TITLE>New control lines for forwarded messages.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| 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.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>New control lines for forwarded messages.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| 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&gt; ...
...
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.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

313
html/ftsc/fsc-0093.html
View File

@ -1,156 +1,157 @@
<HTML>
<HEAD>
<TITLE>Reduced seen-by lines.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| 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 -
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Reduced seen-by lines.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
| 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 -
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

421
html/ftsc/fsp-1001.html
View File

@ -1,210 +1,211 @@
<HTML>
<HEAD>
<TITLE>Timezone information in FTN messages.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Timezone information in FTN messages.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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: &lt;current offset from UTC&gt;
The offset has the format &lt;[-]hhmm&gt;, 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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

281
html/ftsc/fsp-1002.html
View File

@ -1,140 +1,141 @@
<HTML>
<HEAD>
<TITLE>Numeric reply indication in FTN subject lines.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Numeric reply indication in FTN subject lines.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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" -&gt; "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" -&gt; "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" -&gt; "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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

233
html/ftsc/fsp-1003.html
View File

@ -1,116 +1,117 @@
<HTML>
<HEAD>
<TITLE>Suggested use of Nodelist Fields.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Suggested use of Nodelist Fields.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

515
html/ftsc/fsp-1004.html
View File

@ -1,257 +1,258 @@
<HTML>
<HEAD>
<TITLE>Standard FidoNet Addressing.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Standard FidoNet Addressing.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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) =&gt; 1:234/5.6@fidonet
2:34/6.78 (a '4D' address) =&gt; 2:34/6.78@fidonet
4:610/34 (a '3D' address) =&gt; 4:610/34.0@fidonet
123/45 (a '2D' address) =&gt; 1:123/45.0@fidonet
955:95/2@othernet (another FTN) =&gt; 955:95/2.0@othernet
2:259/-1 (node application) =&gt; 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-&gt;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 =&gt; 1:234/5.6@fidonet
harry.cat@p78.f6.n34.z2.fidonet.org =&gt; 2:34/6.78@fidonet
i.be.jolly@f34.n610.z4.fidonet.org =&gt; 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 =&gt; 955:95/2.0@othernet
3. Routing Address Syntax
-------------------------
The two previous address types (Fidonet and Internet-&gt;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 =&gt; 2:259/7.0@fidonet, region 25, hub 0
fidonet:1:1:1:0:23:0 =&gt; 1:1/23.0@fidonet, zone 1 net
:955:9551:95:300:45:0 =&gt; 955:95/45.0, region 9551, hub 300
fidonet:2:25:25:0:0:0 =&gt; 2:25/0.0@fidonet, R25C
cnet:12:34:341:100:1:7 =&gt; 12:341/1.7@cnet, region 34, hub 100
:2:25:259:300:300:0 =&gt; 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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

901
html/ftsc/fsp-1005.html
View File

@ -1,450 +1,451 @@
<HTML>
<HEAD>
<TITLE>Zone 2 nodelist flags.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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...
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Zone 2 nodelist flags.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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.
-&gt; VM VModem, default port 3141, dummy country code 000-
-&gt; IFC IFCico, default port 60179, dummy country code 000-
-&gt; BND BinkP, default port 24544, dummy country code 000-
-&gt; IP general IP connectivity, dummy country code 000-
-&gt; 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
-&gt; 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)
-&gt; 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)
-&gt; 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
-&gt; ZYX Zyxel series 16800 bps (implies V32b and V42b)
-&gt; 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
-&gt; #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.
-&gt; 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:
-&gt; V110L ITU-T V.110 19k2 async 'Low' (former ISDNA)
-&gt; V110H ITU-T V.110 38k4 async 'High' (former ISDNB)
-&gt; V120L ITU-T V.120 56k6 async, N1 = 259, W = 7, modulo 8
-&gt; V120H ITU-T V.120 64k async, N1 = 259, W = 7, modulo 8
-&gt; 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)
-&gt; ISDN Other configuration, used only if none of above fits
These ISDN flags follow the specification in FSC-0091.
-&gt; 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.
-&gt; Z19 Zyxel series 19200 bps (implies ZYX)
-&gt; X2C x2 client w/ 56000 bps (should imply V34 and V42b)
-&gt; X2S x2 server w/ 64000 bps (should imply V34 and V42b)
-&gt; K12 Systems offering all educational K12-conferences
-&gt; ENC The node accepts inbound encrypted mail
-&gt; NC Network Coordinator (only if the NC is not the host)
-&gt; NEC Net Echomail Coordinator (at most one per net)
-&gt; 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 =&gt; MNP
H14 =&gt; MNP HST
H16 =&gt; MNP HST H14
V42b =&gt; V42 (MNP ?)
V32b =&gt; V32
Flag implications specified in the zone 2 nodelist epilogue:
HST =&gt; MNP
H14 =&gt; HST MNP
-&gt; H16 =&gt; V42 MNP V42b H14 HST
-&gt; V42b =&gt; V42 MNP
-&gt; ZYX =&gt; V42 MNP V42b V32 V32b
-&gt; Z19 =&gt; V42 MNP V42b V32 V32b ZYX
V32b =&gt; V32
-&gt; V32T =&gt; V32 V32b
-&gt; V110L =&gt; ISDN
-&gt; V110H =&gt; ISDN
-&gt; V120L =&gt; ISDN
-&gt; V120H =&gt; ISDN
-&gt; X75 =&gt; 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 =&gt; V32 V32b MNP V42 V42b
X2C =&gt; V34 MNP V42 V42b
X2S =&gt; 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 =&gt; XW XR XP XB XC XX,
| XB =&gt; XW XR XP,
| XC =&gt; XW XR XX,
| XR =&gt; XW,
| XX =&gt; 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...
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

319
html/ftsc/fsp-1006.html
View File

@ -1,159 +1,160 @@
<HTML>
<HEAD>
<TITLE>Kludge for specifying addition e-mail reply addresses.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Kludge for specifying addition e-mail reply addresses.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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 &lt;e-mail address&gt;
Where &lt;e-mail address&gt; 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$&lt;123455@goldware.dk&gt; 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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

325
html/ftsc/fsp-1007.html
View File

@ -1,162 +1,163 @@
<HTML>
<HEAD>
<TITLE>Multiple recipient address specification to gateway.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Multiple recipient address specification to gateway.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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: &lt;e-mail address&gt;[,&lt;e-mail address&gt;[...]]
GW-Cc: &lt;e-mail address&gt;[,&lt;e-mail address&gt;[...]]
GW-Bcc: &lt;e-mail address&gt;[,&lt;e-mail address&gt;[...]]
Where &lt;e-mail address&gt; 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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

551
html/ftsc/fsp-1008.html
View File

@ -1,275 +1,276 @@
<HTML>
<HEAD>
<TITLE>New control lines for forwarding messages.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>New control lines for forwarding messages.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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&gt; ...
...
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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

285
html/ftsc/fsp-1009.html
View File

@ -1,142 +1,143 @@
<HTML>
<HEAD>
<TITLE>Year 2000 issues in FTN software.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Year 2000 issues in FTN software.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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 &lt; 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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

485
html/ftsc/fsp-1010.html
View File

@ -1,242 +1,243 @@
<HTML>
<HEAD>
<TITLE>FTSC Document FSP-1010, Revision 001</TITLE>
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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 &lt;CR&gt;
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: &lt;FTN Address&gt; @YYYYMMDD.HHMMSS[.Precise][.Time Zone]
&lt;Program Name&gt; &lt;Version&gt; [Serial Number]&lt;CR&gt;
Where ^A denotes the ASCII &lt;SOH&gt; (01h) character, and &lt;CR&gt; 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 &quot;UTC&quot; 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 &quot;Via&quot; 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
&lt;NAME&gt; [VERSION] [SERIAL] &lt;ADDRESS&gt; &lt;TIMESTAMP&gt; &lt;TIMEZONE&gt;
&lt;NAME&gt; &lt;ADDRESS&gt;, &lt;TIMESTAMP&gt; &lt;TIMEZONE&gt; &lt;VERSION&gt;
Not that the time stamp in the above formats is also widely
variable, and takes forms which include, but may not be limited to
&lt;Day&gt; &lt;Month&gt; &lt;Year&gt; AT &lt;Hour&gt;:&lt;Min&gt;:[Sec]
&lt;Day of Week&gt; &lt;Month&gt; &lt;Day of Month&gt; &lt;Year&gt; &lt;Hour&gt;:&lt;Min&gt;:&lt;Sec&gt;
ON &lt;Day of Month&gt; &lt;Month&gt; &lt;Year&gt; &lt;Hour&gt;:&lt;Min&gt;:&lt;Sec&gt;
&lt;Month&gt;/&lt;Day&gt; &lt;Hour&gt;:&lt;Min&gt;
@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] &quot;A Basic FidoNet(r) Technical Standard Revision 16&quot;, Randy
Bush. September 1995.
[FSC-46] &quot;A Product Identifier for FidoNet Message Handlers&quot;,
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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>FTSC Document FSP-1010, Revision 001</TITLE>
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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 &lt;CR&gt;
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: &lt;FTN Address&gt; @YYYYMMDD.HHMMSS[.Precise][.Time Zone]
&lt;Program Name&gt; &lt;Version&gt; [Serial Number]&lt;CR&gt;
Where ^A denotes the ASCII &lt;SOH&gt; (01h) character, and &lt;CR&gt; 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 &quot;UTC&quot; 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 &quot;Via&quot; 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
&lt;NAME&gt; [VERSION] [SERIAL] &lt;ADDRESS&gt; &lt;TIMESTAMP&gt; &lt;TIMEZONE&gt;
&lt;NAME&gt; &lt;ADDRESS&gt;, &lt;TIMESTAMP&gt; &lt;TIMEZONE&gt; &lt;VERSION&gt;
Not that the time stamp in the above formats is also widely
variable, and takes forms which include, but may not be limited to
&lt;Day&gt; &lt;Month&gt; &lt;Year&gt; AT &lt;Hour&gt;:&lt;Min&gt;:[Sec]
&lt;Day of Week&gt; &lt;Month&gt; &lt;Day of Month&gt; &lt;Year&gt; &lt;Hour&gt;:&lt;Min&gt;:&lt;Sec&gt;
ON &lt;Day of Month&gt; &lt;Month&gt; &lt;Year&gt; &lt;Hour&gt;:&lt;Min&gt;:&lt;Sec&gt;
&lt;Month&gt;/&lt;Day&gt; &lt;Hour&gt;:&lt;Min&gt;
@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] &quot;A Basic FidoNet(r) Technical Standard Revision 16&quot;, Randy
Bush. September 1995.
[FSC-46] &quot;A Product Identifier for FidoNet Message Handlers&quot;,
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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>

3513
html/ftsc/fsp-1011.html
View File

File diff suppressed because it is too large Load Diff

537
html/ftsc/fta-1005.html
View File

@ -1,268 +1,269 @@
<HTML>
<HEAD>
<TITLE>FTSC Product ID List.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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.
**********************************************************************
</PRE>
<A HREF="./"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>FTSC Product ID List.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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.
**********************************************************************
</PRE>
<A HREF="./"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

2521
html/ftsc/fts-0001.html
View File

File diff suppressed because it is too large Load Diff

829
html/ftsc/fts-0004.html
View File

@ -1,414 +1,415 @@
<HTML>
<HEAD>
<TITLE>Echomail Specification.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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-
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Echomail Specification.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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:
--- &lt;a small product-specific banner&gt;
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-
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

1235
html/ftsc/fts-0005.html
View File

File diff suppressed because it is too large Load Diff

1741
html/ftsc/fts-0006.html
View File

File diff suppressed because it is too large Load Diff

3514
html/ftsc/fts-0007.html
View File

File diff suppressed because it is too large Load Diff

976
html/ftsc/fts-0008.html
View File

@ -1,485 +1,491 @@
<HTML>
<HEAD>
<TITLE>Bark file-request protocol extension.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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 <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 | | (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.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Bark file-request protocol extension.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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&lt;max&gt; - 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&lt;12&gt;
Space
Date&lt;11&gt;
ETX
CRC
DataBlock (with password) = ACK
Filename&lt;12&gt;
Space
Date&lt;11&gt;
Space
Password&lt;6|8&gt;
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 &gt; 2400bps, | |
| | | | | Reset SLO if &lt;= 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 &lt;cr&gt; | exit|
| | +-+-----------------------+-------------------------+-----+
| | |2| ?? &lt;cr&gt;s received | delay 1 sec | S3 |
| | +-+-----------------------+-------------------------+-----+
| | |3| &lt;cr&gt;s not received | send &lt;cr&gt; &lt;sp&gt; &lt;cr&gt; &lt;sp&gt;| 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 <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 | | (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 &gt; 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 &amp; 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 &amp; 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.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

209
html/ftsc/fts-0009.html
View File

@ -1,104 +1,105 @@
<HTML>
<HEAD>
<TITLE>Message identification and reply linkage.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Message identification and reply linkage.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
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.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

385
html/ftsc/fts-4001.html
View File

@ -1,192 +1,193 @@
<HTML>
<HEAD>
<TITLE>Addessing Control Paragraphs.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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:
&lt;SOH&gt;"FMPT &lt;point number&gt;"&lt;CR&gt;
where &lt;point number&gt; 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
&lt;SOH&gt;"FMPT 1"&lt;CR&gt;
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:
&lt;SOH&gt;"TOPT "&lt;point number&gt;&lt;CR&gt;
where &lt;point number&gt; 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
&lt;SOH&gt;"TOPT 1"&lt;CR&gt;
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:
&lt;SOH&gt;"INTL "&lt;destination address&gt;" "&lt;origin address&gt;&lt;CR&gt;
where &lt;destination address&gt; shall be the representation of the
address of ultimate destination and &lt;origin address&gt; is the
representation of the address of the original sender of the message
in question. These addresses shall be given on the form
&lt;zone&gt;:&lt;net&gt;/&lt;node&gt; where &lt;zone&gt; is the ASCII representation of the
zone number, &lt;net&gt; is the ASCII representation of the net number and
&lt;node&gt; 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
&lt;SOH&gt;"INTL 2:345/6 1:123/4"&lt;CR&gt;
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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Addessing Control Paragraphs.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
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:
&lt;SOH&gt;"FMPT &lt;point number&gt;"&lt;CR&gt;
where &lt;point number&gt; 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
&lt;SOH&gt;"FMPT 1"&lt;CR&gt;
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:
&lt;SOH&gt;"TOPT "&lt;point number&gt;&lt;CR&gt;
where &lt;point number&gt; 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
&lt;SOH&gt;"TOPT 1"&lt;CR&gt;
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:
&lt;SOH&gt;"INTL "&lt;destination address&gt;" "&lt;origin address&gt;&lt;CR&gt;
where &lt;destination address&gt; shall be the representation of the
address of ultimate destination and &lt;origin address&gt; is the
representation of the address of the original sender of the message
in question. These addresses shall be given on the form
&lt;zone&gt;:&lt;net&gt;/&lt;node&gt; where &lt;zone&gt; is the ASCII representation of the
zone number, &lt;net&gt; is the ASCII representation of the net number and
&lt;node&gt; 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
&lt;SOH&gt;"INTL 2:345/6 1:123/4"&lt;CR&gt;
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.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

3
html/ftsc/fts-5000.html
View File

@ -1,4 +1,5 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>The Distribution Nodelist.</TITLE>
</HEAD>
@ -446,7 +447,7 @@ C.&nbsp;History<BR>
<BR>
</TT>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

3
html/ftsc/fts-5001.html
View File

@ -1,4 +1,5 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>The Distribution Nodelist.</TITLE>
</HEAD>
@ -396,7 +397,7 @@ B.&nbsp;History<BR>
<BR>
</TT>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

623
html/ftsc/ftscprod.html
View File

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

3
html/ftsc/index.htm
View File

@ -1,4 +1,5 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=ISO 8859-1">
<META http-equiv="Content-Style-Type" content="text/css">
@ -94,7 +95,7 @@ Michiel Broek.
<HR>
<A HREF="../index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Index" Border="0" width="33" height="35">Back to Index</A>
<A HREF="../index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Index" Border="0">Back to Index</A>
</BLOCKQUOTE>
</BODY>
</HTML>