Fixed HTML codes in Fidonet documents
This commit is contained in:
Michiel Broek
parent
1fb610f935
commit
0aa608b565
@ -1,79 +1,80 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>Transparant Gateways to and from FidoNet.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>Transparant Gateways to and from FidoNet.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
Transparent Gateways to and from FidoNet <tm>
|
<PRE>
|
||||||
Technical Considerations
|
Transparent Gateways to and from FidoNet <tm>
|
||||||
FSC-0035
|
Technical Considerations
|
||||||
|
FSC-0035
|
||||||
Michael Shiels 22 June 89
|
|
||||||
|
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,
|
Copyright 1989, Michael Shiels. All rights reserved. The right to distribute
|
||||||
provided that no fee is charged. This may be posted on FidoNet electronic BBSs
|
for non-commercial use is granted to the FidoNet Technical Standards Committee,
|
||||||
which charge no fee for accessing this document. Any and all other reproduction
|
provided that no fee is charged. This may be posted on FidoNet electronic BBSs
|
||||||
or excerpting requires the explicit written consent of the author.
|
which charge no fee for accessing this document. Any and all other reproduction
|
||||||
|
or excerpting requires the explicit written consent of the author.
|
||||||
|
|
||||||
Gateways
|
|
||||||
--------
|
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
|
Gatewaying between Fidonet and other networks seems to be the latest feature
|
||||||
are some real problems with gatewaying and doing "transparent" replies.
|
which hopefully brings more benefits to the users of each network. But there
|
||||||
This proposal should allow for almost totally transparent gateways but requires
|
are some real problems with gatewaying and doing "transparent" replies.
|
||||||
the co-operation of BBS software writers to support this following protocol.
|
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
|
|
||||||
-----------------
|
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
|
When a message is entered into fidonet from another network it will be entering
|
||||||
very will with the 2 word 36 character userid on Fidonet. So the following is
|
through one machine (say 1/2). The userid on the other network may not match
|
||||||
done to store away the proper userid of the sender.
|
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).
|
Two (2) lines are added to the message (usually at the top of the text portion
|
||||||
|
hidden by the infamous ^A KLUDGE).
|
||||||
^AREPLYADDR .....\r
|
|
||||||
|
^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
|
which signifies the FULL userid of the person on the other network. The first
|
||||||
in the FROM field of the message header. When replies are done they use a
|
36 characters or the full userid if less than 36 characters long, are stored
|
||||||
second line of the following form.
|
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
|
|
||||||
|
^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
|
which is used to signify the "userid" which mail destined to this other network
|
||||||
to this zone:net/node and userid with the first line of the message being
|
must be sent to and on which machine that userids resides. Replies are sent
|
||||||
changed into 'TO: ....' where .... is the FULL userid from the ^AREPLYADDR
|
to this zone:net/node and userid with the first line of the message being
|
||||||
line.
|
changed into 'TO: ....' where .... is the FULL userid from the ^AREPLYADDR
|
||||||
|
line.
|
||||||
Should you have constructive correction or criticism, please contact:
|
|
||||||
|
Should you have constructive correction or criticism, please contact:
|
||||||
Michael Shiels
|
|
||||||
FidoNet: 1:250/410 michael.shiels@masnet.fidonet.org
|
Michael Shiels
|
||||||
uucp: ?!tmsoft!masnet!michael.shiels
|
FidoNet: 1:250/410 michael.shiels@masnet.fidonet.org
|
||||||
Internet: michael.shiels@masnet.uucp
|
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.
|
FidoNet is a trademark of Tom Jennings and Fido Software, to whom we all owe
|
||||||
</PRE>
|
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>
|
|
||||||
|
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
|
||||||
</BODY>
|
|
||||||
</HTML>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,362 +1,363 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>A Type-2 Packet Extension Proposal.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>A Type-2 Packet Extension Proposal.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
Document: FSC-0039
|
<PRE>
|
||||||
Version: 04
|
Document: FSC-0039
|
||||||
Date: 29-Sep-90
|
Version: 04
|
||||||
|
Date: 29-Sep-90
|
||||||
|
|
||||||
A Type-2 Packet Extension Proposal
|
|
||||||
Mark A. Howard 1:260/340@FidoNet
|
A Type-2 Packet Extension Proposal
|
||||||
|
Mark A. Howard 1:260/340@FidoNet
|
||||||
Status of this document:
|
|
||||||
------------------------
|
Status of this document:
|
||||||
This FSC suggests a proposed protocol for the FidoNet(r) community,
|
------------------------
|
||||||
and requests discussion and suggestions for improvements. Distribution
|
This FSC suggests a proposed protocol for the FidoNet(r) community,
|
||||||
of this document is unlimited.
|
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.
|
Fido and FidoNet are registered marks of Tom Jennings and Fido Software.
|
||||||
|
FTS-0001 is a copyrighted work of Randy Bush.
|
||||||
Introduction
|
|
||||||
------------
|
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.
|
This document serves two major purposes. The first is an attempt to define
|
||||||
Although FTS-0001 defines the structure of a Type-2 packet, the natural
|
and document the Type-2 packet which is widely in use in FidoNet today.
|
||||||
evolution of our network, mostly with regards to addressing methodology,
|
Although FTS-0001 defines the structure of a Type-2 packet, the natural
|
||||||
has made it necessary to utilize hitherto unused portions of the header
|
evolution of our network, mostly with regards to addressing methodology,
|
||||||
to insert Zone and Point information. Also, it has become apparent that
|
has made it necessary to utilize hitherto unused portions of the header
|
||||||
some of the existing fields are not large enough to accomplish their
|
to insert Zone and Point information. Also, it has become apparent that
|
||||||
original tasks.
|
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
|
The second is to propose a simple mechanism to allow FidoNet to begin to
|
||||||
Type-2 has served us faithfully for some time now, the evolution of our
|
utilize advanced mail packing techniques. It is quite apparent that while
|
||||||
network in terms of technical and physical complexity has caused us to
|
Type-2 has served us faithfully for some time now, the evolution of our
|
||||||
consider more efficient and functional ways to pack mail.
|
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),
|
It should be made clear that with the exception of the Capability Word,
|
||||||
which are proposed extensions to the Type-2 packet header, this FSC is
|
Capability Word Validation Copy, ProductCode(hi), and Revision(minor),
|
||||||
an attempt to correctly document existing practices with regards to the
|
which are proposed extensions to the Type-2 packet header, this FSC is
|
||||||
insertion of zone and point info by at least three mail processors in
|
an attempt to correctly document existing practices with regards to the
|
||||||
use today.
|
insertion of zone and point info by at least three mail processors in
|
||||||
|
use today.
|
||||||
|
|
||||||
The Type-2 Header (Where's the Zone?)
|
|
||||||
-------------------------------------
|
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
|
Although FTS-0001 has recently been updated to reflect the use of some of
|
||||||
methods for inserting the zone information have been adopted, making it
|
the areas in the packed message header for zone data, at least two other
|
||||||
necessary to provide support for both formats in all of the zone aware mail
|
methods for inserting the zone information have been adopted, making it
|
||||||
processors. The end result is more code, and redundant information in the
|
necessary to provide support for both formats in all of the zone aware mail
|
||||||
packet header.
|
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.
|
This has presented a problem in logistics, as it is difficult to consider
|
||||||
As sufficient indentification is provided, in the form of the product code,
|
the project of updating mail processors using one type to use the other.
|
||||||
to determine the expected location of the zone information, and because
|
As sufficient indentification is provided, in the form of the product code,
|
||||||
code already exists in most of the mail processors to overcome this, this
|
to determine the expected location of the zone information, and because
|
||||||
proposal does not attempt to suggest that one method be used over the
|
code already exists in most of the mail processors to overcome this, this
|
||||||
other, rather the intent is to attempt to document the extensions in use,
|
proposal does not attempt to suggest that one method be used over the
|
||||||
and the products involved.
|
other, rather the intent is to attempt to document the extensions in use,
|
||||||
|
and the products involved.
|
||||||
See the accompanying chart and cross-reference.
|
|
||||||
|
See the accompanying chart and cross-reference.
|
||||||
|
|
||||||
The Product Code
|
|
||||||
----------------
|
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
|
Based upon the current rate of requests for product codes from the FTSC,
|
||||||
accomodate all of the codes required. While it is not reasonable to
|
it is probable that the Product Code byte will not be large enough to
|
||||||
expect that all Type-2 processors will eventually check the hi-order byte
|
accomodate all of the codes required. While it is not reasonable to
|
||||||
proposed here, it is likely that 'current' mail processors will. This
|
expect that all Type-2 processors will eventually check the hi-order byte
|
||||||
can be nothing but benefical, as it will force users to upgrade their
|
proposed here, it is likely that 'current' mail processors will. This
|
||||||
mail processors to a product which will as a minimum, support Type-2
|
can be nothing but benefical, as it will force users to upgrade their
|
||||||
with Zone and Point extensions, and quite possibly, processors that will
|
mail processors to a product which will as a minimum, support Type-2
|
||||||
utilize more advanced mail packing techniques, making Type-2 extinct once
|
with Zone and Point extensions, and quite possibly, processors that will
|
||||||
and for all.
|
utilize more advanced mail packing techniques, making Type-2 extinct once
|
||||||
|
and for all.
|
||||||
|
|
||||||
The Capability Word (How do we GET there from here?)
|
|
||||||
-----------------------------------------------------
|
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
|
Everybody would like to see more efficient and functional ways to pack and
|
||||||
really address a problem which must be solved first. The problem is that
|
exchange mail. Several Type-3 message bundle proposals exist, but none
|
||||||
since FidoNet is a hobbyist network, no demands can be placed on any one
|
really address a problem which must be solved first. The problem is that
|
||||||
sysop to upgrade or change their bundling software. Because of this, it
|
since FidoNet is a hobbyist network, no demands can be placed on any one
|
||||||
is necessary to consider strategies which allow for the existence of Type-2
|
sysop to upgrade or change their bundling software. Because of this, it
|
||||||
bundlers in the network topology.
|
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
|
Considerable advantages can be realized, however, between systems that
|
||||||
simply send netmail to all of your connecting systems, saying "Hey, I've
|
consent to use advanced bundling techniques. One way to do this is to
|
||||||
got a Type-3 bundler now, how about you?" This could become quite
|
simply send netmail to all of your connecting systems, saying "Hey, I've
|
||||||
tiresome, and does not represent much of an improvement on the current
|
got a Type-3 bundler now, how about you?" This could become quite
|
||||||
situation.
|
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
|
What would be desirable is a network that would 'upgrade itself'. Given a
|
||||||
network topology, the goal is to provide a mechanism whereby two links can
|
situation where mail processors of various capabilities will exist in a
|
||||||
determine and utilize the most efficient bundling method to use, in a
|
network topology, the goal is to provide a mechanism whereby two links can
|
||||||
manner transparent to the sysop.
|
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
|
For instance, let's say that the FTSC releases the Type-7 All New Singing
|
||||||
only support Types 2, 3, and 5. One of your downlinks gets a new version
|
and Dancing bundle format. Well, your current version of SlingToss can
|
||||||
of MailMangle which can support Types 2, 3, 4, and 7. Well, it is quite
|
only support Types 2, 3, and 5. One of your downlinks gets a new version
|
||||||
obvious that since you and he are exchanging 4 megs of mail each night,
|
of MailMangle which can support Types 2, 3, 4, and 7. Well, it is quite
|
||||||
and it's an overseas call, that it would be in your interest to obtain a
|
obvious that since you and he are exchanging 4 megs of mail each night,
|
||||||
new version of SlingToss which can support Type 7.
|
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
|
Note that this is *optional*. Because both processors can support Type-3,
|
||||||
MailMangle is happily advertising the availability of Type-7. Even your
|
they will continue to exchange Type-3 mail quite happily, even though
|
||||||
downlinks which are still using stone-age Type-2 processors will be fine,
|
MailMangle is happily advertising the availability of Type-7. Even your
|
||||||
as SlingToss will always export Type-2 bundles when no higher capability
|
downlinks which are still using stone-age Type-2 processors will be fine,
|
||||||
can be determined.
|
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.
|
So, after dashing off the check to the author, your new version of
|
||||||
The next time SlingToss exports mail to the MailMangle system, it says
|
SlingToss comes in the mail! You rush over to your system, and install it.
|
||||||
"Hey! I can now support Type 2, 3, 5, and 7! So, whattya got?" This is
|
The next time SlingToss exports mail to the MailMangle system, it says
|
||||||
no skin off MailMangle's nose, he's had Type-7 for quite a while, and he
|
"Hey! I can now support Type 2, 3, 5, and 7! So, whattya got?" This is
|
||||||
begins to export Type-7 bundles to SlingToss. "It's about time.", he says.
|
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
|
Now, this scenario is made possible by implementing a 'Capability Word' in
|
||||||
depends on several assumptions:
|
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
|
1) Any Advanced Capability Bundler *MUST* be capable of receiving and
|
||||||
will be in the new format proposed by this document, but then again,
|
faithfully processing Type-2 bundles. Hopefully, the inbound packets
|
||||||
this is not an exact science. What this means is that it is likely
|
will be in the new format proposed by this document, but then again,
|
||||||
that some packets may arrive with the Capability Word (CW) set to 0.
|
this is not an exact science. What this means is that it is likely
|
||||||
In this case, Type-2 is assumed, assuring compatibility. The only
|
that some packets may arrive with the Capability Word (CW) set to 0.
|
||||||
caveat is that it is conceivable that some obscure mail processor
|
In this case, Type-2 is assumed, assuring compatibility. The only
|
||||||
uses the location proposed for the CW for other arcane purposes. This
|
caveat is that it is conceivable that some obscure mail processor
|
||||||
| can detected through the CWValidation Copy, which is byte-swapped and
|
uses the location proposed for the CW for other arcane purposes. This
|
||||||
| compared with the CW at that time. If a mismatch is found, a CW of
|
| can detected through the CWValidation Copy, which is byte-swapped and
|
||||||
| type 0 is assumed, and a Type-2 bundling method is used.
|
| 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
|
2) An Advanced Capability Bundler, hereafter referred to as a Type-N
|
||||||
capability information. This can be done many ways, and in fact
|
Bundler, must have a method to store and maintain the node-by-node
|
||||||
several processors already have begun to maintain node information
|
capability information. This can be done many ways, and in fact
|
||||||
outside of that found in AREAS.BBS, mostly to implement pre-arranged
|
several processors already have begun to maintain node information
|
||||||
alternate compression methods. In a text configuration file, you
|
outside of that found in AREAS.BBS, mostly to implement pre-arranged
|
||||||
might see the following:
|
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
|
; Address Comp Send LastCW ; Comments
|
||||||
Node 1:135/20 LZH 3 2,3,7 ; Always send Type-3
|
Node 1:260/340 ZIP Auto 7 ; Auto detect & upgrade
|
||||||
Node 1: ARC 2 0 ; Stone-Age processor
|
Node 1:135/20 LZH 3 2,3,7 ; Always send Type-3
|
||||||
Node 1:135/4 --- Auto 7 ; Sent me netmail
|
Node 1: ARC 2 0 ; Stone-Age processor
|
||||||
Node 1: --- 0 0 ; Don't send CW
|
Node 1:135/4 --- Auto 7 ; Sent me netmail
|
||||||
|
Node 1: --- 0 0 ; Don't send CW
|
||||||
In this example, the fields are:
|
|
||||||
|
In this example, the fields are:
|
||||||
Address - downlink address. Note that this is not necessarily
|
|
||||||
relative to echomail, only, it is possible to append
|
Address - downlink address. Note that this is not necessarily
|
||||||
information to the node database as netmail packets are
|
relative to echomail, only, it is possible to append
|
||||||
receieved from different addresses.
|
information to the node database as netmail packets are
|
||||||
|
receieved from different addresses.
|
||||||
Comp - desired mail compression method.
|
|
||||||
|
Comp - desired mail compression method.
|
||||||
Send - Auto - automatically determined maximum common packing
|
|
||||||
method to use. Automatically update to LastCW
|
Send - Auto - automatically determined maximum common packing
|
||||||
when packing.
|
method to use. Automatically update to LastCW
|
||||||
|
when packing.
|
||||||
LastCW - Last CW received from remote system.
|
|
||||||
|
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,
|
3) A Type-N Bundle will always advertise it's capabilities in the CW
|
||||||
it allows Type-N processors to automatically track the capability
|
regardless of the type being sent. As shown in the above example,
|
||||||
of your system. Again, in cases where a stone-age processor is
|
it allows Type-N processors to automatically track the capability
|
||||||
being used, this field will be ignored, and in the unusual event
|
of your system. Again, in cases where a stone-age processor is
|
||||||
that it is not ignored, and is somehow harmful to the far system,
|
being used, this field will be ignored, and in the unusual event
|
||||||
the Type-N processor can be configured to send a CW of 0.
|
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 format of the Capability Word is designed to support up to 15 future
|
||||||
the maximum common level supported between two nodes:
|
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----------------
|
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
|
|
||||||
|
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, 3, and 7 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 1
|
||||||
2 (this FSC) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
|
2, 3, and 5 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1
|
||||||
Stone Age** 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
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
|
^
|
||||||
|
+--- Indicates UseNet RFC-822 capability
|
||||||
** - a mismatch in the CWValidation Copy also
|
|
||||||
produces a CW=0.
|
** - 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.
|
In this example, the Type-N bundler would first compare the remote CW
|
||||||
Prior to the compare, the MSB of the CW's are masked, as this bit is
|
| and the byte-swapped remote CWValidation Copy, and check for a mismatch.
|
||||||
reserved to indicate whether the mail processor is capable of also
|
Prior to the compare, the MSB of the CW's are masked, as this bit is
|
||||||
accepting UseNet RFC-822 bundles. Following the MSB mask, and bit
|
reserved to indicate whether the mail processor is capable of also
|
||||||
comparison, if they do not match, a remote CW of 0 is assumed. If they
|
accepting UseNet RFC-822 bundles. Following the MSB mask, and bit
|
||||||
match, the Type-N processor would AND the local and remote CW words,
|
comparison, if they do not match, a remote CW of 0 is assumed. If they
|
||||||
obtaining a CW expressing the Types which are in common to both systems.
|
match, the Type-N processor would AND the local and remote CW words,
|
||||||
The most significant Type will be used, by default, but note that this
|
obtaining a CW expressing the Types which are in common to both systems.
|
||||||
assumes that new bundling Types will be increasingly more efficient or
|
The most significant Type will be used, by default, but note that this
|
||||||
in some way more beneficial.
|
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
|
Because this may not always be the case, there should be a method provided,
|
||||||
the case.
|
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
|
The MSB of the CW is used to indicate whether the mail processor can accept
|
||||||
to be used as a part of the above comparison, however can be used to also
|
UseNet RFC-822 bundles or not. It is a separate indicator, and not intended
|
||||||
advertise RFC-822 capability to other systems. Since RFC-822 is 'set in
|
to be used as a part of the above comparison, however can be used to also
|
||||||
stone', there is no need to assign more than one capability bit.
|
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
|
It might seem somewhat limiting to only consider the possibility of 15
|
||||||
use of a 'Sub-Type' byte in the packet header can allow for the variations
|
different future bundling methods, but it is my opinion that the careful
|
||||||
on a single theme, and that proposals for new formats should be evaluated
|
use of a 'Sub-Type' byte in the packet header can allow for the variations
|
||||||
by the FTSC to determine whether sufficient benefit can be realized in
|
on a single theme, and that proposals for new formats should be evaluated
|
||||||
the implementation of the given format, prior to assigning a new type
|
by the FTSC to determine whether sufficient benefit can be realized in
|
||||||
code.
|
the implementation of the given format, prior to assigning a new type
|
||||||
|
code.
|
||||||
|
|
||||||
Mailers
|
|
||||||
-------
|
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
|
It is quite clear to me that should this concept take hold, that the
|
||||||
database, or an index-associated data file. As above, it is necessary
|
logical place to store node capability data is in the local nodelist
|
||||||
to generate Type-2 packets for whatever purpose, unless it is known
|
database, or an index-associated data file. As above, it is necessary
|
||||||
by prior association, that the far mailer can accept other types of
|
to generate Type-2 packets for whatever purpose, unless it is known
|
||||||
packets. It is also quite reasonable to assume that a nodelist flag
|
by prior association, that the far mailer can accept other types of
|
||||||
could be assigned to advertise the CW for a given node, which the
|
packets. It is also quite reasonable to assume that a nodelist flag
|
||||||
native mailer nodelist compiler could then immediately determine the
|
could be assigned to advertise the CW for a given node, which the
|
||||||
preferred bundling method for any given node in FidoNet.
|
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
|
Another possibility would be to pass a capability advertisement in the
|
||||||
exist in FidoNet.
|
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
|
The approach suggested previously in this document suggests the use of
|
||||||
can be realized through the use of the nodelist, including the use of
|
a text configuration file, but it is quite obvious that many benefits
|
||||||
additional flags to indicate the preferred compression method, etc.
|
can be realized through the use of the nodelist, including the use of
|
||||||
|
additional flags to indicate the preferred compression method, etc.
|
||||||
|
|
||||||
Summary
|
|
||||||
-------
|
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
|
This document has been created in an attempt to define a method to allow
|
||||||
and mailers, and in a way that is the least disruptive to existing mail
|
the future expansion and enhancement of FidoNet technology mail processors
|
||||||
operations. The intent is to provide for an environment that is as open,
|
and mailers, and in a way that is the least disruptive to existing mail
|
||||||
and extensible as possible.
|
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
|
The mechanism described should allow many different types of processors
|
||||||
environment which is designed to operate at it's maximum efficiency
|
(FTSC-registered) to exist in the network at once, and to provide an
|
||||||
wherever possible or practical.
|
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
|
Revision 2 of this document was produced to implement suggestions made
|
||||||
Copy. Jan presented this idea in his FSC-0048, along with other concepts
|
primarily by Jan Vroonhof, who suggested the use of the CW Validation
|
||||||
relating to the correct indentification and handling of zone and point
|
Copy. Jan presented this idea in his FSC-0048, along with other concepts
|
||||||
addressing. This document sanctions the improvements to the CW as
|
relating to the correct indentification and handling of zone and point
|
||||||
recommended, but does not address or support the other extensions
|
addressing. This document sanctions the improvements to the CW as
|
||||||
recommended in FSC-0048.
|
recommended, but does not address or support the other extensions
|
||||||
|
recommended in FSC-0048.
|
||||||
|
|
||||||
Thanks
|
|
||||||
------
|
Thanks
|
||||||
To Ward Christensen, creator of XModem and BYE.
|
------
|
||||||
|
To Ward Christensen, creator of XModem and BYE.
|
||||||
Tom Jennings, who started this whole mess.
|
|
||||||
|
Tom Jennings, who started this whole mess.
|
||||||
Joaquim Homrighausen, for lots of good ideas, and motivation. Here's
|
|
||||||
another Lamborghini to work on.
|
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
|
Wynn Wagner, Oliver McDonald, Roeland Meyer, Andrew Farmer, Claude
|
||||||
contributed in some way to the creation of this document, mostly
|
Warren, Jan Vroonhof, Bob Hartman, and Vince Perriello, who all
|
||||||
through their messages in NET_DEV.
|
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)
|
|
||||||
-----------------------------------------------------
|
Type-2 Packet Format (proposed, but currently in use)
|
||||||
Field Ofs Siz Type Description Expected value(s)
|
-----------------------------------------------------
|
||||||
------- --- --- ---- -------------------------- -----------------
|
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
|
OrgNode 0x0 2 Word Origination node address 0-65535
|
||||||
Year 4 2 Int Year packet generated 19??-2???
|
DstNode 2 2 Word Destination node address 1-65535
|
||||||
Month 6 2 Int Month " " 0-11 (0=Jan)
|
Year 4 2 Int Year packet generated 19??-2???
|
||||||
Day 8 2 Int Day " " 1-31
|
Month 6 2 Int Month " " 0-11 (0=Jan)
|
||||||
Hour A 2 Int Hour " " 0-23
|
Day 8 2 Int Day " " 1-31
|
||||||
Min C 2 Int Minute " " 0-59
|
Hour A 2 Int Hour " " 0-23
|
||||||
Sec E 2 Int Second " " 0-59
|
Min C 2 Int Minute " " 0-59
|
||||||
Baud 10 2 Int Baud Rate (not in use) ????
|
Sec E 2 Int Second " " 0-59
|
||||||
PktVer 12 2 Int Packet Version Always 2
|
Baud 10 2 Int Baud Rate (not in use) ????
|
||||||
OrgNet 14 2 Word Origination net address 1-65535
|
PktVer 12 2 Int Packet Version Always 2
|
||||||
DstNet 16 2 Word Destination net address 1-65535
|
OrgNet 14 2 Word Origination net address 1-65535
|
||||||
PrdCodL 18 1 Byte FTSC Product Code (lo) 1-255
|
DstNet 16 2 Word Destination net address 1-65535
|
||||||
* PVMajor 19 1 Byte FTSC Product Rev (major) 1-255
|
PrdCodL 18 1 Byte FTSC Product Code (lo) 1-255
|
||||||
Password 1A 8 Char Packet password A-Z,0-9
|
* PVMajor 19 1 Byte FTSC Product Rev (major) 1-255
|
||||||
* QOrgZone 22 2 Int Orig Zone (ZMailQ,QMail) 1-65535
|
Password 1A 8 Char Packet password A-Z,0-9
|
||||||
* QDstZone 24 2 Int Dest Zone (ZMailQ,QMail) 1-65535
|
* QOrgZone 22 2 Int Orig Zone (ZMailQ,QMail) 1-65535
|
||||||
Filler 26 2 Byte Spare Change ?
|
* QDstZone 24 2 Int Dest Zone (ZMailQ,QMail) 1-65535
|
||||||
| * CapValid 28 2 Word CW Byte-Swapped Valid Copy BitField
|
Filler 26 2 Byte Spare Change ?
|
||||||
* PrdCodH 2A 1 Byte FTSC Product Code (hi) 1-255
|
| * CapValid 28 2 Word CW Byte-Swapped Valid Copy BitField
|
||||||
* PVMinor 2B 1 Byte FTSC Product Rev (minor) 1-255
|
* PrdCodH 2A 1 Byte FTSC Product Code (hi) 1-255
|
||||||
* CapWord 2C 2 Word Capability Word BitField
|
* PVMinor 2B 1 Byte FTSC Product Rev (minor) 1-255
|
||||||
* OrigZone 2E 2 Int Origination Zone 1-65535
|
* CapWord 2C 2 Word Capability Word BitField
|
||||||
* DestZone 30 2 Int Destination Zone 1-65535
|
* OrigZone 2E 2 Int Origination Zone 1-65535
|
||||||
* OrigPoint 32 2 Int Origination Point 1-65535
|
* DestZone 30 2 Int Destination Zone 1-65535
|
||||||
* DestPoint 34 2 Int Destination Point 1-65535
|
* OrigPoint 32 2 Int Origination Point 1-65535
|
||||||
* ProdData 36 4 Long Product-specific data Whatever
|
* DestPoint 34 2 Int Destination Point 1-65535
|
||||||
PktTerm 3A 2 Word Packet terminator 0000
|
* ProdData 36 4 Long Product-specific data Whatever
|
||||||
|
PktTerm 3A 2 Word Packet terminator 0000
|
||||||
* - extensions to FTS-0001
|
|
||||||
|
* - extensions to FTS-0001
|
||||||
Ofs, Siz are in hex, other values are decimal.
|
|
||||||
|
Ofs, Siz are in hex, other values are decimal.
|
||||||
|
|
||||||
Zone/Point Aware Mail Processors (probably a partial list)
|
|
||||||
----------------------------------------------------------
|
Zone/Point Aware Mail Processors (probably a partial list)
|
||||||
Prod
|
----------------------------------------------------------
|
||||||
Code Name - Uses QOrg/QDstZone Orig/DestZone Orig/DestPoint
|
Prod
|
||||||
---- ----------- ------------- ------------- --------------
|
Code Name - Uses QOrg/QDstZone Orig/DestZone Orig/DestPoint
|
||||||
0x0C FrontDoor Reads/Updates Yes Yes
|
---- ----------- ------------- ------------- --------------
|
||||||
0x1A DBridge ????? Yes Yes
|
0x0C FrontDoor Reads/Updates Yes Yes
|
||||||
0x45 XRS Reads/Updates Yes Yes
|
0x1A DBridge ????? Yes Yes
|
||||||
0x29 QMail Yes ????? Not point-aware
|
0x45 XRS Reads/Updates Yes Yes
|
||||||
0x35 ZMailQ Yes ????? Not point-aware
|
0x29 QMail Yes ????? Not point-aware
|
||||||
0x3F TosScan Reads/Updates Yes Yes
|
0x35 ZMailQ Yes ????? Not point-aware
|
||||||
|
0x3F TosScan Reads/Updates Yes Yes
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
</PRE>
|
|
||||||
|
</PRE>
|
||||||
<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>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,227 +1,228 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>A Product Identiefier for FidoNet Message Handlers.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>A Product Identiefier for FidoNet Message Handlers.</TITLE>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
</HEAD>
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
Document: FSC-0046
|
<PRE>
|
||||||
Version: 005
|
Document: FSC-0046
|
||||||
Date: 30-Aug-94
|
Version: 005
|
||||||
|
Date: 30-Aug-94
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
A Product Idenfifier for FidoNet Message Handlers
|
|
||||||
|
A Product Idenfifier for FidoNet Message Handlers
|
||||||
Joaquim Homrighausen
|
|
||||||
2:270/17@fidonet or joho@abs.lu
|
Joaquim Homrighausen
|
||||||
|
2:270/17@fidonet or joho@abs.lu
|
||||||
August 30, 1994
|
|
||||||
|
August 30, 1994
|
||||||
Copyright 1994 Joaquim Homrighausen; All rights reserved.
|
|
||||||
|
Copyright 1994 Joaquim Homrighausen; All rights reserved.
|
||||||
|
|
||||||
|
|
||||||
Status of this document:
|
|
||||||
|
Status of this document:
|
||||||
This FSC suggests a proposed protocol for the FidoNet(r) community,
|
|
||||||
and requests discussion and suggestions for improvements.
|
This FSC suggests a proposed protocol for the FidoNet(r) community,
|
||||||
Distribution of this document is unlimited.
|
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.
|
Fido and FidoNet are registered marks of Tom Jennings and Fido
|
||||||
|
Software.
|
||||||
|
|
||||||
Purpose
|
|
||||||
|
Purpose
|
||||||
This document should serve as a guide for the product identfier, PID
|
|
||||||
hereafter, format for FidoNet message handlers. The purpose behind PIDs
|
This document should serve as a guide for the product identfier, PID
|
||||||
is related to my attempt to remove the requirement of Origin lines in
|
hereafter, format for FidoNet message handlers. The purpose behind PIDs
|
||||||
conference mail messages.
|
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
|
While I fully understand that this won't happen in all conferences, I
|
||||||
conferences where all the participants are using software that supports
|
would like to provide the facility to those who can use it (i.e. for
|
||||||
messages without origin lines).
|
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
|
Another use for PIDs is to minimize the excessive amount of information
|
||||||
transportation cost and time of conference mail.
|
some programs put on the tear lines which increases overall
|
||||||
|
transportation cost and time of conference mail.
|
||||||
|
|
||||||
PID
|
|
||||||
|
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).
|
A PID replaces the program identifier often seen on the tear line of
|
||||||
This also allows for better tracking of software causing problems in
|
conference mail messages and is hidden behind a ^A (ASCII SOH, 01h).
|
||||||
conferences.
|
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
|
: Only one PID per message is allowed and should only be added by the
|
||||||
: to someone else may not add additional PIDs. If a PID is added, no
|
: program that creates the message. I.e. programs passing the message on
|
||||||
: program information may be present after the tear line.
|
: 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
|
A PID also offers the ability to add serial numbers to identify a
|
||||||
or no effort.
|
specific copy of a program as being the source of a message with little
|
||||||
|
or no effort.
|
||||||
|
|
||||||
Format
|
|
||||||
|
Format
|
||||||
^APID: <pID> <version>[ <serial#>]<CR>
|
|
||||||
|
^APID: <pID> <version>[ <serial#>]<CR>
|
||||||
|
|
||||||
Sample
|
|
||||||
|
Sample
|
||||||
^APID: FM 2.11.b<CR>
|
|
||||||
|
^APID: FM 2.11.b<CR>
|
||||||
Would identify FrontDoor's editor, beta version 2.11 and replace:
|
|
||||||
|
Would identify FrontDoor's editor, beta version 2.11 and replace:
|
||||||
--- FM 2.11 (beta)
|
|
||||||
|
--- FM 2.11 (beta)
|
||||||
|
|
||||||
Fields
|
|
||||||
|
Fields
|
||||||
pID The ID of the product responsible for creating the message.
|
|
||||||
This should be kept as short as possible. The maximum
|
pID The ID of the product responsible for creating the message.
|
||||||
length for this field is 10 characters.
|
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
|
version The version of the product including any alpha, beta, or
|
||||||
be included. I.e. 1.00 should be expressed as 1, 1.10 as
|
gamma status. Only the relevant part of the version should
|
||||||
1.1 and 1.01 as 1.01. Alpha, beta, or gamma status should
|
be included. I.e. 1.00 should be expressed as 1, 1.10 as
|
||||||
be expressed by appending a / or . followed by a, b, or g
|
1.1 and 1.01 as 1.01. Alpha, beta, or gamma status should
|
||||||
and optionally a revision indicator, such as a1, b2, etc.
|
be expressed by appending a / or . followed by a, b, or g
|
||||||
The maximum length for this field is 10 characters.
|
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)
|
serial# The serial number of the product, omitted if irrelevant
|
||||||
characters.
|
or zero. The maximum length for this field is ten (10)
|
||||||
|
characters.
|
||||||
|
|
||||||
TID
|
|
||||||
|
TID
|
||||||
TIDs or "Tosser IDs" started to appear shortly after the first
|
|
||||||
revision of this document was released. They are added by Conference
|
TIDs or "Tosser IDs" started to appear shortly after the first
|
||||||
Mail ("EchoMail") processors when a message is exported from the
|
revision of this document was released. They are added by Conference
|
||||||
local message base and injected into the network distribution scope
|
Mail ("EchoMail") processors when a message is exported from the
|
||||||
for a conference.
|
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
|
When a Conference Mail processor adds a TID to a message, it may not
|
||||||
the same format used for PIDs, as explained above.
|
add a PID. An existing TID should, however, be replaced. TIDs follow
|
||||||
|
the same format used for PIDs, as explained above.
|
||||||
|
|
||||||
List of products
|
|
||||||
|
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 accompanying file, PIDLIST.TXT, is a list of products known to
|
||||||
the author of this document of changes and additions to this list.
|
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>
|
--- end of file "fsc-0046.005" ---
|
||||||
<HR>
|
</PRE>
|
||||||
<PRE>
|
<HR>
|
||||||
Document: PIDLIST.TXT (FSC-0046)
|
<PRE>
|
||||||
Date: 30-Aug-94
|
Document: PIDLIST.TXT (FSC-0046)
|
||||||
|
Date: 30-Aug-94
|
||||||
|
|
||||||
|
|
||||||
A list of used product idenfifiers
|
|
||||||
|
A list of used product idenfifiers
|
||||||
Joaquim Homrighausen
|
|
||||||
2:270/17@fidonet or joho@abs.lu
|
Joaquim Homrighausen
|
||||||
|
2:270/17@fidonet or joho@abs.lu
|
||||||
|
|
||||||
|
|
||||||
Product identifiers
|
|
||||||
|
Product identifiers
|
||||||
Product Version ID Author
|
|
||||||
-----------------------------------------------------------------------------
|
Product Version ID Author
|
||||||
!!MessageBase 1.6+ !!MB Holger Lembke 2:240/500.20
|
-----------------------------------------------------------------------------
|
||||||
Alert 2.1+ Alert Richard Kail 2:310/25.2
|
!!MessageBase 1.6+ !!MB Holger Lembke 2:240/500.20
|
||||||
ANet 921213+ ANet Thomas Ekstroem 2:201/411
|
Alert 2.1+ Alert Richard Kail 2:310/25.2
|
||||||
ArcMail RISC OS 1.04+ AM Philip Blundell 2:440/34.4
|
ANet 921213+ ANet Thomas Ekstroem 2:201/411
|
||||||
Artmail Mailer System 1.00+ ART Klaus Landefeld 2:247/402
|
ArcMail RISC OS 1.04+ AM Philip Blundell 2:440/34.4
|
||||||
Auto Message Taker 1.00+ AMT Patrik Torstensson n/a
|
Artmail Mailer System 1.00+ ART Klaus Landefeld 2:247/402
|
||||||
AVALON 3.10+ AVALON Stephan Slabihoud 2:2401/103.6
|
Auto Message Taker 1.00+ AMT Patrik Torstensson n/a
|
||||||
CrossPoint 2.10+ XP Peter Mandrella 2:243/97.80
|
AVALON 3.10+ AVALON Stephan Slabihoud 2:2401/103.6
|
||||||
EchoSprint 1.02+ ES Ben Elliston 3:620/262
|
CrossPoint 2.10+ XP Peter Mandrella 2:243/97.80
|
||||||
Enhanced Mail MAnager .01+ EMMA Johan Zwiekhorst 2:292/118
|
EchoSprint 1.02+ ES Ben Elliston 3:620/262
|
||||||
Enhanced Message EDitor .02+ EMED Johan Zwiekhorst 2:292/118
|
Enhanced Mail MAnager .01+ EMMA Johan Zwiekhorst 2:292/118
|
||||||
EZMail .67+ EZMail Torben Paving 2:234/41
|
Enhanced Message EDitor .02+ EMED Johan Zwiekhorst 2:292/118
|
||||||
F_POINT 1.1+ F_POINT Florian Rupp 2:248/107.2
|
EZMail .67+ EZMail Torben Paving 2:234/41
|
||||||
FastEcho 1.21a+ FastEcho Tobias Burchhardt 2:245/39
|
F_POINT 1.1+ F_POINT Florian Rupp 2:248/107.2
|
||||||
FileScan 1.5+ FileScan Matthias Duesterhoeft 2:241/4513
|
FastEcho 1.21a+ FastEcho Tobias Burchhardt 2:245/39
|
||||||
Freqit (Windows) 1.0+ FIW Marvin Hart 1:106/462
|
FileScan 1.5+ FileScan Matthias Duesterhoeft 2:241/4513
|
||||||
Freqit (MS-DOS) 1.0+ FID Marvin Hart 1:106/462
|
Freqit (Windows) 1.0+ FIW Marvin Hart 1:106/462
|
||||||
FrontDoor APX 1.00+ FDAPX Joaquim Homrighausen 2:270/17
|
Freqit (MS-DOS) 1.0+ FID Marvin Hart 1:106/462
|
||||||
FrontDoor (Editor) 2.00+ FM Joaquim Homrighausen 2:270/17
|
FrontDoor APX 1.00+ FDAPX Joaquim Homrighausen 2:270/17
|
||||||
FrontDoor (Mailer) 2.00+ FD Joaquim Homrighausen 2:270/17
|
FrontDoor (Editor) 2.00+ FM Joaquim Homrighausen 2:270/17
|
||||||
FrontEnd FX 1.00+ FEFX Eric Theriault 1:132/220
|
FrontDoor (Mailer) 2.00+ FD Joaquim Homrighausen 2:270/17
|
||||||
GEcho 1.00+ GE Gerard van der Land 2:2802/110
|
FrontEnd FX 1.00+ FEFX Eric Theriault 1:132/220
|
||||||
GeeMail 2.00+ GeeMail Lech Szychowski 2:480/4.7
|
GEcho 1.00+ GE Gerard van der Land 2:2802/110
|
||||||
HbToSca 1.00+ HTS Jani Laatikainen 2:220/150
|
GeeMail 2.00+ GeeMail Lech Szychowski 2:480/4.7
|
||||||
HyperBBS 2.00+ HyperBBS Jani Laatikainen 2:220/150
|
HbToSca 1.00+ HTS Jani Laatikainen 2:220/150
|
||||||
JetMail 1.00+ JetMail Daniel Roesen 2:243/93.8
|
HyperBBS 2.00+ HyperBBS Jani Laatikainen 2:220/150
|
||||||
LazyBBS .5+ LazyBBS Franck Arnaud 2:320/100
|
JetMail 1.00+ JetMail Daniel Roesen 2:243/93.8
|
||||||
Mail FX 1.00+ MFX Eric Theriault 1:132/220
|
LazyBBS .5+ LazyBBS Franck Arnaud 2:320/100
|
||||||
MsgTrack 3.20+ MT Andrew Farmer 1:243/1
|
Mail FX 1.00+ MFX Eric Theriault 1:132/220
|
||||||
NewsFlash 1.01+ NwF Chris Lueders 2:2402/330
|
MsgTrack 3.20+ MT Andrew Farmer 1:243/1
|
||||||
NodeDiff Processor 3.00+ NDP Serge Vikulov 2:5080/5
|
NewsFlash 1.01+ NwF Chris Lueders 2:2402/330
|
||||||
Notify 2.1 Notify Frank Schuhardt 2:247/160
|
NodeDiff Processor 3.00+ NDP Serge Vikulov 2:5080/5
|
||||||
OFFFax 3.03 OFFFax Frank Schuhardt 2:247/160
|
Notify 2.1 Notify Frank Schuhardt 2:247/160
|
||||||
Pobble 0.15+ Pobble Josh Parsons 3:771/340
|
OFFFax 3.03 OFFFax Frank Schuhardt 2:247/160
|
||||||
QBBed 2.64+ qbbed Werner Berghofer 2:310/90.100
|
Pobble 0.15+ Pobble Josh Parsons 3:771/340
|
||||||
RemoteAccess 1.10+ RA Andrew Milner 2:270/18
|
QBBed 2.64+ qbbed Werner Berghofer 2:310/90.100
|
||||||
RASS 1.00+ RASS Yossi Gottlieb 2:403/139.75
|
RemoteAccess 1.10+ RA Andrew Milner 2:270/18
|
||||||
SendFile 1.00+ SendFile Mike Shoyher 2:5020/17.3
|
RASS 1.00+ RASS Yossi Gottlieb 2:403/139.75
|
||||||
Synchronet 1.00+ SYNC Rob Swindell 1:103/705
|
SendFile 1.00+ SendFile Mike Shoyher 2:5020/17.3
|
||||||
TB-Edit 1.10+ TB-Edit Arjen Lentz 2:283/512
|
Synchronet 1.00+ SYNC Rob Swindell 1:103/705
|
||||||
TB-Mailer 1.97+ TB-Mailer Arjen Lentz 2:283/512
|
TB-Edit 1.10+ TB-Edit Arjen Lentz 2:283/512
|
||||||
TB-Point .10+ TB-Point Arjen Lentz 2:283/512
|
TB-Mailer 1.97+ TB-Mailer Arjen Lentz 2:283/512
|
||||||
TechBBS 1.00 TECHBBS Marcel Tegelaar 2:281/409
|
TB-Point .10+ TB-Point Arjen Lentz 2:283/512
|
||||||
TechMail 1.00 TECHMAIL Raymond van der Holst 2:281/409.2
|
TechBBS 1.00 TECHBBS Marcel Tegelaar 2:281/409
|
||||||
TosScan 1.10+ TosScan Joaquim Homrighausen 2:270/17
|
TechMail 1.00 TECHMAIL Raymond van der Holst 2:281/409.2
|
||||||
TPCS .89b TPCS Krister Hansson-Renaud 2:201/201.7
|
TosScan 1.10+ TosScan Joaquim Homrighausen 2:270/17
|
||||||
Mikael Kjellstrom 2:201/201.10
|
TPCS .89b TPCS Krister Hansson-Renaud 2:201/201.7
|
||||||
XRobot 3.00+ XRobot Joaquim Homrighausen 2:270/17
|
Mikael Kjellstrom 2:201/201.10
|
||||||
Xrs Alternative Packer 1.04+ XAP Jeroen Smulders 2:512/1.8
|
XRobot 3.00+ XRobot Joaquim Homrighausen 2:270/17
|
||||||
ZeroToss 1.00 ZeroToss Jeff Masud 1:103/115
|
Xrs Alternative Packer 1.04+ XAP Jeroen Smulders 2:512/1.8
|
||||||
-----------------------------------------------------------------------------
|
ZeroToss 1.00 ZeroToss Jeff Masud 1:103/115
|
||||||
|
-----------------------------------------------------------------------------
|
||||||
|
|
||||||
Product identifier registration
|
|
||||||
|
Product identifier registration
|
||||||
Simply fill in the required information and send this form to the author of
|
|
||||||
this document via private netmail.
|
Simply fill in the required information and send this form to the author of
|
||||||
|
this document via private netmail.
|
||||||
Product: _________________________________________
|
|
||||||
|
Product: _________________________________________
|
||||||
Version: __________
|
|
||||||
|
Version: __________
|
||||||
PID info: _________________________________________
|
|
||||||
|
PID info: _________________________________________
|
||||||
Author: _________________________________________
|
|
||||||
|
Author: _________________________________________
|
||||||
Address: ___________________________ (eMail address)
|
|
||||||
|
Address: ___________________________ (eMail address)
|
||||||
--- end of file "pidlist.txt" ---
|
|
||||||
</PRE>
|
--- 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>
|
|
||||||
|
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
|
||||||
</BODY>
|
|
||||||
</HTML>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,417 +1,418 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>A Proposed Type-2 Packet Extension.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>A Proposed Type-2 Packet Extension.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
Document: FSC-0048
|
<PRE>
|
||||||
Version: 002
|
Document: FSC-0048
|
||||||
Date: 21-Oct-90
|
Version: 002
|
||||||
|
Date: 21-Oct-90
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
A Proposed Type-2 Packet Extension
|
|
||||||
Jan Vroonhof
|
A Proposed Type-2 Packet Extension
|
||||||
2:281/1.12@fidonet
|
Jan Vroonhof
|
||||||
Oct 21, 1990
|
2:281/1.12@fidonet
|
||||||
|
Oct 21, 1990
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Status of this document
|
|
||||||
=======================
|
Status of this document
|
||||||
|
=======================
|
||||||
This FSC suggests a proposed protocol for the FidoNet(r)
|
|
||||||
community, and requests discussion and suggestions for
|
This FSC suggests a proposed protocol for the FidoNet(r)
|
||||||
improvements. Distribution of this document is unlimited.
|
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.
|
Fido and FidoNet are registered marks of Tom Jennings and Fido
|
||||||
|
Software.
|
||||||
Purpose
|
|
||||||
=======
|
Purpose
|
||||||
|
=======
|
||||||
The final goal of this document is to become a widely used
|
|
||||||
standardised extension to FTS-0001, like FTS-0006, 0007 and
|
The final goal of this document is to become a widely used
|
||||||
0008 are, and provide an elegant way to switch to a new
|
standardised extension to FTS-0001, like FTS-0006, 0007 and
|
||||||
bundling method without requiring major effort or breaking
|
0008 are, and provide an elegant way to switch to a new
|
||||||
anything.
|
bundling method without requiring major effort or breaking
|
||||||
|
anything.
|
||||||
Prologue
|
|
||||||
========
|
Prologue
|
||||||
|
========
|
||||||
The main thing that needs stressing is that the additions
|
|
||||||
covered by this document are FULLY (I repeat FULLY) BACKWARDS
|
The main thing that needs stressing is that the additions
|
||||||
COMPATIBLE with FTS-0001 (and other existing standards and
|
covered by this document are FULLY (I repeat FULLY) BACKWARDS
|
||||||
practices in FidoNet and WhatEverOtherNets that I know of).
|
COMPATIBLE with FTS-0001 (and other existing standards and
|
||||||
When I say "backwards compatible" I mean that problems it would
|
practices in FidoNet and WhatEverOtherNets that I know of).
|
||||||
create already exist in the current FTS-0001 system (e.g.
|
When I say "backwards compatible" I mean that problems it would
|
||||||
zone conflicts when dealing with a non compliant system). In
|
create already exist in the current FTS-0001 system (e.g.
|
||||||
short it only corrects some flaws in FTS-0001 WITHOUT
|
zone conflicts when dealing with a non compliant system). In
|
||||||
generating new ones.
|
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
|
In this document I have tried to stay as much as possible on
|
||||||
implementation of the additions it proposes will not be too
|
the paths of existing practices. Therefore I think
|
||||||
hard.
|
implementation of the additions it proposes will not be too
|
||||||
|
hard.
|
||||||
! Prologue to revision 2
|
|
||||||
! ======================
|
! Prologue to revision 2
|
||||||
|
! ======================
|
||||||
! Revision 2 of this document reserves a bit in the
|
|
||||||
! CapabilityWord for one bundle type already in use outside of
|
! Revision 2 of this document reserves a bit in the
|
||||||
! FidoNet, RFC-822. A small change was made to the "receiving"
|
! CapabilityWord for one bundle type already in use outside of
|
||||||
! flowchart in order to ensure compatibility with FSC-0039.004.
|
! FidoNet, RFC-822. A small change was made to the "receiving"
|
||||||
! In the process a lot of errors and omissions in the spelling,
|
! flowchart in order to ensure compatibility with FSC-0039.004.
|
||||||
! credits etc. were corrected.
|
! 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.
|
! 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
|
|
||||||
===========================================
|
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
|
First, revision 12 of FTS-0001 introduced the term "(some
|
||||||
! extensions to FTS-0001 (Note that in later revisions this was
|
impls)" to indicate that some implementations used their own
|
||||||
! changed to "optional"). The problem is that this info cannot be
|
! extensions to FTS-0001 (Note that in later revisions this was
|
||||||
relied upon, because there is no way to actually validate the
|
! changed to "optional"). The problem is that this info cannot be
|
||||||
data. One can only check whether the values of these fields are
|
relied upon, because there is no way to actually validate the
|
||||||
in the range of valid values and hope for the best.
|
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
|
Second, FSC-0039 introduced the idea of having a bitfield
|
||||||
was valid. Through the Capability Word, it also made it
|
(called the Capability Word) indicating whether extension data
|
||||||
possible to indicate the ability to support other, non type 2,
|
was valid. Through the Capability Word, it also made it
|
||||||
packets, thus allowing for flexible migration towards type 3.
|
possible to indicate the ability to support other, non type 2,
|
||||||
It also documented the addressing extensions used by various
|
packets, thus allowing for flexible migration towards type 3.
|
||||||
programs.
|
It also documented the addressing extensions used by various
|
||||||
|
programs.
|
||||||
However, FSC-0039 has two flaws:
|
|
||||||
|
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.
|
1. One cannot be sure the bitfield is zero because other
|
||||||
Therefore this document includes a second validation copy
|
implementations might use this field for their own purposes.
|
||||||
for the Capability Word (CW hereafter). This copy allows the
|
Therefore this document includes a second validation copy
|
||||||
FSC-xxxx compliant software to validate the CW by comparing
|
for the Capability Word (CW hereafter). This copy allows the
|
||||||
the two. The chance of some junk portraying itself as a CW
|
FSC-xxxx compliant software to validate the CW by comparing
|
||||||
is significantly reduced by this.
|
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
|
! Please note that the validation copy is byte swapped
|
||||||
! out as a typo, I decided to leave it in as it introduces
|
! compared to the normal capability word. While this started
|
||||||
! some extra safety, without requiring much extra code effort.
|
! out as a typo, I decided to leave it in as it introduces
|
||||||
! In later revisions of FSC-0039, Mark adopted this idea of a
|
! some extra safety, without requiring much extra code effort.
|
||||||
! validation copy too and eliminated the problem.
|
! 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-
|
2. Although FSC-0039 provides a way to make packet headers 4D
|
||||||
0001 sessions to unknown systems, making FidoNet still not
|
it is not backwards compatible. It cannot be used in FTS-
|
||||||
totally 4D capable. Although it implements fields for zone
|
0001 sessions to unknown systems, making FidoNet still not
|
||||||
and point number, an FTS-0001 compliant application is not
|
totally 4D capable. Although it implements fields for zone
|
||||||
required to look at these fields. When a point mails using
|
and point number, an FTS-0001 compliant application is not
|
||||||
these fields to implement its 4D address, a system only
|
required to look at these fields. When a point mails using
|
||||||
looking at the net/node info, as is required by FTS-0001,
|
these fields to implement its 4D address, a system only
|
||||||
still sees it as a boss node, causing the obvious problems.
|
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
|
This document provides a way for transparent point handling,
|
||||||
internally. It will allow this document to be implemented
|
using a technique already exploited by many mailers
|
||||||
and used by mailers not supporting it. At the same time the
|
internally. It will allow this document to be implemented
|
||||||
danger that a point is seen as the boss node is eliminated.
|
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
|
It does NOT provide full inter-zone backwards compatibility,
|
||||||
great. Any measures to ensure backwards compatibility in
|
but that is not needed as badly, as problems are not yet too
|
||||||
this area might harm communication with non-supporting
|
great. Any measures to ensure backwards compatibility in
|
||||||
programs, when the old system could handle the situation.
|
this area might harm communication with non-supporting
|
||||||
|
programs, when the old system could handle the situation.
|
||||||
Packet Header
|
|
||||||
=============
|
Packet Header
|
||||||
|
=============
|
||||||
The "|" character is used to indicate extensions documented in
|
|
||||||
FTS-0001 revision 12, the ":" character indicates those
|
The "|" character is used to indicate extensions documented in
|
||||||
documented here and in FSC-0039.
|
FTS-0001 revision 12, the ":" character indicates those
|
||||||
|
documented here and in FSC-0039.
|
||||||
Offset
|
|
||||||
dec hex
|
Offset
|
||||||
.-----------------------------------------------------.
|
dec hex
|
||||||
0 0 | origNode (low order) | origNode (high order) |
|
.-----------------------------------------------------.
|
||||||
+--------------------------+--------------------------+
|
0 0 | origNode (low order) | origNode (high order) |
|
||||||
2 2 | destNode (low order) | destNode (high order) |
|
+--------------------------+--------------------------+
|
||||||
+--------------------------+--------------------------+
|
2 2 | destNode (low order) | destNode (high order) |
|
||||||
4 4 | year (low order) | year (high order) |
|
+--------------------------+--------------------------+
|
||||||
+--------------------------+--------------------------+
|
4 4 | year (low order) | year (high order) |
|
||||||
6 6 | month (low order) | month (high order) |
|
+--------------------------+--------------------------+
|
||||||
+--------------------------+--------------------------+
|
6 6 | month (low order) | month (high order) |
|
||||||
8 8 | day (low order) | day (high order) |
|
+--------------------------+--------------------------+
|
||||||
+--------------------------+--------------------------+
|
8 8 | day (low order) | day (high order) |
|
||||||
10 A | hour (low order) | hour (high order) |
|
+--------------------------+--------------------------+
|
||||||
+--------------------------+--------------------------+
|
10 A | hour (low order) | hour (high order) |
|
||||||
12 C | minute (low order) | minute (high order) |
|
+--------------------------+--------------------------+
|
||||||
+--------------------------+--------------------------+
|
12 C | minute (low order) | minute (high order) |
|
||||||
14 E | second (low order) | second (high order) |
|
+--------------------------+--------------------------+
|
||||||
+--------------------------+--------------------------+
|
14 E | second (low order) | second (high order) |
|
||||||
16 10 | baud (low order) | baud (high order) |
|
+--------------------------+--------------------------+
|
||||||
+--------------------------+--------------------------+
|
16 10 | baud (low order) | baud (high order) |
|
||||||
18 12 | 0 | 2 | 0 | 0 |
|
+--------------------------+--------------------------+
|
||||||
+--------------------------+--------------------------+
|
18 12 | 0 | 2 | 0 | 0 |
|
||||||
20 14 | origNet (low order) | origNet (high order) |
|
+--------------------------+--------------------------+
|
||||||
: | Set to -1 if from point |
|
20 14 | origNet (low order) | origNet (high order) |
|
||||||
+--------------------------+--------------------------+
|
: | Set to -1 if from point |
|
||||||
22 16 | destNet (low order) | destNet (high order) |
|
+--------------------------+--------------------------+
|
||||||
+--------------------------+--------------------------+
|
22 16 | destNet (low order) | destNet (high order) |
|
||||||
| 24 18 | ProductCode (low order) | Revision (major) |
|
+--------------------------+--------------------------+
|
||||||
| +--------------------------+--------------------------+
|
| 24 18 | ProductCode (low order) | Revision (major) |
|
||||||
| 26 1A | password |
|
| +--------------------------+--------------------------+
|
||||||
| | 8 bytes, null padded |
|
| 26 1A | password |
|
||||||
| +--------------------------+--------------------------+
|
| | 8 bytes, null padded |
|
||||||
|: 34 22 | origZone (low order) | origZone (high order) | }
|
| +--------------------------+--------------------------+
|
||||||
| +--------------------------+--------------------------+ } As in
|
|: 34 22 | origZone (low order) | origZone (high order) | }
|
||||||
|: 36 24 | destZone (low order) | destZone (high order) | } QMail
|
| +--------------------------+--------------------------+ } As in
|
||||||
: +--------------------------+--------------------------+
|
|: 36 24 | destZone (low order) | destZone (high order) | } QMail
|
||||||
: 38 26 | AuxNet (low order) | AuxNet (high order) |
|
: +--------------------------+--------------------------+
|
||||||
: +--------------------------+--------------------------+
|
: 38 26 | AuxNet (low order) | AuxNet (high order) |
|
||||||
: 40 28 | CWvalidationCopy (high) | CWvalidationCopy (low) |
|
: +--------------------------+--------------------------+
|
||||||
: +--------------------------+--------------------------+
|
: 40 28 | CWvalidationCopy (high) | CWvalidationCopy (low) |
|
||||||
: 42 2A | ProductCode (high order) | Revision (minor) |
|
: +--------------------------+--------------------------+
|
||||||
: +--------------------------+--------------------------+
|
: 42 2A | ProductCode (high order) | Revision (minor) |
|
||||||
: 44 2C | CapabilWord (low order) | CapabilWord (high order) |
|
: +--------------------------+--------------------------+
|
||||||
: +--------------------------+--------------------------+
|
: 44 2C | CapabilWord (low order) | CapabilWord (high order) |
|
||||||
: 46 2E | origZone (low order) | origZone (high order) | }
|
: +--------------------------+--------------------------+
|
||||||
: +--------------------------+--------------------------+ } As in
|
: 46 2E | origZone (low order) | origZone (high order) | }
|
||||||
: 48 30 | destZone (low order) | destZone (high order) | } FD etc
|
: +--------------------------+--------------------------+ } As in
|
||||||
: +--------------------------+--------------------------+
|
: 48 30 | destZone (low order) | destZone (high order) | } FD etc
|
||||||
: 50 32 | origPoint (low order) | origPoint (high order) | }
|
: +--------------------------+--------------------------+
|
||||||
: +--------------------------+--------------------------+ } As in
|
: 50 32 | origPoint (low order) | origPoint (high order) | }
|
||||||
: 52 34 | destPoint (low order) | destPoint (high order) | } FD etc
|
: +--------------------------+--------------------------+ } As in
|
||||||
: +--------------------------+--------------------------+
|
: 52 34 | destPoint (low order) | destPoint (high order) | } FD etc
|
||||||
: 54 46 | Product Specific Data |
|
: +--------------------------+--------------------------+
|
||||||
: + +
|
: 54 46 | Product Specific Data |
|
||||||
: | 4 Bytes |
|
: + +
|
||||||
+--------------------------+--------------------------+
|
: | 4 Bytes |
|
||||||
58 3A | zero or more |
|
+--------------------------+--------------------------+
|
||||||
~ packed ~
|
58 3A | zero or more |
|
||||||
| messages |
|
~ packed ~
|
||||||
+--------------------------+--------------------------+
|
| messages |
|
||||||
| 0 | 0 | 0 | 0 |
|
+--------------------------+--------------------------+
|
||||||
'-----------------------------------------------------'
|
| 0 | 0 | 0 | 0 |
|
||||||
|
'-----------------------------------------------------'
|
||||||
Packet = PacketHeader { PakdMessage } 00H 00H
|
|
||||||
|
Packet = PacketHeader { PakdMessage } 00H 00H
|
||||||
PacketHeader = origNode (* of packet, not of messages in packet *)
|
|
||||||
destNode (* of packet, not of messages in packet *)
|
PacketHeader = origNode (* of packet, not of messages in packet *)
|
||||||
year (* of packet creation, e.g. 1986 *)
|
destNode (* of packet, not of messages in packet *)
|
||||||
month (* of packet creation, 0-11 for Jan-Dec *)
|
year (* of packet creation, e.g. 1986 *)
|
||||||
day (* of packet creation, 1-31 *)
|
month (* of packet creation, 0-11 for Jan-Dec *)
|
||||||
hour (* of packet creation, 0-23 *)
|
day (* of packet creation, 1-31 *)
|
||||||
minute (* of packet creation, 0-59 *)
|
hour (* of packet creation, 0-23 *)
|
||||||
second (* of packet creation, 0-59 *)
|
minute (* of packet creation, 0-59 *)
|
||||||
baud (* max baud rate of orig and dest *)
|
second (* of packet creation, 0-59 *)
|
||||||
PacketType (* old type-1 packets now obsolete *)
|
baud (* max baud rate of orig and dest *)
|
||||||
origNet (* of packet, not of messages in packet
|
PacketType (* old type-1 packets now obsolete *)
|
||||||
set to -1 if orig=point *)
|
origNet (* of packet, not of messages in packet
|
||||||
destNet (* of packet, not of messages in packet *)
|
set to -1 if orig=point *)
|
||||||
+ productCode Lo (* 0 for Fido, write to FTSC for others *)
|
destNet (* of packet, not of messages in packet *)
|
||||||
|+ serialNo Maj (* binary serial number (otherwise null) *)
|
+ productCode Lo (* 0 for Fido, write to FTSC for others *)
|
||||||
| password (* session pasword (otherwise null) *)
|
|+ serialNo Maj (* binary serial number (otherwise null) *)
|
||||||
| origZone (* zone of pkt sender (otherwise null) *)
|
| password (* session pasword (otherwise null) *)
|
||||||
| destZone (* zone of pkt receiver (otherwise null) *)
|
| origZone (* zone of pkt sender (otherwise null) *)
|
||||||
| auxNet (* contains Orignet if Origin is a point *)
|
| destZone (* zone of pkt receiver (otherwise null) *)
|
||||||
+! Bytesw. CWvalidationCopy (* Must be equal to CW to be valid *)
|
| auxNet (* contains Orignet if Origin is a point *)
|
||||||
+ ProductCode Hi
|
+! Bytesw. CWvalidationCopy (* Must be equal to CW to be valid *)
|
||||||
+ revision Minor
|
+ ProductCode Hi
|
||||||
+ origZone (* zone of pkt sender (otherwise null) *)
|
+ revision Minor
|
||||||
+ destZone (* zone of pkt receiver (otherwise null) *)
|
+ origZone (* zone of pkt sender (otherwise null) *)
|
||||||
+ ProdData (* Product specific filler *)
|
+ 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.
|
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 ":"
|
Stone-Aged: Old FTS-0001
|
||||||
are valid
|
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
|
A Type-N Bundle will always advertise its capabilities in the
|
||||||
below, the CW allows Type-N processors to automatically track
|
CW regardless of the type being sent. As shown in the example
|
||||||
the capability of your system. Again, in cases where a stone-
|
below, the CW allows Type-N processors to automatically track
|
||||||
age processor is being used, this field will be ignored, and in
|
the capability of your system. Again, in cases where a stone-
|
||||||
the unusual event that it is not ignored, and is somehow
|
age processor is being used, this field will be ignored, and in
|
||||||
harmful to the far system, the Type-N processor can be
|
the unusual event that it is not ignored, and is somehow
|
||||||
configured to send a CW of 0.
|
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
|
The format of the Capability Word is designed to support up to
|
||||||
easy determination of the maximum common level supported
|
15 future bundle types, and is bit-mapped to facilitate the
|
||||||
between two nodes:
|
easy determination of the maximum common level supported
|
||||||
|
between two nodes:
|
||||||
msb Capability Word lsb
|
|
||||||
Node Supports ------------FTSC Type Supported **)------------
|
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+
|
|
||||||
|
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+,3, and 7 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 1
|
||||||
2+ (this Doc) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
|
2+,3, and 5 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1
|
||||||
Stone Age 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
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.
|
! ^-- "U" Indicates nodes able to process RFC-822
|
||||||
** - In the example bit definitions only type 2,
|
! bundles.
|
||||||
and the Stone-Age type, are defined now.
|
** - In the example bit definitions only type 2,
|
||||||
The rest are to be concidered "reserved by
|
and the Stone-Age type, are defined now.
|
||||||
FTSC".
|
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
|
The receiving Type-N bundler would AND the two words, obtaining
|
||||||
receiving and the sending system. The most significant Type
|
a word expressing the Types which are common to both the
|
||||||
will be used for future sessions, by default. Please note that
|
receiving and the sending system. The most significant Type
|
||||||
this assumes that new bundling Types will be increasingly more
|
will be used for future sessions, by default. Please note that
|
||||||
efficient or in some way more beneficial. Because this may not
|
this assumes that new bundling Types will be increasingly more
|
||||||
always be the case, there should be a method provided to
|
efficient or in some way more beneficial. Because this may not
|
||||||
override the automatic upgrade, as illustrated above, should
|
always be the case, there should be a method provided to
|
||||||
this ever happen.
|
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
|
! N.B. The one bit left over (Msb) is now used as indicator for
|
||||||
! the relevant documents themselves.
|
! 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.
|
! For a more explanatory text on using the CW to its full
|
||||||
! Mark also gives some more rationale for the origional idea
|
! potential, refer to the FSC-0039 text by Mark Howard.
|
||||||
! of the CW.
|
! Mark also gives some more rationale for the origional idea
|
||||||
|
! of the CW.
|
||||||
Generating Type-2+ bundles
|
|
||||||
==========================
|
Generating Type-2+ bundles
|
||||||
|
==========================
|
||||||
Do we have a CW Does CW indicate
|
|
||||||
stored for dest? YES ----> higher packets YES ---> Generate higher
|
Do we have a CW Does CW indicate
|
||||||
NO we support? packet
|
stored for dest? YES ----> higher packets YES ---> Generate higher
|
||||||
| NO
|
NO we support? packet
|
||||||
\|/ |
|
| NO
|
||||||
+-----<----------------------+
|
\|/ |
|
||||||
|
|
+-----<----------------------+
|
||||||
Fill header with all info
|
|
|
||||||
|
|
Fill header with all info
|
||||||
\|/
|
|
|
||||||
|
|
\|/
|
||||||
Are we sending from a point? (origPoint != 0) YES --+
|
|
|
||||||
| |
|
Are we sending from a point? (origPoint != 0) YES --+
|
||||||
NO |
|
| |
|
||||||
| \|/
|
NO |
|
||||||
| set AuxNet = OrigNet
|
| \|/
|
||||||
\|/ set OrigNet = -1
|
| set AuxNet = OrigNet
|
||||||
| |
|
\|/ set OrigNet = -1
|
||||||
+-----<----------------------------------------+
|
| |
|
||||||
|
|
+-----<----------------------------------------+
|
||||||
Add Messages
|
|
|
||||||
|
|
Add Messages
|
||||||
Terminate packet
|
|
|
||||||
|
|
Terminate packet
|
||||||
Send packet
|
|
|
||||||
|
Send packet
|
||||||
Receiving Type-2+ bundles
|
|
||||||
=========================
|
Receiving Type-2+ bundles
|
||||||
|
=========================
|
||||||
Receive Packet
|
|
||||||
|
|
Receive Packet
|
||||||
Packettype = 2 NO -------------> Process Type-Other
|
|
|
||||||
YES
|
Packettype = 2 NO -------------> Process Type-Other
|
||||||
|
|
YES
|
||||||
|
|
|
|
||||||
CWcopies match NO --------+------> Treat as normal Stone-Age packet
|
|
|
||||||
YES | |
|
CWcopies match NO --------+------> Treat as normal Stone-Age packet
|
||||||
| | |
|
YES | |
|
||||||
Store CW /|\ |
|
| | |
|
||||||
| | /|\
|
Store CW /|\ |
|
||||||
CW is 0 YES --------------+ |
|
| | /|\
|
||||||
NO |
|
CW is 0 YES --------------+ |
|
||||||
| |
|
NO |
|
||||||
| |
|
| |
|
||||||
CW indicates support for 2+ NO --+
|
| |
|
||||||
YES
|
CW indicates support for 2+ NO --+
|
||||||
|
|
YES
|
||||||
|
|
|
|
||||||
! OrigPoint is not 0 and OrigNet = -1 YES -------+
|
|
|
||||||
NO |
|
! OrigPoint is not 0 and OrigNet = -1 YES -------+
|
||||||
| \|/
|
NO |
|
||||||
! \|/ Set OrigNet is AuxNet
|
| \|/
|
||||||
| |
|
! \|/ Set OrigNet is AuxNet
|
||||||
+------<-----------------------------------+
|
| |
|
||||||
|
|
+------<-----------------------------------+
|
||||||
Process using added info
|
|
|
||||||
|
Process using added info
|
||||||
Credits
|
|
||||||
=======
|
Credits
|
||||||
|
=======
|
||||||
To Mark Howard, for introducing the idea of a CW in his FSC-
|
|
||||||
0039 document and quite rightly pointing out one big omision
|
To Mark Howard, for introducing the idea of a CW in his FSC-
|
||||||
in revision 1 of this document.
|
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
|
To Rick Moore, for doing a good job in processing all these
|
||||||
general.
|
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
|
To Joaquim Homrighausen, for his contributions to FidoNet
|
||||||
reading, discussing and implementing the ideas Mark and I
|
software in general, and especially for his time devoted to
|
||||||
introduced.
|
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
|
To Andre van de Wijdeven, for producing and letting me beta
|
||||||
software around. (I'm not saying available, because it isn't
|
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 john lots, for shipping this stuff to the US.
|
||||||
To Jon Webb, for doing a much needed grammar and spelling
|
|
||||||
check.
|
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
|
To Bob Hartman, Vince Periello, Tom Jennings, Eelco de Graaff,
|
||||||
Nugent, Peter Janssens and many others, for making FidoNet
|
aXel Horst, Arjen van Loon, jim nutt, Odinn Sorensen, David
|
||||||
what it is now, for me and for everybody.
|
Nugent, Peter Janssens and many others, for making FidoNet
|
||||||
|
what it is now, for me and for everybody.
|
||||||
Epilog
|
|
||||||
======
|
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
|
So this it, now it's up to you to decide whether or not to
|
||||||
flowchart and a small incompatibility with the later revisions
|
implement it. A small change was made in the receivers
|
||||||
of FSC-0039 was removed. That will ensure that FSC-0048 and
|
flowchart and a small incompatibility with the later revisions
|
||||||
FSC-0039 mailers can happily talk to each other....
|
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
|
The best way to implement this would be to always support FSC-
|
||||||
default. A switch on a per-node basis will force your software
|
0048 on inbound trafic and generate FSC-0048 on outbound by
|
||||||
to be FSC-0039 or even FSC-0001 only, and you will cover all
|
default. A switch on a per-node basis will force your software
|
||||||
bases.
|
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
|
This can be done easily, as FSC-0048 is a superset of FSC-0039
|
||||||
a superset of FTS-0001 (CW). I'd be glad to get some feedback.
|
(The -1 thing on points being the difference) which in turn is
|
||||||
You can put it in NET_DEV or netmail me.
|
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)
|
|
||||||
|
Jan Vroonhof (2:281/1.12@fidonet)
|
||||||
</PRE>
|
|
||||||
|
</PRE>
|
||||||
<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>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,103 +1,104 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>A Proposal for Passing Domain Information During an FST-0006 Session.</TITLE>
|
<HEAD>
|
||||||
</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
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
Document: FSC-0049
|
<PRE>
|
||||||
Version: 001
|
Document: FSC-0049
|
||||||
Date: 03-Jul-90
|
Version: 001
|
||||||
|
Date: 03-Jul-90
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
A Proposal for
|
|
||||||
Passing Domain Information
|
A Proposal for
|
||||||
During an FTS-0006 Session
|
Passing Domain Information
|
||||||
|
During an FTS-0006 Session
|
||||||
by
|
|
||||||
Bob Hartman
|
by
|
||||||
1:104/501@fidonet.org
|
Bob Hartman
|
||||||
July 3, 1990
|
1:104/501@fidonet.org
|
||||||
|
July 3, 1990
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Status of this document:
|
|
||||||
|
Status of this document:
|
||||||
This FSC suggests a proposed protocol for the FidoNet(r) community,
|
|
||||||
and requests discussion and suggestions for improvements.
|
This FSC suggests a proposed protocol for the FidoNet(r) community,
|
||||||
Distribution of this document is unlimited.
|
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.
|
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
|
FSC-0045 proposes a method for sending five dimensional FidoNet addresses
|
||||||
document describes a proposed method for sending the same five dimensional
|
(ie, zone:net/node.point@domain) via the type 2 packet header. This
|
||||||
address in the Hello packet of an FTS-0006 session, with the additional
|
document describes a proposed method for sending the same five dimensional
|
||||||
advantage of being able to utilize the full Internet recognized domain name
|
address in the Hello packet of an FTS-0006 session, with the additional
|
||||||
for various Fidonet technology networks. This proposal, combined with
|
advantage of being able to utilize the full Internet recognized domain name
|
||||||
FSC-0045 will help to solve one of FidoNet's most pressing problems: How to
|
for various Fidonet technology networks. This proposal, combined with
|
||||||
recognize alternative networks without the need of some centralized
|
FSC-0045 will help to solve one of FidoNet's most pressing problems: How to
|
||||||
management looking at all of them and what they are doing with Zone numbers,
|
recognize alternative networks without the need of some centralized
|
||||||
etc. Like FSC-0045, this proposal remains backwards compatible with what it
|
management looking at all of them and what they are doing with Zone numbers,
|
||||||
is replacing.
|
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
|
Currently FTS-0006 has provisions for zone, net, node, and point information
|
||||||
to be passed, an extra capability bit is used. This bit corresponds to the
|
to be passed in the Hello packet. To extend this to allow the domain name
|
||||||
0x4000 bit, and will be called the DO_DOMAIN bit. If this bit is set, it
|
to be passed, an extra capability bit is used. This bit corresponds to the
|
||||||
means that the sender is domain aware, and has enclosed his domain in the
|
0x4000 bit, and will be called the DO_DOMAIN bit. If this bit is set, it
|
||||||
Hello packet. The domain is stored in the system name field, after the null
|
means that the sender is domain aware, and has enclosed his domain in the
|
||||||
that terminates the real system name. The system name field is a maximum of
|
Hello packet. The domain is stored in the system name field, after the null
|
||||||
60 characters, so the sender must make the real system name, a null, the
|
that terminates the real system name. The system name field is a maximum of
|
||||||
domain name, and another null byte fit within the 60 bytes. The domain will
|
60 characters, so the sender must make the real system name, a null, the
|
||||||
start at the byte immediately after the first null byte. The domain is
|
domain name, and another null byte fit within the 60 bytes. The domain will
|
||||||
arbitrary length and should correspond to the Internet assigned domain name.
|
start at the byte immediately after the first null byte. The domain is
|
||||||
This is NOT the same as the FSC-0045 domain, and therefore there needs to be
|
arbitrary length and should correspond to the Internet assigned domain name.
|
||||||
a mapping between real Internet domains, and the FSC-0045 style domain name,
|
This is NOT the same as the FSC-0045 domain, and therefore there needs to be
|
||||||
if FSC-0045 is accepted by the FTSC as a standard for use by all mailers.
|
a mapping between real Internet domains, and the FSC-0045 style domain name,
|
||||||
This mapping is normally straightforward (for example, Internet fidonet.org
|
if FSC-0045 is accepted by the FTSC as a standard for use by all mailers.
|
||||||
would correspond to FSC-0045 domain FidoNet). Since most alternative nets
|
This mapping is normally straightforward (for example, Internet fidonet.org
|
||||||
do not have a registered Internet domain, the naming convention should be
|
would correspond to FSC-0045 domain FidoNet). Since most alternative nets
|
||||||
"known by" domain (ie, FSC-0045 domain name) followed by .ftn (for FidoNet
|
do not have a registered Internet domain, the naming convention should be
|
||||||
Technology Network). So, the FSC-0045 domain "Alternet" would be converted
|
"known by" domain (ie, FSC-0045 domain name) followed by .ftn (for FidoNet
|
||||||
to alternet.ftn under this proposal. This allows domains which are not
|
Technology Network). So, the FSC-0045 domain "Alternet" would be converted
|
||||||
normally FidoNet aware to use FTS-0006 to talk to FidoNet technology mail
|
to alternet.ftn under this proposal. This allows domains which are not
|
||||||
programs. For example, a mailer located at Camex in Manchester, NH might
|
normally FidoNet aware to use FTS-0006 to talk to FidoNet technology mail
|
||||||
send it's mail as 'man.camex.com' during an FTS-0006 session. When parsing
|
programs. For example, a mailer located at Camex in Manchester, NH might
|
||||||
the domain name, the parsing should try to match the domain from right to
|
send it's mail as 'man.camex.com' during an FTS-0006 session. When parsing
|
||||||
left (Internet naming is hierarchical from right to left), so that if a
|
the domain name, the parsing should try to match the domain from right to
|
||||||
mailer knew about man.camex.com, that could also match something of the form
|
left (Internet naming is hierarchical from right to left), so that if a
|
||||||
super.machine.silly.name.man.camex.com. The domain name should be case
|
mailer knew about man.camex.com, that could also match something of the form
|
||||||
INSENSITIVE, and the FSC-0045 abbreviation of it should be unique within the
|
super.machine.silly.name.man.camex.com. The domain name should be case
|
||||||
first 8 characters, and also should not include any periods ('.') or at-signs
|
INSENSITIVE, and the FSC-0045 abbreviation of it should be unique within the
|
||||||
('@') since those characters are significant in the Internet domain naming
|
first 8 characters, and also should not include any periods ('.') or at-signs
|
||||||
scheme.
|
('@') 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
|
In order for this proposal to be adopted, the FTSC would have to assign the
|
||||||
backwards compatible, since a domain aware mailer could send the domain
|
DO_DOMAIN bit, and have it documented in FTS-0006. This method is fully
|
||||||
information, and if the other end was not domain aware, it would ignore it.
|
backwards compatible, since a domain aware mailer could send the domain
|
||||||
If the other end was domain aware, it would be able to extract the domain
|
information, and if the other end was not domain aware, it would ignore it.
|
||||||
information easily and would then have a full five dimensional address
|
If the other end was domain aware, it would be able to extract the domain
|
||||||
available for the sender. This proposal remains fully backward compatible
|
information easily and would then have a full five dimensional address
|
||||||
with the current uses of all FTS-0006 fields, and should not affect operation
|
available for the sender. This proposal remains fully backward compatible
|
||||||
of any mailer that has used reserved bytes in the Hello packet.
|
with the current uses of all FTS-0006 fields, and should not affect operation
|
||||||
</PRE>
|
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>
|
|
||||||
|
<A HREF="./"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
|
||||||
</BODY>
|
|
||||||
</HTML>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,98 +1,99 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>A Character Set Identifier For FidoNet Message Editors.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>A Character Set Identifier For FidoNet Message Editors.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
Document: FSC-0050
|
<PRE>
|
||||||
Version: 001
|
Document: FSC-0050
|
||||||
Date: 14-Jul-90
|
Version: 001
|
||||||
|
Date: 14-Jul-90
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
A Character Set Identifier For FidoNet Message Editors
|
|
||||||
|
A Character Set Identifier For FidoNet Message Editors
|
||||||
Draft I
|
|
||||||
|
Draft I
|
||||||
Thomas Sundblom
|
|
||||||
2:201/114@fidonet
|
Thomas Sundblom
|
||||||
|
2:201/114@fidonet
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Status of this document:
|
|
||||||
|
Status of this document:
|
||||||
This FSC suggests a proposed protocol for the FidoNet(r) community,
|
|
||||||
and requests discussion and suggestions for improvements.
|
This FSC suggests a proposed protocol for the FidoNet(r) community,
|
||||||
Distribution of this document is unlimited.
|
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.
|
Fido and FidoNet are registered marks of Tom Jennings and Fido
|
||||||
|
Software.
|
||||||
|
|
||||||
Purpose
|
|
||||||
|
Purpose
|
||||||
This document should serve as a guide for the character set
|
|
||||||
identifier, CHARSET hereafter, format for FidoNet message Editors.
|
This document should serve as a guide for the character set
|
||||||
The purpose behind CHARSET is related to my attempt to make it
|
identifier, CHARSET hereafter, format for FidoNet message Editors.
|
||||||
easier for each reader of a FidoNet message to identify the
|
The purpose behind CHARSET is related to my attempt to make it
|
||||||
characters used in the messages.
|
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
|
Since FidoNet messages aren't restricted to use any special character
|
||||||
kinds and special country dependent characters. To avoid confusion
|
sets in the messages, there will be differences between computer
|
||||||
in such cases, I'm hereby introducing the CHARSET kludge.
|
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
|
There is no need that each FidoNet Message reader should be able
|
||||||
handle the special character set found in a message, then it should
|
to understand every possible character set. If the reader can't
|
||||||
use a default character set (as most readers do today).
|
handle the special character set found in a message, then it should
|
||||||
|
use a default character set (as most readers do today).
|
||||||
|
|
||||||
Format
|
|
||||||
|
Format
|
||||||
^aCHARSET: <Character set identifier>
|
|
||||||
|
^aCHARSET: <Character set identifier>
|
||||||
Sample
|
|
||||||
|
Sample
|
||||||
^aCHARSET: ISO-11
|
|
||||||
|
^aCHARSET: ISO-11
|
||||||
Would identify that the message is written using the ISO-11
|
|
||||||
character set, which relates to the character set mainly used
|
Would identify that the message is written using the ISO-11
|
||||||
in Sweden.
|
character set, which relates to the character set mainly used
|
||||||
|
in Sweden.
|
||||||
|
|
||||||
Supported character sets
|
|
||||||
|
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
|
No special character set is specified, but it is recomended to
|
||||||
ISO number is available, an easy to understand code should by used.
|
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
|
|
||||||
|
Character set identifier examples
|
||||||
ISO-6 Relates to plain ASCII 7 bit character set.
|
|
||||||
ISO-11 Swedish character set, 7 bit.
|
ISO-6 Relates to plain ASCII 7 bit character set.
|
||||||
ISO-21 Germany character set, 7 bit.
|
ISO-11 Swedish character set, 7 bit.
|
||||||
ISO-69 French 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.
|
Other character set identifiers could be
|
||||||
ATARI ATARI ST complete character set
|
PC-8 IBM PC complete character set.
|
||||||
AMIGA AMIGA complete character set
|
ATARI ATARI ST complete character set
|
||||||
</PRE>
|
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>
|
|
||||||
|
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
|
||||||
</BODY>
|
|
||||||
</HTML>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,187 +1,188 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>Specifications for the ^aFLAGS field.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>Specifications for the ^aFLAGS field.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
Document: FSC-0053
|
<PRE>
|
||||||
Version: 002
|
Document: FSC-0053
|
||||||
Date: 08-Dec-92
|
Version: 002
|
||||||
|
Date: 08-Dec-92
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Specifications for the ^aFLAGS field
|
|
||||||
|
Specifications for the ^aFLAGS field
|
||||||
Joaquim H. Homrighausen
|
|
||||||
2:270/17@fidonet or joho@ae.lu
|
Joaquim H. Homrighausen
|
||||||
|
2:270/17@fidonet or joho@ae.lu
|
||||||
December 8, 1992
|
|
||||||
|
December 8, 1992
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Status of this document:
|
|
||||||
|
Status of this document:
|
||||||
This FSC suggests a proposed protocol for the FidoNet(r) community,
|
|
||||||
and requests discussion and suggestions for improvements.
|
This FSC suggests a proposed protocol for the FidoNet(r) community,
|
||||||
Distribution of this document is unlimited.
|
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.
|
Fido and FidoNet are registered marks of Tom Jennings and Fido
|
||||||
|
Software.
|
||||||
|
|
||||||
Purpose
|
|
||||||
|
Purpose
|
||||||
To explain and document the existing usage of the ^aFLAGS field used
|
|
||||||
by many software packages, including FrontDoor, TosScan, and
|
To explain and document the existing usage of the ^aFLAGS field used
|
||||||
D'Bridge. And to inform software authors of its proper usage.
|
by many software packages, including FrontDoor, TosScan, and
|
||||||
|
D'Bridge. And to inform software authors of its proper usage.
|
||||||
|
|
||||||
Prologue
|
|
||||||
|
Prologue
|
||||||
One of the problems with the FTS-1 (stored) message format is its
|
|
||||||
limitations in regards to message attributes. Several bits are used
|
One of the problems with the FTS-1 (stored) message format is its
|
||||||
(reserved) by SEAdog, another by several packers and editors - even
|
limitations in regards to message attributes. Several bits are used
|
||||||
though most mailer authors don't support them, they remain. One
|
(reserved) by SEAdog, another by several packers and editors - even
|
||||||
reason would be backward compatibility with older software.
|
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
|
Unfortunately, this presents a problem for software authors that
|
||||||
by other software.
|
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
|
Some software packages have been using an alternate method called
|
||||||
the beginning of a message. The various flags will now be described.
|
"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
|
|
||||||
|
Flags
|
||||||
The FLAGS string should be placed somewhere near the beginning of
|
|
||||||
the message text, and is preceeded by a <SOH> (^a) character. There
|
The FLAGS string should be placed somewhere near the beginning of
|
||||||
is no need to support all or any of the below mentioned flags.
|
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
|
If flags are stripped when a message passes through a system, all
|
||||||
the original contents of the FLAGS field.
|
relevant and correct FTS-1 status bits should be updated to indicate
|
||||||
|
the original contents of the FLAGS field.
|
||||||
|
|
||||||
Flag Brief Long description
|
|
||||||
--------------------------------------------------------------------
|
Flag Brief Long description
|
||||||
PVT Private Indicates that the message may only be read
|
--------------------------------------------------------------------
|
||||||
by its addressee and author.
|
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.
|
HLD Hold Message should be held for pickup by its
|
||||||
|
destination system.
|
||||||
CRA Crash High-priority mail.
|
|
||||||
|
CRA Crash High-priority mail.
|
||||||
K/S Kill/Sent Remove message after it has been success-
|
|
||||||
fully sent.
|
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).
|
SNT Sent Message has been successfully sent (used
|
||||||
|
for message without Kill/Sent status).
|
||||||
RCV Received Message has been read by its addressee.
|
|
||||||
|
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.
|
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.
|
DIR Direct Message must be sent directly to its
|
||||||
|
destination and may not be routed.
|
||||||
ZON Zonegate Send message through zonegate (if
|
|
||||||
possible).
|
ZON Zonegate Send message through zonegate (if
|
||||||
|
possible).
|
||||||
HUB Hub/Host-route Host- or Hub-route message (as
|
|
||||||
appropriate).
|
HUB Hub/Host-route Host- or Hub-route message (as
|
||||||
|
appropriate).
|
||||||
FIL File attach Message has one or more files attached to
|
|
||||||
it.
|
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.
|
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
|
IMM Immediate NOW!-priority mail. Send at first
|
||||||
restrictions enforced by events, costs, or
|
opportunity, override any transmission
|
||||||
qualification.
|
restrictions enforced by events, costs, or
|
||||||
|
qualification.
|
||||||
XMA Xmail Message has alternate form of compressed
|
|
||||||
mail attached.
|
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
|
KFS Kill file Remove attached file(s) after they have
|
||||||
attach message.
|
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.
|
TFS Truncate file Truncate attached file(s) to zero length
|
||||||
Only valid for file attach message.
|
after they have been successfully sent.
|
||||||
Primarily used by Conference Mail
|
Only valid for file attach message.
|
||||||
processors.
|
Primarily used by Conference Mail
|
||||||
|
processors.
|
||||||
LOK Lock Prevent message from being processed.
|
|
||||||
This includes sending, deleting,
|
LOK Lock Prevent message from being processed.
|
||||||
purging, and editing.
|
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
|
RRQ Receipt REQ When the mailer/packer at the message's
|
||||||
asked to generate a receipt to the author
|
final destination unpacks the message, it's
|
||||||
of the message that indicates that the
|
asked to generate a receipt to the author
|
||||||
message arrived at its final destination.
|
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
|
CFM Confirm REQ When message is read by its addressee, a
|
||||||
the author of the message.
|
Confirmation Receipt should be generated to
|
||||||
|
the author of the message.
|
||||||
HIR HiRes FAX: Hi-Resolution image.
|
|
||||||
|
HIR HiRes FAX: Hi-Resolution image.
|
||||||
COV CoverLetter FAX: Cover sheet.
|
|
||||||
|
COV CoverLetter FAX: Cover sheet.
|
||||||
SIG Signature FAX: Signature.
|
|
||||||
|
SIG Signature FAX: Signature.
|
||||||
LET LetterHead FAX: LetterHead.
|
|
||||||
|
LET LetterHead FAX: LetterHead.
|
||||||
| FAX Fax image The filename specified in the message's
|
|
||||||
| subject field contains a fax document that
|
| FAX Fax image The filename specified in the message's
|
||||||
| should be viewed using software capable of
|
| subject field contains a fax document that
|
||||||
| doing so.
|
| 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
|
| FPU Force pickup Treated as a message with an IMM flag. This
|
||||||
| destination system, if the connection is
|
| instructs the mailer to keep calling the
|
||||||
| aborted for some reason, until a valid "End
|
| destination system, if the connection is
|
||||||
| of files" signal is received (i.e. no more
|
| aborted for some reason, until a valid "End
|
||||||
| files remain to pick up).
|
| of files" signal is received (i.e. no more
|
||||||
|
| files remain to pick up).
|
||||||
|
|
||||||
Notes
|
|
||||||
|
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
|
Xmail is related to the ARCmail 0.60 standard as adopted by the FTSC.
|
||||||
the naming convention isn't necessarily limited to that of the
|
The exception is that any type of compression method may be used and
|
||||||
ARCmail 0.60 standard.
|
the naming convention isn't necessarily limited to that of the
|
||||||
|
ARCmail 0.60 standard.
|
||||||
|
|
||||||
Epilogue
|
|
||||||
|
Epilogue
|
||||||
Feedback would be appreciated and can be sent to me at the addresses
|
|
||||||
specified on the title page. Please send feedback via netmail.
|
Feedback would be appreciated and can be sent to me at the addresses
|
||||||
</PRE>
|
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>
|
|
||||||
|
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
|
||||||
</BODY>
|
|
||||||
</HTML>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -1,363 +1,364 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>A Proposed Nodelist flag indicating Online Times of a Node.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>A Proposed Nodelist flag indicating Online Times of a Node.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
| Document: FSC-0062
|
<PRE>
|
||||||
| Version: 003
|
| Document: FSC-0062
|
||||||
| Date: April 14, 1996
|
| Version: 003
|
||||||
| Author: David J. Thomas
|
| Date: April 14, 1996
|
||||||
|
| Author: David J. Thomas
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
A Proposed Nodelist flag indicating Online Times of a Node
|
|
||||||
David J. Thomas
|
A Proposed Nodelist flag indicating Online Times of a Node
|
||||||
2:442/600@fidonet.org
|
David J. Thomas
|
||||||
|
2:442/600@fidonet.org
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Status of this document:
|
|
||||||
|
Status of this document:
|
||||||
This FSC suggests a proposed protocol for the FidoNet(r) community,
|
|
||||||
and requests discussion and suggestions for improvements.
|
This FSC suggests a proposed protocol for the FidoNet(r) community,
|
||||||
Distribution of this document is unlimited.
|
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.
|
Fido and FidoNet are registered marks of Tom Jennings and Fido
|
||||||
|
Software.
|
||||||
Note
|
|
||||||
----
|
Note
|
||||||
|
----
|
||||||
Changes in content between the previous edition of this document, and this
|
|
||||||
edition, are signified by bars (|) in the left margin, except where
|
Changes in content between the previous edition of this document, and this
|
||||||
otherwise specified. I have changed the format of the document slightly to
|
edition, are signified by bars (|) in the left margin, except where
|
||||||
allow this. Where the format of the document has changed, but the actual
|
otherwise specified. I have changed the format of the document slightly to
|
||||||
text has not, bars are not present.
|
allow this. Where the format of the document has changed, but the actual
|
||||||
|
text has not, bars are not present.
|
||||||
Purpose
|
|
||||||
-------
|
Purpose
|
||||||
|
-------
|
||||||
There are currently several systems within FidoNet that offer file request
|
|
||||||
or mail holding capabilities but are not continuously online. The only time
|
There are currently several systems within FidoNet that offer file request
|
||||||
during which these nodes can be contacted with reference to the nodelist is
|
or mail holding capabilities but are not continuously online. The only time
|
||||||
currently the Zone Mail Hour of the zone to which the systems belong. In
|
during which these nodes can be contacted with reference to the nodelist is
|
||||||
theory, mailers can only use the zone mail hour(s) specified by the system
|
currently the Zone Mail Hour of the zone to which the systems belong. In
|
||||||
in question to contact these nodes, which does not provide for any method
|
theory, mailers can only use the zone mail hour(s) specified by the system
|
||||||
of file requesting or calling for echomail that does not conflict with the
|
in question to contact these nodes, which does not provide for any method
|
||||||
Policy requirement that no echomail or files be transferred during the zone
|
of file requesting or calling for echomail that does not conflict with the
|
||||||
mail hour. This means that, in practice, if it is known that a particular
|
Policy requirement that no echomail or files be transferred during the zone
|
||||||
node is online for more time than ZMH alone, but less than 24 hours a day,
|
mail hour. This means that, in practice, if it is known that a particular
|
||||||
it is necessary to "kludge," or set this up as a special situation, in most
|
node is online for more time than ZMH alone, but less than 24 hours a day,
|
||||||
mailers whenever a node has to be contacted a number of times, whether
|
it is necessary to "kludge," or set this up as a special situation, in most
|
||||||
regularly or irregularly. The proposed flag would benefit the mailers in
|
mailers whenever a node has to be contacted a number of times, whether
|
||||||
such a way as to provide for them the online times that the node is usually
|
regularly or irregularly. The proposed flag would benefit the mailers in
|
||||||
online for, thus cutting on the costs of calling a non-continuous mail
|
such a way as to provide for them the online times that the node is usually
|
||||||
node, only to find that it is not available; and also, hopefully preventing
|
online for, thus cutting on the costs of calling a non-continuous mail
|
||||||
annoyance for a sysop whose mailer is being called whilst it is not online,
|
node, only to find that it is not available; and also, hopefully preventing
|
||||||
for example in the case of a voice/data shared line.
|
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
|
|
||||||
-------------
|
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
|
Since the current nodelist format is always being extended and nodelist
|
||||||
expected compatibility problems with the suggestion outlined below.
|
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
|
|
||||||
----------------------------------
|
Format of additional nodelist flag
|
||||||
|
----------------------------------
|
||||||
The proposed nodelist flag has the following form:
|
|
||||||
|
The proposed nodelist flag has the following form:
|
||||||
Txy
|
|
||||||
|
Txy
|
||||||
where x represents the startup time, and y the end time, in the following
|
|
||||||
format:
|
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|
|
+------+----+ +------+----+ +------+----+ +------+----+ +------+----+
|
||||||
+------+----+ +------+----+ +------+----+ +------+----+ +------+----+
|
|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|
|
| A |0000| | F |0500| | K |1000| | P |1500| | U |2000|
|
||||||
| B |0100| | G |0600| | L |1100| | Q |1600| | V |2100|
|
| a |0030| | f |0530| | k |1030| | p |1530| | u |2030|
|
||||||
| b |0130| | g |0630| | l |1130| | q |1630| | v |2130|
|
| B |0100| | G |0600| | L |1100| | Q |1600| | V |2100|
|
||||||
| C |0200| | H |0700| | M |1200| | R |1700| | W |2200|
|
| b |0130| | g |0630| | l |1130| | q |1630| | v |2130|
|
||||||
| c |0230| | h |0730| | m |1230| | r |1730| | w |2230|
|
| C |0200| | H |0700| | M |1200| | R |1700| | W |2200|
|
||||||
| D |0300| | I |0800| | N |1300| | S |1800| | X |2300|
|
| c |0230| | h |0730| | m |1230| | r |1730| | w |2230|
|
||||||
| d |0330| | i |0830| | n |1330| | s |1830| | x |2330|
|
| D |0300| | I |0800| | N |1300| | S |1800| | X |2300|
|
||||||
| E |0400| | J |0900| | O |1400| | T |1900| | | |
|
| d |0330| | i |0830| | n |1330| | s |1830| | x |2330|
|
||||||
| e |0430| | j |0930| | o |1430| | t |1930| | | |
|
| 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
|
| This flag is not intended to be a user flag. The flag is intended to provide
|
||||||
| human beings (although they can of course interpret the meaning of the
|
| information to computerised mailer processes, and is not easily read by
|
||||||
| flag); most mailers however do not attempt to interpret any information that
|
| human beings (although they can of course interpret the meaning of the
|
||||||
| is specified as a user flag, assuming that it is there for the benefit of
|
| flag); most mailers however do not attempt to interpret any information that
|
||||||
| human beings. Such mailers would not be able to make use of the information
|
| is specified as a user flag, assuming that it is there for the benefit of
|
||||||
| provided, which is the purpose of the flag.
|
| 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
|
| This flag is of course not specified in FTS-0005 at the time of writing, but
|
||||||
| use are not specified in FTS-0005.
|
| 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
|
The case of the letter could be relevant. Whereas the case is currently not
|
||||||
nodelist, there exists the potential for the case of a letter to have
|
used by any flags in the document describing the current format of the
|
||||||
relevant meaning. The case has to be correct for the CRC check calculation
|
nodelist, there exists the potential for the case of a letter to have
|
||||||
to prove correct, and this would be a good use for the case of the letter.
|
relevant meaning. The case has to be correct for the CRC check calculation
|
||||||
If it is necessary to ignore the case, then the upper on-the-hour time
|
to prove correct, and this would be a good use for the case of the letter.
|
||||||
should be used, i.e. the time that is listed after the upper-case 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
|
| These times are expressed in UTC so that the flag is useful for systems all
|
||||||
included in the nodelist. They do not adjust with daylight saving time for a
|
around the world, without the need for specific time zone information to be
|
||||||
similar reason. Note the section on daylight saving time for information
|
included in the nodelist. They do not adjust with daylight saving time for a
|
||||||
about handling adjustments without changing the flag; this is important.
|
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
|
Where necessary, the times can wrap around midnight, so for example, for a
|
||||||
would be a valid indication of this time.
|
| 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
|
This nodelist entry is not required by any node. It is supplementary to the
|
||||||
meaning is different. It has been suggested to me about the possibility of
|
#01, #02, #08, #09, #18, #20 flags and their !xx counterparts, though its
|
||||||
an additional flag with the same meaning, but having a W as the first
|
meaning is different. It has been suggested to me about the possibility of
|
||||||
letter, indicating that the node is also available for all hours during
|
an additional flag with the same meaning, but having a W as the first
|
||||||
weekends; however, I believe that the simple inclusion of the single flag
|
letter, indicating that the node is also available for all hours during
|
||||||
indicated above will solve most problems, as it does indicate a period for
|
weekends; however, I believe that the simple inclusion of the single flag
|
||||||
non-CM nodes during which the node is available, which is all that is
|
indicated above will solve most problems, as it does indicate a period for
|
||||||
really required.
|
non-CM nodes during which the node is available, which is all that is
|
||||||
|
really required.
|
||||||
Daylight saving time
|
|
||||||
--------------------
|
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),
|
If a node changes online times with respect to UTC when daylight saving
|
||||||
then this is to be taken into account when assigning this flag. An online
|
time becomes effective (which would be the case with most part time nodes),
|
||||||
times flag assigned to a node should not be altered for the specific
|
then this is to be taken into account when assigning this flag. An online
|
||||||
purpose of adjusting due to daylight saving time, since large difference
|
times flag assigned to a node should not be altered for the specific
|
||||||
files (NODEDIFF's) would result if every node was allowed to do this, e.g.
|
purpose of adjusting due to daylight saving time, since large difference
|
||||||
my node used to be online from 2300 to 0800 in local time, which in winter
|
files (NODEDIFF's) would result if every node was allowed to do this, e.g.
|
||||||
| is UTC, but in the summer it becomes BST (British Summer Time). This is one
|
my node used to be online from 2300 to 0800 in local time, which in winter
|
||||||
| hour ahead of UTC, and the corresponding availability times of my node
|
| is UTC, but in the summer it becomes BST (British Summer Time). This is one
|
||||||
| during the summer period were 2200 to 0700 UTC. Therefore my online times
|
| hour ahead of UTC, and the corresponding availability times of my node
|
||||||
flag would have indicated availability between the hours of 2300 and 0700
|
| during the summer period were 2200 to 0700 UTC. Therefore my online times
|
||||||
| UTC, the daily time period encompassing both times, so the flag would be
|
flag would have indicated availability between the hours of 2300 and 0700
|
||||||
TXH.
|
| UTC, the daily time period encompassing both times, so the flag would be
|
||||||
|
TXH.
|
||||||
Policy considerations
|
|
||||||
---------------------
|
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
|
This is a technical document. However, since the flag could make for an
|
||||||
following guidelines should be adopted concerning the use of the flag.
|
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
|
The online times flag does not replace the requirement for exclusivity of
|
||||||
this flag and be unavailable during ZMH, just as it is annoying behaviour
|
zone mail hour to be maintained. It is still annoying behaviour to have
|
||||||
to have the CM (continuous mail) flag in one's entry, and disregard ZMH.
|
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
|
Except for during ZMH, the sysop of a node using this flag finding that
|
||||||
perform system maintenance, or for any other reason, would not be acting in
|
they need to take their mailer offline during the specified times to
|
||||||
an annoying manner to do so, unless the practice is found to be continuous,
|
perform system maintenance, or for any other reason, would not be acting in
|
||||||
in which case the flag's times could be reduced, or the flag itself could
|
an annoying manner to do so, unless the practice is found to be continuous,
|
||||||
be removed from their node entry.
|
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
|
It should be noted that this flag is present for the benefit of mailers,
|
||||||
when a mailer is ready to receive calls. A system that uses a FidoNet-
|
not human beings. This means that the flag should be used only to indicate
|
||||||
technology mailer in ZMH, and a human-access only system during other
|
when a mailer is ready to receive calls. A system that uses a FidoNet-
|
||||||
period(s) of the day that cannot receive mail, should not use this flag.
|
technology mailer in ZMH, and a human-access only system during other
|
||||||
This flag does not explicitly specify online times of a public access BBS,
|
period(s) of the day that cannot receive mail, should not use this flag.
|
||||||
although for presumably most nodes with FidoNet-capable software, a public
|
This flag does not explicitly specify online times of a public access BBS,
|
||||||
access BBS will be available during the times indicated.
|
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
|
Where the flag is used, it should not often be changed. If a situation
|
||||||
first two weeks of a month, and a different set of times during the
|
exists, for example, where a node uses a certain set of times during the
|
||||||
remainder period, the flag should be set to a time during each day of the
|
first two weeks of a month, and a different set of times during the
|
||||||
month when the node is online. For example, if a node is online during
|
remainder period, the flag should be set to a time during each day of the
|
||||||
1800-0800 for the first two weeks, and then during 2200-1000 for the
|
month when the node is online. For example, if a node is online during
|
||||||
remainder, the time flag should specify 2200-0800 only. If there is no such
|
1800-0800 for the first two weeks, and then during 2200-1000 for the
|
||||||
time (other than ZMH) then no flag should be used. Of course, any permanent
|
remainder, the time flag should specify 2200-0800 only. If there is no such
|
||||||
changes, and any necessary reductions in the times, should be permitted at
|
time (other than ZMH) then no flag should be used. Of course, any permanent
|
||||||
any time, but changes owing only to daylight saving time should certainly
|
changes, and any necessary reductions in the times, should be permitted at
|
||||||
be expressly forbidden.
|
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).
|
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
|
The above list may seem rather frightening! Please note that they are
|
||||||
rules. In the vast majority of situations where a node is online for a
|
guidelines rather than rules, unless FidoNet policy has included them as
|
||||||
fixed set of hours per day, the only thing to watch out for is that you get
|
rules. In the vast majority of situations where a node is online for a
|
||||||
the daylight saving time period right. Then you don't have to worry about
|
fixed set of hours per day, the only thing to watch out for is that you get
|
||||||
changing it at any time, except when your own online times change.
|
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
|
|
||||||
-------
|
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
|
With regard to time zones now; this is a complicated topic, so I wish to
|
||||||
time period beginning 6 o'clock pm (1800) and ending 8 o'clock am (0800).
|
express an example. Imagine a node in Indiana, USA. It is online for the
|
||||||
This changes with daylight saving time, so the times expressed effectively
|
time period beginning 6 o'clock pm (1800) and ending 8 o'clock am (0800).
|
||||||
| become an hour earlier with respect to UTC during daylight saving time.
|
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.
|
| Indiana is in the Central time zone, which is 6 hours behind UTC. Therefore,
|
||||||
| During daylight saving time, however, the local time for Indiana is 5 hours
|
| the online times in UTC can be expressed as 0000-1400 UTC during winter.
|
||||||
| behind UTC. The online times during this period are 0100-1500 UTC. The
|
| During daylight saving time, however, the local time for Indiana is 5 hours
|
||||||
| subset should be used, so that the online times flag for the node should
|
| behind UTC. The online times during this period are 0100-1500 UTC. The
|
||||||
| indicate availability between 0100 and 1400 UTC, which is indicated
|
| subset should be used, so that the online times flag for the node should
|
||||||
| by the flag TBO.
|
| 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
|
| (Thanks to a few people for pointing out that the previous example was in
|
||||||
| actually the case.)
|
| 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
|
|
||||||
--------------------------------------------------
|
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.
|
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
|
The first program calculates the online times flag from the user's entry of
|
||||||
offset to UTC used by the user's country. It takes into account that the
|
the online times of a system, expressed in the local time zone, and the
|
||||||
clock is put forward and back once a year by reducing the end time by one
|
offset to UTC used by the user's country. It takes into account that the
|
||||||
hour. The program should work on any platform, and has been tested.
|
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
|
=== start of code ===
|
||||||
Calculates FSC-0062 time flag requirement from user input */
|
/* TIMEFLAG.C
|
||||||
|
Calculates FSC-0062 time flag requirement from user input */
|
||||||
#include <stdio.h>
|
|
||||||
|
#include <stdio.h>
|
||||||
char *onlineflag(char *on, char *off, int utc_diff);
|
|
||||||
|
char *onlineflag(char *on, char *off, int utc_diff);
|
||||||
void main()
|
|
||||||
{
|
void main()
|
||||||
char on[6], off[6]; int utc_diff;
|
{
|
||||||
|
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 online [HH:MM]: ");
|
||||||
printf("\nPlease specify the time you come offline [HH:MM]: ");
|
scanf("%s", on);
|
||||||
scanf("%s", off);
|
printf("\nPlease specify the time you come offline [HH:MM]: ");
|
||||||
printf("\nSpecify the difference between your local time zone in winter\n"
|
scanf("%s", off);
|
||||||
"time and UTC (e.g. if your time zone is 6 hours behind UTC,\n"
|
printf("\nSpecify the difference between your local time zone in winter\n"
|
||||||
"enter 6): ");
|
"time and UTC (e.g. if your time zone is 6 hours behind UTC,\n"
|
||||||
scanf("%d", &utc_diff);
|
"enter 6): ");
|
||||||
printf("\nYour online time flag is %s\n\n",
|
scanf("%d", &utc_diff);
|
||||||
onlineflag(on, off, utc_diff));
|
printf("\nYour online time flag is %s\n\n",
|
||||||
}
|
onlineflag(on, off, utc_diff));
|
||||||
|
}
|
||||||
char *onlineflag(char *ontime, char *offtime, int utcdiff)
|
|
||||||
{
|
char *onlineflag(char *ontime, char *offtime, int utcdiff)
|
||||||
int onhour, onmin, offhour, offmin;
|
{
|
||||||
static char flag[4]="T ";
|
int onhour, onmin, offhour, offmin;
|
||||||
|
static char flag[4]="T ";
|
||||||
sscanf(ontime, "%d:%d", &onhour, &onmin);
|
|
||||||
sscanf(offtime, "%d:%d", &offhour, &offmin);
|
sscanf(ontime, "%d:%d", &onhour, &onmin);
|
||||||
|
sscanf(offtime, "%d:%d", &offhour, &offmin);
|
||||||
if(onmin>30) ++onhour;
|
|
||||||
--offhour; /* to correct for daylight saving time */
|
if(onmin>30) ++onhour;
|
||||||
onhour = (onhour+24+utcdiff) % 24;
|
--offhour; /* to correct for daylight saving time */
|
||||||
offhour = (offhour+24+utcdiff) % 24;
|
onhour = (onhour+24+utcdiff) % 24;
|
||||||
|
offhour = (offhour+24+utcdiff) % 24;
|
||||||
flag[1]='A'+onhour;
|
|
||||||
flag[2]='A'+offhour;
|
flag[1]='A'+onhour;
|
||||||
|
flag[2]='A'+offhour;
|
||||||
if(onmin>0 && onmin<31) flag[1] += 'a'-'A';
|
|
||||||
if(offmin>29) flag[2] += 'a'-'A';
|
if(onmin>0 && onmin<31) flag[1] += 'a'-'A';
|
||||||
|
if(offmin>29) flag[2] += 'a'-'A';
|
||||||
return flag;
|
|
||||||
}
|
return flag;
|
||||||
=== end of code ===
|
}
|
||||||
|
=== 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
|
The second program calculates the online times from the time flag, input
|
||||||
returns a pointer to a structure which contains the on- and off-times in
|
as a pointer to char to the routine (this being of the format "Txy"). It
|
||||||
UTC. This is not a complete program; it is designed to be used by mailers
|
returns a pointer to a structure which contains the on- and off-times in
|
||||||
to determine the valid online times. It has also been tested.
|
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
|
=== start of code ===
|
||||||
Interprets online time flags and converts them to a set of UTC times */
|
/* INTFLAG.C
|
||||||
|
Interprets online time flags and converts them to a set of UTC times */
|
||||||
struct TIMES {
|
|
||||||
int on_hour;
|
struct TIMES {
|
||||||
int on_min;
|
int on_hour;
|
||||||
int off_hour;
|
int on_min;
|
||||||
int off_min;
|
int off_hour;
|
||||||
};
|
int off_min;
|
||||||
|
};
|
||||||
struct TIMES *interpret_flag(char *time_flag);
|
|
||||||
|
struct TIMES *interpret_flag(char *time_flag);
|
||||||
struct TIMES *interpret_flag(char *timeflag)
|
|
||||||
{
|
struct TIMES *interpret_flag(char *timeflag)
|
||||||
static struct TIMES times;
|
{
|
||||||
|
static struct TIMES times;
|
||||||
times.on_min=0;
|
|
||||||
times.off_min=0;
|
times.on_min=0;
|
||||||
|
times.off_min=0;
|
||||||
times.on_hour=timeflag[1]-'A';
|
|
||||||
if(times.on_hour>23) {
|
times.on_hour=timeflag[1]-'A';
|
||||||
times.on_hour -= 'a'-'A';
|
if(times.on_hour>23) {
|
||||||
times.on_min=30;
|
times.on_hour -= 'a'-'A';
|
||||||
}
|
times.on_min=30;
|
||||||
times.off_hour=timeflag[2]-'A';
|
}
|
||||||
if(times.off_hour>23) {
|
times.off_hour=timeflag[2]-'A';
|
||||||
times.off_hour -= 'a'-'A';
|
if(times.off_hour>23) {
|
||||||
times.off_min=30;
|
times.off_hour -= 'a'-'A';
|
||||||
}
|
times.off_min=30;
|
||||||
return ×
|
}
|
||||||
}
|
return ×
|
||||||
=== end of code ===
|
}
|
||||||
|
=== 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! :-)
|
| 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
|
|
||||||
-------
|
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
|
I believe this to be a neat and compact solution to, what is in my opinion,
|
||||||
nodes are continuous mail, but it is important for the growth and
|
one of the gravest problems currently facing FidoNet. In FidoNet, most
|
||||||
popularity of FidoNet that non-CM nodes do not receive many mailer calls at
|
nodes are continuous mail, but it is important for the growth and
|
||||||
times when they are off line. Users are bad enough in this respect. It is
|
popularity of FidoNet that non-CM nodes do not receive many mailer calls at
|
||||||
also useful for people wishing to contact hubs that are non-CM with mail
|
times when they are off line. Users are bad enough in this respect. It is
|
||||||
for a downlink, and for people wishing to file request from a node that is
|
also useful for people wishing to contact hubs that are non-CM with mail
|
||||||
not CM. There is no need for systems that are only online in zone mail hour
|
for a downlink, and for people wishing to file request from a node that is
|
||||||
to adopt this flag; also, there is no need for CM systems to adopt this
|
not CM. There is no need for systems that are only online in zone mail hour
|
||||||
flag.
|
to adopt this flag; also, there is no need for CM systems to adopt this
|
||||||
|
flag.
|
||||||
Contacting the Author
|
|
||||||
---------------------
|
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).
|
My board is now online continuously, except for periods of down time during
|
||||||
Netmail contact is therefore possible at any time. I went CM because of a
|
| which the board is maintained (few and far between now that Linux is used).
|
||||||
certain number of nodes calling at the wrong times, and also users. Users
|
Netmail contact is therefore possible at any time. I went CM because of a
|
||||||
weren't too bad, but I dislike 0600 am wake-up calls, repeated at regular
|
certain number of nodes calling at the wrong times, and also users. Users
|
||||||
three-minute intervals for an hour, by mailers, rather intensely :-)
|
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>
|
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>
|
|
||||||
|
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
|
||||||
</BODY>
|
|
||||||
</HTML>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,122 +1,123 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>Improving FidoNet/UseNet gating and Dupe Checking.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>Improving FidoNet/UseNet gating and Dupe Checking.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
Document: FSC-0070
|
<PRE>
|
||||||
Date: 15-Jul-94
|
Document: FSC-0070
|
||||||
Revision: 002
|
Date: 15-Jul-94
|
||||||
|
Revision: 002
|
||||||
Improving Fidonet/Usenet gating and Dupe Checking
|
|
||||||
|
Improving Fidonet/Usenet gating and Dupe Checking
|
||||||
Franck Arnaud, Fidonet 2:320/213.666
|
|
||||||
|
Franck Arnaud, Fidonet 2:320/213.666
|
||||||
|
|
||||||
|
|
||||||
Status of this document
|
|
||||||
-----------------------
|
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 FSC suggests a proposed standard for the FidoNet(r) community,
|
||||||
this document is unlimited.
|
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.
|
|
||||||
|
Fido and FidoNet are registered marks of Tom Jennings and Fido Software.
|
||||||
|
|
||||||
Introduction
|
|
||||||
------------
|
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
|
The complexity of Usenet/Fidonet gating and the large number of gateways
|
||||||
both the Usenet and Fidonet worlds. This proposal defines a standard method
|
has led to a non-negligible quantity of duplicates appearing regularly in
|
||||||
for gateway software to deal with conversion of message identifiers between
|
both the Usenet and Fidonet worlds. This proposal defines a standard method
|
||||||
both worlds, so that we can improve the reliability of Usenet/Fidonet
|
for gateway software to deal with conversion of message identifiers between
|
||||||
gateways.
|
both worlds, so that we can improve the reliability of Usenet/Fidonet
|
||||||
|
gateways.
|
||||||
In this document "^" means <control-A> (character 01h).
|
|
||||||
|
In this document "^" means <control-A> (character 01h).
|
||||||
|
|
||||||
History
|
|
||||||
-------
|
History
|
||||||
|
-------
|
||||||
Revision 002 adds details and makes the Fidonet to Usenet sheme FTS-0009
|
|
||||||
compliant.
|
Revision 002 adds details and makes the Fidonet to Usenet sheme FTS-0009
|
||||||
|
compliant.
|
||||||
|
|
||||||
Usenet To Fidonet Message Identifier Conversion
|
|
||||||
-----------------------------------------------
|
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
|
A major problem is preventing messages gated into Fidonet from RFC822 from
|
||||||
easy way to solve that is simply to store the RFC message ID in a kludge
|
being gated back to Usenet at another gateway with a new message id. The
|
||||||
line. This kludge line could also allow identifying messages gated from
|
easy way to solve that is simply to store the RFC message ID in a kludge
|
||||||
Usenet (this could be used by message editors to allow private replies to
|
line. This kludge line could also allow identifying messages gated from
|
||||||
the nearest uucp gateway for example).
|
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
|
It is proposed that the ^RFCID: kludge is used to store the RFC Message-ID:
|
||||||
the standard fts-0009 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
|
(Usenet) Message-ID: <92_feb_10_19192012901@prep.ai.mit.edu>
|
||||||
^RFCID: 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 ">".
|
|
||||||
|
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.
|
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
|
|
||||||
------------------------------------------------
|
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).
|
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
|
So it would be interesting if the same Fidonet message gated at different
|
||||||
stopping dupes.
|
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 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,
|
The ^MSGID: value (a string) is not parsed and converted as below to the ID
|
||||||
"fidonet.org" if the gated echomail comes from the Fidonet(tm) network.
|
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).
|
To convert the MSGID string, the following rules are applied:
|
||||||
- Non-alphanumeric characters - including the space beetwen the origin
|
- Alphanumeric (a-z,A-Z,0-9) characters are kept intact (case preserved).
|
||||||
address and the serial number - are converted to '-'.
|
- Non-alphanumeric characters - including the space beetwen the origin
|
||||||
|
address and the serial number - are converted to '-'.
|
||||||
Some examples:
|
|
||||||
|
Some examples:
|
||||||
(Fido) ^MSGID: 2:300/400 12345AbC
|
|
||||||
to (Usenet) Message-ID: <2-300-400-12345AbC@fidonet.org>
|
(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: 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: 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>
|
(Fido) ^MSGID: "LZKkoe$1982 98a" 45678bcd
|
||||||
|
to (Usenet) Message-ID: <-LZKkoe-1982-98a--45678bcd@fidonet.org>
|
||||||
|
|
||||||
</PRE>
|
|
||||||
|
</PRE>
|
||||||
<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>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
File diff suppressed because it is too large
Load Diff
@ -1,305 +1,306 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>File Forwarding in Fidonet Technology Networks.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>File Forwarding in Fidonet Technology Networks.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
| Document: FSC-0087
|
<PRE>
|
||||||
| Version: 001
|
| Document: FSC-0087
|
||||||
| Date: 31 October, 1995
|
| Version: 001
|
||||||
|
|
| Date: 31 October, 1995
|
||||||
| Robert Williamson FidoNet#1:167/104.0
|
|
|
||||||
|
| Robert Williamson FidoNet#1:167/104.0
|
||||||
File Forwarding in Fidonet Technology Networks
|
|
||||||
Robert Williamson FidoNet#1:167/104.0 robert@ecs.mtlnet.org
|
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
|
Purpose:
|
||||||
requirements and known extensions of the TIC file format.
|
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
|
Acknowledgements:
|
||||||
File Forwarder, Tick. Useful extensions to this format were introduced
|
The TIC file format was introduced by Barry Geller, in the MSDOS
|
||||||
by Harald Helms, in the MSDOS FileForwarder, AllFix.
|
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.
|
Terminology:
|
||||||
Sometimes used interchangably with the term DOMAIN.
|
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.
|
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
|
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.
|
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
|
TIC - a file that contains control information for the File Forwarding
|
||||||
abbreviation representing the File Forwarding program name and
|
system. These files are named xxSTAMP.TIC, where xx is an
|
||||||
stamp is a unixdate stamp truncated to 6 characters.
|
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
|
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.
|
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.
|
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
|
|
||||||
|
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
|
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.
|
|
||||||
|
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.
|
Note that use of UPPERCASE on tic file keywords in this document in
|
||||||
|
for display purposes only.
|
||||||
Format of a TIC file:
|
|
||||||
|
Format of a TIC file:
|
||||||
Addressing:
|
|
||||||
In a tic file any form of FTN address representation from 3d to
|
Addressing:
|
||||||
FQFA may be used. All File Forwarders must understand the
|
In a tic file any form of FTN address representation from 3d to
|
||||||
following formats:
|
FQFA may be used. All File Forwarders must understand the
|
||||||
zone:net/node - 3D
|
following formats:
|
||||||
zone:net/node.point - 4D
|
zone:net/node - 3D
|
||||||
zone:net/node@ftn - 5D - point 0 assumed
|
zone:net/node.point - 4D
|
||||||
zone:net/node.point@ftn - 5D
|
zone:net/node@ftn - 5D - point 0 assumed
|
||||||
ftn#zone:net/node.point - fqfa
|
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.
|
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.
|
Dates:
|
||||||
|
All dates are expressed in UTC.
|
||||||
TimeDateStamps:
|
|
||||||
All TimeDateStamps are unix TimeDateStamps (# of seconds since Jan
|
TimeDateStamps:
|
||||||
1, 1960) in UTC and expressed in hexadecimal notation.
|
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
|
Case Insensitivity:
|
||||||
that the first letter of a keyword is uppercase. This is not a
|
the format is completely case-insensitive. It is general practice
|
||||||
requirement.
|
that the first letter of a keyword is uppercase. This is not a
|
||||||
|
requirement.
|
||||||
Order Dependancy:
|
|
||||||
keywords are not order dependant.
|
Order Dependancy:
|
||||||
Order dependancy is required in some groupings of a keyword, such
|
keywords are not order dependant.
|
||||||
as PATH, VIA, DESC and APP.
|
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
|
Modification of address fields on PassThrough:
|
||||||
to make them compliant with the addressing limitations of each
|
The forwarding site may modify the addresses in any keyword field
|
||||||
downlink.
|
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,
|
Stripping of SeenBys:
|
||||||
when not forwarding outside of current FTN, ZONE or NET. This does
|
The forwarding site may strip seenbys to current FTN, ZONE or NET,
|
||||||
not imply nor permit the stripping of of a direct downlink which is
|
when not forwarding outside of current FTN, ZONE or NET. This does
|
||||||
outside the current strip filter.
|
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.
|
Keywords:
|
||||||
|
There are no colons on keywords.
|
||||||
Each keyword line is terminated with CR LF pair.
|
|
||||||
|
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.
|
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.
|
Keywords are separated from their data by a single space. There is
|
||||||
eg: ReturnReceipt
|
no space if there is no data associated with the keyword.
|
||||||
|
eg: ReturnReceipt
|
||||||
Keywords are case-insensitive and order independant.
|
|
||||||
|
Keywords are case-insensitive and order independant.
|
||||||
Keywords not understood are to be passed-though.
|
|
||||||
|
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
|
Known Keywords that are blank should not be passed though.
|
||||||
blank replaced with the proper description.
|
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
|
Most Keywords are passed through when processing.
|
||||||
may be created.
|
There are exceptions. In some cases, a site-specific replacement
|
||||||
Keywords marked with a ^ should not be passed-through.
|
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
|
Keywords marked with a * are REQUIRED when processing a TIC file.
|
||||||
BAD and the associated file not forwarded to downlinks.
|
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.
|
|
||||||
|
Keywords marked with a # are CREATED when hatching or forwarding.
|
||||||
|
|
||||||
*# AREA [AreaName]
|
|
||||||
the TagName of the file area.
|
*# 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
|
AREADESC [description of area] OPTIONAL
|
||||||
the description found in FileBone.NA
|
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
|
*# FILE [File being sent]
|
||||||
the filename must conform to msdos 8.3 format, unless it is known
|
the name of the file being sent, no path
|
||||||
that the receiving site can handle longer filenames.
|
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
|
^# 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
|
*# 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
|
^ MAGIC [MagicName] OPTIONAL
|
||||||
FROM. This is NOT passed though when forwarding, unless the
|
Name under which the file can be FREQed from the site listed in
|
||||||
MAGIC name is the same on the forwarding site. It can be
|
FROM. This is NOT passed though when forwarding, unless the
|
||||||
replaced by the appropriate name.
|
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
|
REPLACES [FileName] OPTIONAL
|
||||||
associated file replaces. If the site expects FNC files, and the
|
Filename (no path) of a file hatched in the AREA that the
|
||||||
filename does not confrom to msdos 8.3 convention, the REPLACES
|
associated file replaces. If the site expects FNC files, and the
|
||||||
name should also be FNC.
|
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,
|
# DESC [Description]
|
||||||
including CRLF termination.
|
Description of the file, limited to 80 characters per line,
|
||||||
If multiple LDESC lines are used, the DESC line must provide the
|
including CRLF termination.
|
||||||
maximum information. No File Forwadrer is required to passthough
|
If multiple LDESC lines are used, the DESC line must provide the
|
||||||
or make use of any extra DESC line after the first.
|
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
|
# LDESC [multiple lines]
|
||||||
is used IN ADDITION to the short description. No File Forwarder
|
A long description of the file. LDESC does NOT replace DESC, it
|
||||||
is required make use of LESC lines.
|
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
|
# 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.
|
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
|
RELEASE [TimeDateStamp]
|
||||||
be used by ADS as well.
|
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
|
AUTHOR [name]
|
||||||
field is obviously not applicable to Newsletters, Nodelists and
|
Name of the author of the software package being hatched. This
|
||||||
Diffs and the like.
|
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.
|
SOURCE [authors_address]
|
||||||
Not necessary the same as the ORIGIN hatch site. Does not have
|
FTN address of the Author of the software package being hatched.
|
||||||
to be an FTN address.
|
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
|
^ APP [program] [Application Specific Information]
|
||||||
indicated. APP'S are order dependent and must be passed though.
|
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
|
*# ORIGIN [Address]
|
||||||
|
Site where file entered the fileecho
|
||||||
*^# FROM [Address] [Pwd]
|
|
||||||
Site that is forwarding the file to the next site. Pwd is
|
*^# FROM [Address] [Pwd]
|
||||||
optional and rarely used, IF AT ALL. Pwd is NEVER passed through.
|
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.
|
^ TO [Address] OPTIONAL
|
||||||
This keyword is included in the .TIC file when:
|
Site to which this TIC and the assocaited file are being sent.
|
||||||
a) the file is being routed via another system which permits
|
This keyword is included in the .TIC file when:
|
||||||
such routing.
|
a) the file is being routed via another system which permits
|
||||||
b) the platform in use does not have any FTN software
|
such routing.
|
||||||
independant method of associating a file nd it's
|
b) the platform in use does not have any FTN software
|
||||||
destination. eg. platforms that do not have filenotes
|
independant method of associating a file nd it's
|
||||||
that could contain this information as part of the
|
destination. eg. platforms that do not have filenotes
|
||||||
filesystem.
|
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
|
If the address in the TO line is that of the receiving site, the
|
||||||
the TO lines IS NOT that of the receiving site, it should be
|
field is not passed through when forwarding. If the address in
|
||||||
forwarded to the TO site, if a routing agreement is in place with
|
the TO lines IS NOT that of the receiving site, it should be
|
||||||
the sending site.
|
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
|
*^# CREATED [by] [Program Banner]
|
||||||
the form:
|
File Forwarder which created the TIC file. This is generally in
|
||||||
Created [by] program_name version [copyright_info]
|
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
|
VIA [FROM CREATED] OPTIONAL (tracking)
|
||||||
FROM prepended. Always passed though. The VIA is only created
|
Copy of CREATED line of FROM, with 'Created [by]' stripped and
|
||||||
by the receiving site when forwarding. It is never created by the
|
FROM prepended. Always passed though. The VIA is only created
|
||||||
hatching site. Therefore, in any TIC file, the addresses in the
|
by the receiving site when forwarding. It is never created by the
|
||||||
FROM and VIA should never be the same.
|
hatching site. Therefore, in any TIC file, the addresses in the
|
||||||
examples:
|
FROM and VIA should never be the same.
|
||||||
Via 1:167/100 ALLFIX+ 4.31 Copyright (C) 1992,95 Harald Harms (2:281/910)
|
examples:
|
||||||
Via FIDONET#1:167/104.0 XTick 3 Copyright (c) 1995 Robert Williamson FIDONET#1:167/104.0
|
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,
|
*# PATH [Address] [TimeDateStamp] [date and time]
|
||||||
date and time is that of when the Site received and Processed the
|
Address of Site which has forwarded the file. TimeDateStamp,
|
||||||
file.
|
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 [Address]
|
||||||
Seenby and they are unordered.
|
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
|
* PW [password]
|
||||||
least 5 characters in length.
|
Site or Area password. This is case-insensitive and should be at
|
||||||
|
least 5 characters in length.
|
||||||
PGP [signature]
|
|
||||||
PrettyGoodPrivacy signature. To be discussed.
|
PGP [signature]
|
||||||
|
PrettyGoodPrivacy signature. To be discussed.
|
||||||
^ ReceiptRequest -no data- OPTIONAL
|
|
||||||
A request to the receiving system to generate a IsReturnReceipt
|
^ ReceiptRequest -no data- OPTIONAL
|
||||||
(attribute word bit 13) messsage, in the same manner it would if
|
A request to the receiving system to generate a IsReturnReceipt
|
||||||
it had received a message with the FileAttach an ReturnReceipt
|
(attribute word bit 13) messsage, in the same manner it would if
|
||||||
attributes and a subject of the filename.
|
it had received a message with the FileAttach an ReturnReceipt
|
||||||
There is NO requirement to recognize this keyword. It should
|
attributes and a subject of the filename.
|
||||||
never be passed through.
|
There is NO requirement to recognize this keyword. It should
|
||||||
|
never be passed through.
|
||||||
Transmission of Files:
|
|
||||||
|
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,
|
The associated file, that is, the file Listed in the FILE field of the
|
||||||
sending the FILE first prevents the orphaning of the file that is
|
TIC file, should always be sent FIRST. In the case of a failed session,
|
||||||
normally caused by the deletion or movement of the TIC file to BAD.
|
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 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
|
File Forwaders should be transparent to the renaming of file by
|
||||||
renaming or bumpinmg a numeric extension, the File Forwarder should be
|
mailers. This means that if the mailer renames a duplicate file by
|
||||||
able to use the size and crc fields of the TIC to find and properly
|
renaming or bumpinmg a numeric extension, the File Forwarder should be
|
||||||
rename the associated file referred to in the TIC.
|
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
|
File Forwaders should always delete and dequeue unsent TIC files when
|
||||||
implementor may wish to allow exceptions for periodicals such as
|
re-hatching the same or updated version of an associated file. The
|
||||||
nodediffs and newsletters.
|
implementor may wish to allow exceptions for periodicals such as
|
||||||
|
nodediffs and newsletters.
|
||||||
-to be continued-
|
|
||||||
</PRE>
|
-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>
|
|
||||||
|
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
|
||||||
</BODY>
|
|
||||||
</HTML>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,326 +1,327 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>Compatibility and Link Qualifier Extensions for EMSI Sessions</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>Compatibility and Link Qualifier Extensions for EMSI Sessions</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
| Document: FSC-0088
|
<PRE>
|
||||||
| Version: 001
|
| Document: FSC-0088
|
||||||
| Date: 31 October, 1995
|
| Version: 001
|
||||||
|
|
| Date: 31 October, 1995
|
||||||
| Robert Williamson FidoNet#1:167/104.0
|
|
|
||||||
|
| 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
|
Compatibility and Link Qualifier Extensions for EMSI Sessions
|
||||||
|
Robert Williamson FidoNet#1:167/104.0 robert@ecs.mtlnet.org
|
||||||
Purpose:
|
|
||||||
|
Purpose:
|
||||||
The basic purpose of this document is to start discussions which will
|
|
||||||
hopefully result in an improved handshake negotiation protocol.
|
The basic purpose of this document is to start discussions which will
|
||||||
|
hopefully result in an improved handshake negotiation protocol.
|
||||||
Scope:
|
|
||||||
|
Scope:
|
||||||
Relation of flags to Types of files transferred:
|
|
||||||
|
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
|
The FSC-0056 EMSI specification (hereafter referred to as EMSI-I)
|
||||||
files, such as files attached and TIC'ed files. In EMSI-I, the term
|
makes little distinction between ARCmail/packets and other types of
|
||||||
'Mail' when not used in conjunction with the term 'compressed', is
|
files, such as files attached and TIC'ed files. In EMSI-I, the term
|
||||||
interpreted to mean ANY file.
|
'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'.
|
This extension (hereafter referred to as EMSI-II) makes reference to
|
||||||
References to 'Mail' are changed to 'File' where common practice so
|
and allows control of types of files in addition to 'compressed mail'.
|
||||||
indicates. The additional qualifier flags described provide for more
|
References to 'Mail' are changed to 'File' where common practice so
|
||||||
control as to the types of files a system is prepared to receive.
|
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:
|
|
||||||
|
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
|
The EMSI-I specification does not allow qualification for any address
|
||||||
in application to either all presented addresses or to the primary
|
other than the PRIMARY address. This means that Link flags are limited
|
||||||
presented address only.
|
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.
|
This extension also allows application of Link flags to specific
|
||||||
|
addresses other than the primary.
|
||||||
|
|
||||||
Distinctions between Calling and Answering System:
|
|
||||||
|
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
|
In the EMSI-I spec, the type of flags that may be presented is limited
|
||||||
the site is the caller and other flags may only be presented when the
|
by the status of the site. Certain flags may only be presented when
|
||||||
site is the answerer. This proposed extension removes this
|
the site is the caller and other flags may only be presented when the
|
||||||
distinction.
|
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
|
In the EMSI-I spec, certain Link and Capability (a.k.a: Compatibility)
|
||||||
system. This specification attempts to harmonize these discrepancies.
|
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,
|
A attempt is made to remain somewhat backwards compatible and to have
|
||||||
it would be preferable to harmonize the flags; reducing the number of
|
new flags follow the original flag naming convention. However, IMHO,
|
||||||
them while retaining the fine type control, so that the same codes are
|
it would be preferable to harmonize the flags; reducing the number of
|
||||||
used in all sessions.
|
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
|
Under both EMSI-I and EMSI-II, any flags that are not understood, are
|
||||||
format and the other site does not do EMSI-II, it is permissable for
|
to be ignored. Therfore, if a site presents it's flags in EMSI-II
|
||||||
that site to interpret all flags according to EMSI-I specifications.
|
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:
|
|
||||||
|
Specifics:
|
||||||
Compatibility flags:
|
|
||||||
|
Compatibility flags:
|
||||||
Compatibility flags consist of a string of codes that specify the
|
|
||||||
PROTOCOL CAPABILITIES and ENABLED FEATURES of the mailer.
|
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
|
ARC, XMA
|
||||||
transfer of files and are not to be presented under EMSI-II. If
|
These EMSI-I compatibility flags have no meaning relavant to the
|
||||||
received, they are to be ignored.
|
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
|
FNC
|
||||||
the author of EMSI-I. This is agreeable as that specification called
|
The FNC EMSI-I compatibility flag has been identified as a 'mistake' by
|
||||||
for the creation of a filename that was ALWAYS 8.3, not
|
the author of EMSI-I. This is agreeable as that specification called
|
||||||
up-to-8.up-to-3.
|
for the creation of a filename that was ALWAYS 8.3, not
|
||||||
It is not to be presented under EMSI-II. If received as a
|
up-to-8.up-to-3.
|
||||||
compatibility flag, it is to be ignored.
|
It is not to be presented under EMSI-II. If received as a
|
||||||
|
compatibility flag, it is to be ignored.
|
||||||
|
|
||||||
Protocol Selection:
|
|
||||||
|
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
|
In the EMSI-I spec, a requirement is placed upon the calling system to
|
||||||
follows:
|
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
|
The calling system must list supported protocols first and
|
||||||
should be listed first).
|
descending order of preference (the most desirable protocol
|
||||||
The answering system should only present one protocol and it
|
should be listed first).
|
||||||
should be the first item in the compatibility_codes field.
|
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
|
Some mailer authors have interpreted 'the compatibility_codes field' in
|
||||||
making protocol selection RECEIVER-PREFS driven. This interpretation
|
the second sentence to mean that of the answering system, thereby
|
||||||
makes unnecessary the 'decending order' requirement placed upon the
|
making protocol selection RECEIVER-PREFS driven. This interpretation
|
||||||
calling system, so shall be considered in conflict with that
|
makes unnecessary the 'decending order' requirement placed upon the
|
||||||
requirement.
|
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
|
Most mailer authors have interpreted that phrase to mean the
|
||||||
selection CALLER-PREFS driven. Since EMSI-I was intended to be "a
|
'compatibility_codes field' OF THE CALLER, thereby making protocol
|
||||||
clear protocol definition for state-of-the-art E-Mail systems to
|
selection CALLER-PREFS driven. Since EMSI-I was intended to be "a
|
||||||
follow", they cannot be faulted for interpretation. Caller-prefs
|
clear protocol definition for state-of-the-art E-Mail systems to
|
||||||
driven selection is state-of-the-art, receiver-prefs driven selection
|
follow", they cannot be faulted for interpretation. Caller-prefs
|
||||||
is older technolgy, such as Wazoo.
|
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.
|
This specification requires that the second interpretation,
|
||||||
|
CALLER-PREFS driven, be mandatory.
|
||||||
|
|
||||||
New Compatibilty Flags:
|
|
||||||
----------------------
|
New Compatibilty Flags:
|
||||||
|
----------------------
|
||||||
EII
|
|
||||||
Indicates that the system will interpret flags under this
|
EII
|
||||||
specification, if other end also presents this flag. IF either or both
|
Indicates that the system will interpret flags under this
|
||||||
systems do not present this flag, all interpretations are done
|
specification, if other end also presents this flag. IF either or both
|
||||||
according to EMSI-I.
|
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
|
DFB
|
||||||
FTS1/WAZOO negotiation in the case of failure of EMSI handshake or no
|
Indicates that the system presenting is capabable of fall-back to
|
||||||
common protocol. Since ZMO is the minimum required protocol, NCP
|
FTS1/WAZOO negotiation in the case of failure of EMSI handshake or no
|
||||||
should only occur if the answering system presents more than one
|
common protocol. Since ZMO is the minimum required protocol, NCP
|
||||||
protocol.. (ie. it's broken)
|
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
|
FRQ
|
||||||
received during outbound calls. In other words, the calling system
|
Indicates that the system will accept and process file requests
|
||||||
will do a second turnaround for uni-directional protocols, to send the
|
received during outbound calls. In other words, the calling system
|
||||||
files requested, at his cost.
|
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
|
NRQ
|
||||||
server, task or function and cannot accept requests.. It should NOT be
|
NRQ should be presented ONLY IF the mailer does not have a file request
|
||||||
used to indicate that the function is temporarly disabled.
|
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
|
When examined, No requests will be sent. It would be advisable that
|
||||||
continued polling of the remote site.
|
the mailer alert the system operator of this occurance to prevent
|
||||||
|
continued polling of the remote site.
|
||||||
|
|
||||||
Protocol Capabilities:
|
|
||||||
|
Protocol Capabilities:
|
||||||
Protocol capability flags are presented in decending order of
|
|
||||||
preference by the caller. The answering system selects and presents
|
Protocol capability flags are presented in decending order of
|
||||||
the FIRST protocol from the callers list that it supports. The
|
preference by the caller. The answering system selects and presents
|
||||||
answering system must present only ONE protocol.
|
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
|
HYD Hydra bi-directional (link flags define parameters)
|
||||||
TZA DirectZap (TrapDoor DirectZap varient)
|
JAN Janus bi-directional
|
||||||
DZA DirectZap (Zmodem variant, reduced escape set)
|
TZA DirectZap (TrapDoor DirectZap varient)
|
||||||
ZAP ZedZap (Zmodem variant, upe 8K blocks)
|
DZA DirectZap (Zmodem variant, reduced escape set)
|
||||||
ZMO Zmodem w/1,024 packets (Wazoo ZedZip)
|
ZAP ZedZap (Zmodem variant, upe 8K blocks)
|
||||||
SLK SeaLink (no TYSNC, No MDM7, No TeLink)
|
ZMO Zmodem w/1,024 packets (Wazoo ZedZip)
|
||||||
(8-32k window/ReSync/OverDrive/LongNames)
|
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
|
NCP
|
||||||
EMSI. Since in most FTN networks, a common protocol DOES exist,
|
This is presented if no compatible protocol can be negotiated under
|
||||||
fallback to WaZoo and FTS1 negotiation is expected. If these
|
EMSI. Since in most FTN networks, a common protocol DOES exist,
|
||||||
negotiation methods are not available, the session is terminated.
|
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
|
This condition should never occur under normal circumstances. It
|
||||||
one of the mailers involved.
|
should be considered as a problem with the design or configuration of
|
||||||
|
one of the mailers involved.
|
||||||
Link flags:
|
|
||||||
----------
|
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,
|
Link flags consist of a string of codes that specify DESIRED CONNECT
|
||||||
there are four TYPES of link flags: communications parameters, session
|
CONDITIONS. They apply to the CURRENT SESSION ONLY. Under EMSI-I,
|
||||||
parameters, pickup options and hold options. Under EMSI-II, only three
|
there are four TYPES of link flags: communications parameters, session
|
||||||
types are used, the communications parameters type is REMOVED, as it
|
parameters, pickup options and hold options. Under EMSI-II, only three
|
||||||
serves no purpose whatsoever in FTN operations.
|
types are used, the communications parameters type is REMOVED, as it
|
||||||
|
serves no purpose whatsoever in FTN operations.
|
||||||
|
|
||||||
Link Session options:
|
|
||||||
|
Link Session options:
|
||||||
FNC
|
|
||||||
If either system presents this flag, it is an indication that the
|
FNC
|
||||||
presenting system requires filename conversion to cp/m-msdos
|
If either system presents this flag, it is an indication that the
|
||||||
conventions. The other system will convert filenames to cp/m cpm/msdos
|
presenting system requires filename conversion to cp/m-msdos
|
||||||
8.3 conventions before sending.
|
conventions. The other system will convert filenames to cp/m cpm/msdos
|
||||||
The convention is defined as a filename consisting of two
|
8.3 conventions before sending.
|
||||||
parts, the filepart and extension. The filepart and extension are
|
The convention is defined as a filename consisting of two
|
||||||
separated by a period ".". The filepart may be from 1 to 8 characters
|
parts, the filepart and extension. The filepart and extension are
|
||||||
in length and the extension may be from 0 to 3 characters. The
|
separated by a period ".". The filepart may be from 1 to 8 characters
|
||||||
character set shall be any uppercase character in the range A-Z and any
|
in length and the extension may be from 0 to 3 characters. The
|
||||||
numeric character in the range 0-9. If the extension is of zero
|
character set shall be any uppercase character in the range A-Z and any
|
||||||
length, the period may or may not be present.
|
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
|
RMA
|
||||||
file requests. If both sites present this flag, the caller will send
|
Indicates that the presenting site is able to send and process multiple
|
||||||
any REQ files found for each AKA presented by the answering system.
|
file requests. If both sites present this flag, the caller will send
|
||||||
The answering system will process each received REQ.
|
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
|
RH1
|
||||||
requests only, while batch 2 is reserved for all other files.
|
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)
|
|
||||||
|
(others to be defined)
|
||||||
Pickup and Hold Flags:
|
|
||||||
|
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
|
Under the EMSI-I specification, Link Pickup flags are only presented
|
||||||
when answering (an Inbound Session) and Link Hold flags are only
|
when calling (an Outbound Session) and are examined and processed only
|
||||||
presented when answering (an Inbound Session) and are examined and
|
when answering (an Inbound Session) and Link Hold flags are only
|
||||||
processed only when calling (an Outbound Session).
|
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
|
With EMSI-II, BOTH Pickup and Hold flags are presented by both sites
|
||||||
example, which cannot modify addresses presented or rotate akas to
|
during a session. This allows more control for those systems, for
|
||||||
change the primary address presented on a per-session or per-site
|
example, which cannot modify addresses presented or rotate akas to
|
||||||
basis.
|
change the primary address presented on a per-session or per-site
|
||||||
|
basis.
|
||||||
|
|
||||||
Link Pickup and Hold:
|
|
||||||
|
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
|
Each system can present one of three (or more) Link options related to
|
||||||
is to be assumed.
|
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.
|
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
|
PUP Pickup FILES for primary address only
|
||||||
/ PUn Pickup FILES for address number n in AKA list
|
/ PUA Pickup FILES for all presented addresses
|
||||||
one of |
|
/ 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)
|
\ NPU No FILE pickup desired. (calling system)
|
||||||
HAn Hold all FILES for address number n in AKA list
|
HAT Hold all FILES (answering system)
|
||||||
|
HAn Hold all FILES for address number n in AKA list
|
||||||
|
|
||||||
Qualifiers:
|
|
||||||
|
Qualifiers:
|
||||||
Qualifiers are processed in the order presented, with any conflict
|
|
||||||
being resolved by subsequent qualifiers overridding any conflicting
|
Qualifiers are processed in the order presented, with any conflict
|
||||||
previous qualifier in the list.
|
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.
|
Qualifiers may be not be presented with either NPU or HAT and should be
|
||||||
|
ignored if received with NPU or HAT.
|
||||||
PickUp:
|
|
||||||
|
PickUp:
|
||||||
PMO PickUp Mail (ARCmail and Packets) ONLY
|
|
||||||
PMn PickUp Mail ONLY for address number n in AKA list
|
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
|
NFE No TIC'S, associated files or files
|
||||||
NFn No TIC'S, associated files or file attaches,
|
attachs desired
|
||||||
for address number n in AKA list
|
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,
|
NXP No compressed mail pickup desired
|
||||||
for address number n in AKA list
|
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
|
NRQ File requests not accepted by caller
|
||||||
is disabled TEMPORARILY for any reason
|
This flag is presented if file request processing
|
||||||
NRn File requests not accepted by caller
|
is disabled TEMPORARILY for any reason
|
||||||
for address number n in AKA list
|
NRn File requests not accepted by caller
|
||||||
|
for address number n in AKA list
|
||||||
Note that NFE,NPX,NRQ != NPU
|
|
||||||
|
Note that NFE,NPX,NRQ != NPU
|
||||||
Hold:
|
|
||||||
|
Hold:
|
||||||
HNM Hold all traffic EXCEPT Mail (ARCmail and Packets)
|
|
||||||
HNn Hold all traffic EXCEPT Mail (ARCmail and Packets)
|
HNM Hold all traffic EXCEPT Mail (ARCmail and Packets)
|
||||||
for address number n in AKA list
|
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.
|
HXT Hold compressed mail traffic.
|
||||||
for address number n in AKA list
|
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
|
HFE Hold tic's and associated files
|
||||||
HFn Hold tic's and associated files
|
and file attaches other than mail
|
||||||
and file attaches other than mail
|
HFn Hold tic's and associated files
|
||||||
for address number n in AKA list
|
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
|
HRQ Hold file requests (not processed at this time)
|
||||||
is disabled TEMPORARILY for any reason
|
This flag is presented if file request processing
|
||||||
HRn Hold file requests (not processed at this time)
|
is disabled TEMPORARILY for any reason
|
||||||
for address number n in AKA list
|
HRn Hold file requests (not processed at this time)
|
||||||
|
for address number n in AKA list
|
||||||
Note that HXT,HRQ,HFE == HAT
|
|
||||||
</PRE>
|
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>
|
|
||||||
|
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
|
||||||
</BODY>
|
|
||||||
</HTML>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,60 +1,61 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>ISDN nodelist flags (rev.002).</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>ISDN nodelist flags (rev.002).</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
| Document: fsc-0091
|
<PRE>
|
||||||
| Version: 001
|
| Document: fsc-0091
|
||||||
| Date: 01 Jun 1996
|
| Version: 001
|
||||||
| Arjen Lentz, 2:283/512
|
| 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
|
ISDN nodelist flags (rev.002) Arjen Lentz (agl@bitbike.com)
|
||||||
superceding FSC-0075 October 30th, 1995
|
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!
|
|
||||||
|
Input from Michael Buenter, Jan Ceuleers, Chris Lueders, and others. Thanks!
|
||||||
The proposed new information text in nodelist trailer is as follows:
|
|
||||||
|
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
|
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').
|
V110L ITU-T V.110 19k2 async ('low').
|
||||||
V120L ITU-T V.120 56k async, layer 2 framesize 259, window 7, modulo 8.
|
V110H ITU-T V.110 38k4 async ('high').
|
||||||
V120H ITU-T V.120 64k async, layer 2 framesize 259, window 7, modulo 8.
|
V120L ITU-T V.120 56k async, layer 2 framesize 259, window 7, modulo 8.
|
||||||
X75 ITU-T X.75 SLP (single link procedure) with 64kbit/s B channel;
|
V120H ITU-T V.120 64k async, layer 2 framesize 259, window 7, modulo 8.
|
||||||
layer 2 max.framesize 2048, window 2, non-ext.mode (modulo 8);
|
X75 ITU-T X.75 SLP (single link procedure) with 64kbit/s B channel;
|
||||||
layer 3 transparent (no packet layer).
|
layer 2 max.framesize 2048, window 2, non-ext.mode (modulo 8);
|
||||||
ISDN Other configurations. Use *only* if none of the above fits.
|
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.
|
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.
|
Conversion from old to new ISDN capability flags:
|
||||||
Most will be able to change to V120H (64k lines).
|
- Nodes in the USA currently use the 'ISDN' flag.
|
||||||
Also many to V120L,V120H (64k lines) with autodetecting equipment.
|
Most will be able to change to V120H (64k lines).
|
||||||
Some to only V120L (still with 56k lines).
|
Also many to V120L,V120H (64k lines) with autodetecting equipment.
|
||||||
- Nodes in Europe currently use the ISDNA, ISDNB and ISDNC flags.
|
Some to only V120L (still with 56k lines).
|
||||||
A simple translation will do the trick here.
|
- Nodes in Europe currently use the ISDNA, ISDNB and ISDNC flags.
|
||||||
ISDNA -> V110L
|
A simple translation will do the trick here.
|
||||||
ISDNB -> V110H
|
ISDNA -> V110L
|
||||||
ISDNC -> X75
|
ISDNB -> V110H
|
||||||
|
ISDNC -> X75
|
||||||
</PRE>
|
|
||||||
|
</PRE>
|
||||||
<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>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,243 +1,244 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>New control lines for forwarded messages.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>New control lines for forwarded messages.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
| Document: FSC-0092
|
<PRE>
|
||||||
| Version: 001
|
| Document: FSC-0092
|
||||||
| Date: September 12th 1996
|
| Version: 001
|
||||||
| Author: Michael Hohner
|
| Date: September 12th 1996
|
||||||
|
| Author: Michael Hohner
|
||||||
|
|
||||||
New control lines
|
|
||||||
for forwarded messages
|
New control lines
|
||||||
|
for forwarded messages
|
||||||
by
|
|
||||||
Michael Hohner
|
by
|
||||||
2:2490/2520.17
|
Michael Hohner
|
||||||
|
2:2490/2520.17
|
||||||
September 1996
|
|
||||||
|
September 1996
|
||||||
Status of this document:
|
|
||||||
|
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
|
This document proposes a standard for the Fidonet(tm) community
|
||||||
distributed if unchanged.
|
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.
|
You can reach the author at one of the addresses listed at the end
|
||||||
|
of the document.
|
||||||
|
|
||||||
Abstract:
|
|
||||||
|
Abstract:
|
||||||
Most fidonet message editors offer a "forward" function. Using
|
|
||||||
this function a user A can sort of "redirect" a message from user B
|
Most fidonet message editors offer a "forward" function. Using
|
||||||
to another user C, maybe because A is not the correct recipient or
|
this function a user A can sort of "redirect" a message from user B
|
||||||
because C is a better person to answer the message. The name and
|
to another user C, maybe because A is not the correct recipient or
|
||||||
address of B are usually included in the forward in free-text format.
|
because C is a better person to answer the message. The name and
|
||||||
The message text is included in non-quoted format.
|
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
|
A problem arises when the final recipient C wants to reply to sender B
|
||||||
as the sender. So user C must insert the name and address of B
|
of the forwarded message. The forward contains the intermediate user A
|
||||||
manually, using the information contained in the message text. The
|
as the sender. So user C must insert the name and address of B
|
||||||
message editor of C can't do this automatically because of the
|
manually, using the information contained in the message text. The
|
||||||
free-text format. The editor will also use incorrect quote initials,
|
message editor of C can't do this automatically because of the
|
||||||
which is at least irritating.
|
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
|
This document introduces 6 new control lines which contain the header
|
||||||
message editor can use the original header information automatically.
|
information of the original message. With these control lines the
|
||||||
|
message editor can use the original header information automatically.
|
||||||
|
|
||||||
Specifications:
|
|
||||||
|
Specifications:
|
||||||
There are 7 new control lines: FWDFROM, FWDTO, FWDORIG, FWDDEST,
|
|
||||||
FWDSUBJ, FWDAREA, FWDMSGID. As all control lines they start with an
|
There are 7 new control lines: FWDFROM, FWDTO, FWDORIG, FWDDEST,
|
||||||
ASCII 01 character followed by the control line name followed by
|
FWDSUBJ, FWDAREA, FWDMSGID. As all control lines they start with an
|
||||||
whitespace followed by the control line's content followed by ASCII 13.
|
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.
|
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
|
|
||||||
-------
|
FWDFROM
|
||||||
|
-------
|
||||||
This control line contains the name of the original sender as found in
|
|
||||||
the FROM field of the original message. Leading and trailing
|
This control line contains the name of the original sender as found in
|
||||||
whitespace should be removed. This control line should be omitted
|
the FROM field of the original message. Leading and trailing
|
||||||
altogether if the FROM field is empty.
|
whitespace should be removed. This control line should be omitted
|
||||||
|
altogether if the FROM field is empty.
|
||||||
FWDTO
|
|
||||||
-----
|
FWDTO
|
||||||
|
-----
|
||||||
This control line contains the name of the original recipient as found
|
|
||||||
in the TO field of the original message. Leading and trailing
|
This control line contains the name of the original recipient as found
|
||||||
whitespace should be removed. This control line should be omitted
|
in the TO field of the original message. Leading and trailing
|
||||||
altogether if the TO field is empty.
|
whitespace should be removed. This control line should be omitted
|
||||||
|
altogether if the TO field is empty.
|
||||||
FWDORIG
|
|
||||||
-------
|
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
|
This control line contains the address of the original sender as found
|
||||||
(zone:net/node.point@domain) should be used. This control line should
|
in the ORIG field of the original message. The usual 5D ASCII notation
|
||||||
be omitted altogether if the address is not known.
|
(zone:net/node.point@domain) should be used. This control line should
|
||||||
|
be omitted altogether if the address is not known.
|
||||||
FWDDEST
|
|
||||||
-------
|
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
|
This control line contains the address of the original recipient as
|
||||||
notation (zone:net/node.point@domain) should be used. This control line
|
found in the DEST field of the original message. The usual 5D ASCII
|
||||||
should be omitted altogether if the address is not known or unsure
|
notation (zone:net/node.point@domain) should be used. This control line
|
||||||
(as it is the case with forwarded echomail messages).
|
should be omitted altogether if the address is not known or unsure
|
||||||
|
(as it is the case with forwarded echomail messages).
|
||||||
FWDSUBJ
|
|
||||||
-------
|
FWDSUBJ
|
||||||
|
-------
|
||||||
This control line contains the subject line of the original message.
|
|
||||||
This control line should be omitted altogether if the SUBJ field is
|
This control line contains the subject line of the original message.
|
||||||
empty.
|
This control line should be omitted altogether if the SUBJ field is
|
||||||
This control line should by made optional for security reasons. Echo
|
empty.
|
||||||
manager passwords are too easily revealed with it.
|
This control line should by made optional for security reasons. Echo
|
||||||
|
manager passwords are too easily revealed with it.
|
||||||
|
|
||||||
FWDAREA
|
|
||||||
-------
|
FWDAREA
|
||||||
|
-------
|
||||||
This control line contains the name of the echomail area where the
|
|
||||||
original message was forwarded from. It should be omitted altogether
|
This control line contains the name of the echomail area where the
|
||||||
if the original message was not forwarded from an echomail area.
|
original message was forwarded from. It should be omitted altogether
|
||||||
|
if the original message was not forwarded from an echomail area.
|
||||||
FWDMSGID
|
|
||||||
--------
|
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
|
This control line contains the MSGID control line of the original
|
||||||
present in the original message.
|
message. It should be omitted altogether if a MSGID control line is not
|
||||||
|
present in the original message.
|
||||||
|
|
||||||
Usage:
|
|
||||||
|
Usage:
|
||||||
When the "forward" function of the message editor is invoked, the
|
|
||||||
editor program should generate the proposed control lines from the
|
When the "forward" function of the message editor is invoked, the
|
||||||
header of the original message. If the original message already was
|
editor program should generate the proposed control lines from the
|
||||||
a forwarded one (indicated by the presence of at least a FWDORIG
|
header of the original message. If the original message already was
|
||||||
control line), the editor should keep all FWD* control lines and should
|
a forwarded one (indicated by the presence of at least a FWDORIG
|
||||||
not add any FWD* control lines. This preserves the FWD* control lines
|
control line), the editor should keep all FWD* control lines and should
|
||||||
of the first forwarder, containing the header data of the author of
|
not add any FWD* control lines. This preserves the FWD* control lines
|
||||||
the original message.
|
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
|
The editor should not generate FWD* control lines, if the message isn't
|
||||||
control lines, if it not just readdresses the message.
|
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
|
When the "reply" function of the editor is invoked the program should
|
||||||
control lines should not be included in the reply.
|
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
|
Since it may not be immediately clear whether the user wants to reply
|
||||||
means to ignore the proposed control lines and start a "normal" reply
|
to the forwarder or to the original sender, the editor should offer a
|
||||||
instead, e.g. by two distinct functions, user preference or dialog.
|
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:
|
|
||||||
|
Pseudo code:
|
||||||
forwarding_message:
|
|
||||||
if is_forwarded_message then
|
forwarding_message:
|
||||||
don't change FWD* control lines
|
if is_forwarded_message then
|
||||||
else
|
don't change FWD* control lines
|
||||||
add FWD* control lines
|
else
|
||||||
|
add FWD* control lines
|
||||||
quoting_message:
|
|
||||||
if is_forwarded_message then
|
quoting_message:
|
||||||
if reply_to_forwarder then
|
if is_forwarded_message then
|
||||||
use header data (normal quoting)
|
if reply_to_forwarder then
|
||||||
else
|
use header data (normal quoting)
|
||||||
use FWD* control lines
|
else
|
||||||
remove FWD* control lines from reply
|
use FWD* control lines
|
||||||
else
|
remove FWD* control lines from reply
|
||||||
use header data (normal quoting)
|
else
|
||||||
|
use header data (normal quoting)
|
||||||
other_functions:
|
|
||||||
remove/ignore FWD* control lines
|
other_functions:
|
||||||
|
remove/ignore FWD* control lines
|
||||||
|
|
||||||
Example:
|
|
||||||
|
Example:
|
||||||
Message from Joe User to my boss node:
|
|
||||||
|
Message from Joe User to my boss node:
|
||||||
From: Joe User 1:234/567
|
|
||||||
To: Harry Herrmannsdoerfer 2:2490/2520
|
From: Joe User 1:234/567
|
||||||
Subj: Some questions
|
To: Harry Herrmannsdoerfer 2:2490/2520
|
||||||
@MSGID: 1:234/567 12345678
|
Subj: Some questions
|
||||||
Text: Hello Harry!
|
@MSGID: 1:234/567 12345678
|
||||||
...
|
Text: Hello Harry!
|
||||||
|
...
|
||||||
Harry forwards the message to me:
|
|
||||||
|
Harry forwards the message to me:
|
||||||
From: Harry Herrmannsdoerfer 2:2490/2520
|
|
||||||
To: Michael Hohner 2:2490/2520.17
|
From: Harry Herrmannsdoerfer 2:2490/2520
|
||||||
Subj: Joe's message
|
To: Michael Hohner 2:2490/2520.17
|
||||||
@FWDFROM Joe User
|
Subj: Joe's message
|
||||||
@FWDORIG 1:234/567
|
@FWDFROM Joe User
|
||||||
@FWDTO Harry Herrmannsdoerfer
|
@FWDORIG 1:234/567
|
||||||
@FWDDEST 2:2490/2520
|
@FWDTO Harry Herrmannsdoerfer
|
||||||
@FWDSUBJ Some questions
|
@FWDDEST 2:2490/2520
|
||||||
@FWDMSGID 1:234/567 12345678
|
@FWDSUBJ Some questions
|
||||||
Text: Hi Michael!
|
@FWDMSGID 1:234/567 12345678
|
||||||
...
|
Text: Hi Michael!
|
||||||
|
...
|
||||||
My answer using the new control lines:
|
|
||||||
|
My answer using the new control lines:
|
||||||
From: Michael Hohner 2:2490/2520.17
|
|
||||||
To: Joe User 1:234/567
|
From: Michael Hohner 2:2490/2520.17
|
||||||
Subj: Some questions
|
To: Joe User 1:234/567
|
||||||
@REPLY: 1:234/567 12345678
|
Subj: Some questions
|
||||||
Text: Hi Joe!
|
@REPLY: 1:234/567 12345678
|
||||||
|
Text: Hi Joe!
|
||||||
JU> ...
|
|
||||||
...
|
JU> ...
|
||||||
|
...
|
||||||
|
|
||||||
Compatiblity:
|
|
||||||
|
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
|
Editor programs which are not prepared for the proposed control lines
|
||||||
to the forwarder. Nothing gained and nothing lost.
|
usually just ignore them and remove them from a reply. A reply goes
|
||||||
|
to the forwarder. Nothing gained and nothing lost.
|
||||||
|
|
||||||
Implementations:
|
|
||||||
|
Implementations:
|
||||||
This proposal is implemented in the author's Fidonet editor
|
|
||||||
"FleetStreet for OS/2" (versions 1.17 and above).
|
This proposal is implemented in the author's Fidonet editor
|
||||||
|
"FleetStreet for OS/2" (versions 1.17 and above).
|
||||||
|
|
||||||
Contacting the author:
|
|
||||||
|
Contacting the author:
|
||||||
The author may be contacted electronically at the following addresses:
|
|
||||||
|
The author may be contacted electronically at the following addresses:
|
||||||
Fidonet: 2:2490/2520.17
|
|
||||||
Internet: miho@osn.de
|
Fidonet: 2:2490/2520.17
|
||||||
CompuServe: 100425,1754
|
Internet: miho@osn.de
|
||||||
|
CompuServe: 100425,1754
|
||||||
Suggestions, comments and corrections are always welcome.
|
|
||||||
|
Suggestions, comments and corrections are always welcome.
|
||||||
</PRE>
|
|
||||||
|
</PRE>
|
||||||
<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>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,156 +1,157 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>Reduced seen-by lines.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>Reduced seen-by lines.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
| Document: FSC-0093
|
<PRE>
|
||||||
| Version: 001
|
| Document: FSC-0093
|
||||||
| Date: 13 September, 1996
|
| Version: 001
|
||||||
| Title: Reduced seen-by lines
|
| Date: 13 September, 1996
|
||||||
| Author: Frank Ellermann, 2:240/5815.1
|
| Title: Reduced seen-by lines
|
||||||
|
| Author: Frank Ellermann, 2:240/5815.1
|
||||||
|
|
||||||
Reduced seen-by lines
|
|
||||||
Frank Ellermann, 2:240/5815.1
|
Reduced seen-by lines
|
||||||
|
Frank Ellermann, 2:240/5815.1
|
||||||
|
|
||||||
Abstract
|
|
||||||
--------
|
Abstract
|
||||||
A way to save great amounts (estimated 10 %) of echo mail traffic by
|
--------
|
||||||
reducing "seen by" informations, compatible with existing echo mail
|
A way to save great amounts (estimated 10 %) of echo mail traffic by
|
||||||
tossers conforming to FTS-0004.
|
reducing "seen by" informations, compatible with existing echo mail
|
||||||
|
tossers conforming to FTS-0004.
|
||||||
|
|
||||||
Definitions
|
|
||||||
-----------
|
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
|
A thorough understanding of FTS-0004 is required, the reader should
|
||||||
legal echo mail distribution topologies, i.e. dup-rings, as well
|
be familiar with PATH and SEEN-BY lines in echo mail, illegal and
|
||||||
as with some pre-requisite knowledge of zones, 4D and 2D addresses,
|
legal echo mail distribution topologies, i.e. dup-rings, as well
|
||||||
and the "sticky" 2D notation in PATH and SEEN-BY lines.
|
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
|
PATH: path lines as specified in FTS-0004
|
||||||
TSB: tiny seen-by informations as mentioned in FTS-0004, see below
|
FSB: full seen-by informations as specified in FTS-0004
|
||||||
RSB: reduced seen-by informations specified below
|
TSB: tiny seen-by informations as mentioned in FTS-0004, see below
|
||||||
dupe: multiple arrival of the same echo mail (e.g. different paths)
|
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
|
|
||||||
---------------------------------------------
|
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
|
In all examples a) to d) echo mail entered at system 1 is sent to
|
||||||
system 3 (2) already got this mail, topology a) is perfectly legal.
|
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 |
|
a) 1 - 3 b) 1 - 3 c) 1 - 3 d) 1 - 2
|
||||||
2 2 - 4 2 - 4 2 - 4
|
| / | | | / | | 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
|
In the exanmples b) and c) both systems 2 and 3 forward all mails
|
||||||
are therefore illegal following FTS-0004.
|
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
|
The examples a) and d) show fully connected polygons with three or
|
||||||
systems 2, 3, and 4 with FSB 1 2 3 4. The topologies a) and d) are
|
four nodes. In example d) a mail entered at system 1 is sent to
|
||||||
perfectly legal, there are no dupes caused by distribution.
|
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
|
In example b) each mail entered at system 1 reaching system 4 via
|
||||||
such mails to 3. Using TSB at system 2 the same mails would carry
|
system 2 carries FSB 1 2 3 4, therefore system 4 will not forward
|
||||||
TSB 2 4, therefore system 4 would forward them to 3 as dupes.
|
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),
|
Note that illegal topologies as in example b) and c) cause dupes
|
||||||
as it allows for loop mails on the dup-ring 1 - 2 - 3 - 4 - ...
|
with either FSB or TSB. The real problem with TSB is example b),
|
||||||
and vice versa, if no additional checks for dupes are employed.
|
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
|
With RSB (specified below) systems contained in the PATH are not
|
||||||
mail much like FSB.
|
stripped from the seen-by informations, therefore RSB avoid loop
|
||||||
|
mail much like FSB.
|
||||||
|
|
||||||
FSB algorithm
|
|
||||||
-------------
|
FSB algorithm
|
||||||
1) add own system to the PATH.
|
-------------
|
||||||
2) all area links not contained in the FSB qualify as recipients.
|
1) add own system to the PATH.
|
||||||
3) add own address(es) to the FSB set if not already contained.
|
2) all area links not contained in the FSB qualify as recipients.
|
||||||
4) add recipients to FSB, sort FSB, forward mail to 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
|
|
||||||
-------------
|
TSB algorithm
|
||||||
1) add own system to the PATH.
|
-------------
|
||||||
2) all area links not contained in the TSB qualify as recipients.
|
1) add own system to the PATH.
|
||||||
3) strip old TSB and start new TSB with own address(es).
|
2) all area links not contained in the TSB qualify as recipients.
|
||||||
4) add recipients to TSB, sort TSB and forward mail to 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
|
|
||||||
-------------
|
RSB algorithm
|
||||||
1) add own system to the PATH.
|
-------------
|
||||||
2) all area links not contained in the RSB qualify as recipients.
|
1) add own system to the PATH.
|
||||||
3) strip RSB addresses not matching an address in the PATH, then
|
2) all area links not contained in the RSB qualify as recipients.
|
||||||
add own address(es) to the RSB set if not already contained.
|
3) strip RSB addresses not matching an address in the PATH, then
|
||||||
4) add recipients to RSB, sort RSB and forward mail to recipients.
|
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
|
|
||||||
-------------------
|
PATH considerations
|
||||||
There are 2 problems with the PATH kludge as specified in FTS-0004:
|
-------------------
|
||||||
|
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
|
First like in the FSB the addresses in the PATH are 2D, and having
|
||||||
gates are required to use the TSB algorithm. Unfortunately the PATH
|
the same 2D address in different zones is possible. Therefore zone
|
||||||
is forwarded without regarding zone gating, therefore detection of
|
gates are required to use the TSB algorithm. Unfortunately the PATH
|
||||||
loop mail based solely on the PATH could be erroneous.
|
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
|
Further FTS-0004 (written 1989) expects future echo mail tossers to
|
||||||
implementations. Strictly spoken the PATH is still only an option.
|
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
|
In some areas of FidoNet (e.g. in zone 2) at least all non-terminal
|
||||||
problem will probably not show up in praxis. Of course any tosser
|
nodes are required to fully support the PATH line, therefore this
|
||||||
implementing the RSB feature is required to fully support the PATH.
|
problem will probably not show up in praxis. Of course any tosser
|
||||||
|
implementing the RSB feature is required to fully support the PATH.
|
||||||
|
|
||||||
Summary
|
|
||||||
-------
|
Summary
|
||||||
To show the benfits of RSB compared with FSB assume the following:
|
-------
|
||||||
|
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
|
An echo mail travels from node to echo hub, host, major star, echo
|
||||||
has 10 links, i.e. FSB at the recipient contain 51 addresses, about
|
host, hub, and finally arrives at a recipient. Each routing system
|
||||||
400 characters, but RSB only 15 addresses in about 150 characters.
|
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
|
Therefore in an echo mail with 2500 characters about 10 % of its
|
||||||
is applicable on world wide FidoNet echo mail traffic, RSB can save
|
size can be reduced using RSB in favour of FSB. If this estimation
|
||||||
us an immense amount of costs.
|
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,
|
This document can be adopted by the FTSC as FTS, in this case it
|
||||||
that all non-terminal nodes are required to support PATH lines as
|
has to be regarded as an addition to FTS-0004 with the extension,
|
||||||
specified in FTS-0004.
|
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
|
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>
|
- eof -
|
||||||
|
</PRE>
|
||||||
<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>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,210 +1,211 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>Timezone information in FTN messages.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>Timezone information in FTN messages.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
**********************************************************************
|
<PRE>
|
||||||
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
**********************************************************************
|
||||||
**********************************************************************
|
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
||||||
|
**********************************************************************
|
||||||
Publication: FSP-1001
|
|
||||||
Revision: 2
|
Publication: FSP-1001
|
||||||
Title: Timezone information in FTN messages
|
Revision: 2
|
||||||
Author: Odinn Sorensen, 2:236/77
|
Title: Timezone information in FTN messages
|
||||||
Revision Date: 27 September 1997
|
Author: Odinn Sorensen, 2:236/77
|
||||||
Expiry Date: 13 September 1999
|
Revision Date: 27 September 1997
|
||||||
----------------------------------------------------------------------
|
Expiry Date: 13 September 1999
|
||||||
Contents:
|
----------------------------------------------------------------------
|
||||||
1. Scope
|
Contents:
|
||||||
2. Current practice
|
1. Scope
|
||||||
3. Kludge specification
|
2. Current practice
|
||||||
4. Timezone table
|
3. Kludge specification
|
||||||
5. Examples
|
4. Timezone table
|
||||||
----------------------------------------------------------------------
|
5. Examples
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
|
||||||
Status of this document
|
|
||||||
-----------------------
|
Status of this document
|
||||||
|
-----------------------
|
||||||
This document is a Fidonet Standards Proposal (FSP).
|
|
||||||
|
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
|
This document specifies an optional Fidonet standard protocol for
|
||||||
improvements.
|
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 document is released to the public domain, and may be used,
|
||||||
|
copied or modified for any purpose whatever.
|
||||||
|
|
||||||
Abstract
|
|
||||||
--------
|
Abstract
|
||||||
|
--------
|
||||||
Current practice for Fidonet Technology Network (FTN) messages is to
|
|
||||||
store dates in local time. Timezone information (if known) is
|
Current practice for Fidonet Technology Network (FTN) messages is to
|
||||||
usually lost. This document specifies a standard for storage of
|
store dates in local time. Timezone information (if known) is
|
||||||
timezone information in FTN messages, in the form of a kludge named
|
usually lost. This document specifies a standard for storage of
|
||||||
TZUTC.
|
timezone information in FTN messages, in the form of a kludge named
|
||||||
|
TZUTC.
|
||||||
|
|
||||||
1. Scope
|
|
||||||
--------
|
1. Scope
|
||||||
|
--------
|
||||||
This standard is specified for FTN messages in any form where
|
|
||||||
timezone information is not integrated in the message storage or
|
This standard is specified for FTN messages in any form where
|
||||||
transport format. Specifically any form where the information would
|
timezone information is not integrated in the message storage or
|
||||||
be lost if not stored in a kludge, such as in FTS-1 stored messages
|
transport format. Specifically any form where the information would
|
||||||
or packets.
|
be lost if not stored in a kludge, such as in FTS-1 stored messages
|
||||||
|
or packets.
|
||||||
|
|
||||||
2. Current practice
|
|
||||||
-------------------
|
2. Current practice
|
||||||
|
-------------------
|
||||||
Some kludges already exist to specify the timezone of messages,
|
|
||||||
notably "TZUTC" and "TZUTCINFO". Other kludges may exist.
|
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.
|
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
|
From observations of these kludges in actual messages, TZUTC and
|
||||||
named after the JAM msgbase subfield of the same name.
|
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.
|
This document adopts and documents the TZUTC kludge because it is
|
||||||
|
the shortest of them.
|
||||||
|
|
||||||
3. Kludge specification
|
|
||||||
-----------------------
|
3. Kludge specification
|
||||||
|
-----------------------
|
||||||
Messages which conform to this specification must add the kludge:
|
|
||||||
|
Messages which conform to this specification must add the kludge:
|
||||||
^aTZUTC: <current offset from UTC>
|
|
||||||
|
^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
|
The offset has the format <[-]hhmm>, where hhmm is the number of
|
||||||
is WEST of UTC (Greenwich), then the offset is NEGATIVE. See the
|
hours and minutes that local time is offset from UTC. If local time
|
||||||
table below for typical offsets.
|
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
|
Note that the hh in a timezone offset is not limited to a maximum of
|
||||||
along the boundary between zone -1200 and +1200. The minutes part is
|
12. This is because the International Date Line does not run exactly
|
||||||
00 for most timezones.
|
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.
|
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
|
Implementations must NOT put a plus ('+', ASCII 43, 2Bh) in front of
|
||||||
be prepared to find (and ignore) a plus if it exists.
|
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.
|
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
|
When this kludge is present in a message, the "date written" field
|
||||||
given timezone. Note that this specification does not specify the
|
in the stored message is guaranteed to be in local time for the
|
||||||
timezone for any other date fields. Other date fields (such as "date
|
given timezone. Note that this specification does not specify the
|
||||||
received, arrived, processed, etc.") are usually in local time for
|
timezone for any other date fields. Other date fields (such as "date
|
||||||
the system on which the messages are stored.
|
received, arrived, processed, etc.") are usually in local time for
|
||||||
|
the system on which the messages are stored.
|
||||||
|
|
||||||
4. Timezone table
|
|
||||||
-----------------
|
4. Timezone table
|
||||||
|
-----------------
|
||||||
This table gives examples of typical timezones.
|
|
||||||
|
This table gives examples of typical timezones.
|
||||||
-1000 Alaska-Hawaii Standard Time
|
|
||||||
-0900 Hawaii Daylight Time
|
-1000 Alaska-Hawaii Standard Time
|
||||||
-0800 Pacific Standard Time
|
-0900 Hawaii Daylight Time
|
||||||
-0700 Pacific Daylight Time
|
-0800 Pacific Standard Time
|
||||||
-0700 Mountain Standard Time
|
-0700 Pacific Daylight Time
|
||||||
-0600 Mountain Daylight Time
|
-0700 Mountain Standard Time
|
||||||
-0600 Central Standard Time
|
-0600 Mountain Daylight Time
|
||||||
-0500 Central Daylight Time
|
-0600 Central Standard Time
|
||||||
-0500 Eastern Standard Time
|
-0500 Central Daylight Time
|
||||||
-0400 Eastern Daylight Time
|
-0500 Eastern Standard Time
|
||||||
-0400 Atlantic Standard Time
|
-0400 Eastern Daylight Time
|
||||||
-0330 Newfoundland Standard Time
|
-0400 Atlantic Standard Time
|
||||||
-0300 Atlantic Daylight Time
|
-0330 Newfoundland Standard Time
|
||||||
-0100 West Africa Time
|
-0300 Atlantic Daylight Time
|
||||||
0000 Greenwich Mean Time
|
-0100 West Africa Time
|
||||||
0100 Central European Time
|
0000 Greenwich Mean Time
|
||||||
0100 British Summer Time
|
0100 Central European Time
|
||||||
0200 Central European Summer Time
|
0100 British Summer Time
|
||||||
0200 Eastern European Time
|
0200 Central European Summer Time
|
||||||
0800 Australian Western Time
|
0200 Eastern European Time
|
||||||
0800 China Coast Time
|
0800 Australian Western Time
|
||||||
0900 Japan Standard Time
|
0800 China Coast Time
|
||||||
0900 Australian Western Daylight Time
|
0900 Japan Standard Time
|
||||||
0930 Australian Central Standard Time
|
0900 Australian Western Daylight Time
|
||||||
1000 Australian Eastern Standard Time
|
0930 Australian Central Standard Time
|
||||||
1030 Australian Central Daylight Time
|
1000 Australian Eastern Standard Time
|
||||||
1100 Australian Eastern Daylight Time
|
1030 Australian Central Daylight Time
|
||||||
1200 New Zealand Standard Time
|
1100 Australian Eastern Daylight Time
|
||||||
1300 New Zealand Daylight Time
|
1200 New Zealand Standard Time
|
||||||
|
1300 New Zealand Daylight Time
|
||||||
|
|
||||||
5. Examples
|
|
||||||
-----------
|
5. Examples
|
||||||
|
-----------
|
||||||
^aTZUTC: 0000
|
|
||||||
^aTZUTC: 0200
|
^aTZUTC: 0000
|
||||||
^aTZUTC: -0700
|
^aTZUTC: 0200
|
||||||
|
^aTZUTC: -0700
|
||||||
|
|
||||||
6. Redundancy
|
|
||||||
-------------
|
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,
|
If the TZUTC data duplicates a field in a storage format in such a
|
||||||
then it is recommended that the kludge is not stored in the message.
|
way that no information is lost in conversion to or from the field,
|
||||||
However, implementations are allowed to store the TZUTC even when
|
then it is recommended that the kludge is not stored in the message.
|
||||||
redundant.
|
However, implementations are allowed to store the TZUTC even when
|
||||||
|
redundant.
|
||||||
|
|
||||||
A. References
|
|
||||||
-------------
|
A. References
|
||||||
|
-------------
|
||||||
[FTS-1] "A Basic FidoNet(r) Technical Standard Revision 16", Randy
|
|
||||||
Bush. September 1995.
|
[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.
|
[JAM] "The JAM message base proposal", Joaquim Homrighausen, Andrew
|
||||||
|
Milner, Mats Birch and Mats Wallin. July 1993.
|
||||||
|
|
||||||
B. Author contact data
|
|
||||||
----------------------
|
B. Author contact data
|
||||||
|
----------------------
|
||||||
Odinn Sorensen
|
|
||||||
Fidonet: 2:236/77
|
Odinn Sorensen
|
||||||
E-mail: odinn@goldware.dk
|
Fidonet: 2:236/77
|
||||||
WWW: http://www.goldware.dk
|
E-mail: odinn@goldware.dk
|
||||||
|
WWW: http://www.goldware.dk
|
||||||
|
|
||||||
C. History
|
|
||||||
----------
|
C. History
|
||||||
|
----------
|
||||||
Rev.1, 970913: First release.
|
|
||||||
Rev.2, 970927: Updated the timezone table. Added section about
|
Rev.1, 970913: First release.
|
||||||
redundancy. Clarified what happens when local time
|
Rev.2, 970927: Updated the timezone table. Added section about
|
||||||
changes. Clarified some of what the specification
|
redundancy. Clarified what happens when local time
|
||||||
doesn't cover.
|
changes. Clarified some of what the specification
|
||||||
|
doesn't cover.
|
||||||
|
|
||||||
**********************************************************************
|
|
||||||
</PRE>
|
**********************************************************************
|
||||||
|
</PRE>
|
||||||
<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>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,140 +1,141 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>Numeric reply indication in FTN subject lines.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>Numeric reply indication in FTN subject lines.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
**********************************************************************
|
<PRE>
|
||||||
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
**********************************************************************
|
||||||
**********************************************************************
|
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
||||||
|
**********************************************************************
|
||||||
Publication: FSP-1002
|
|
||||||
Revision: 2
|
Publication: FSP-1002
|
||||||
Title: Numeric reply indication in FTN subject lines
|
Revision: 2
|
||||||
Author: Odinn Sorensen, 2:236/77
|
Title: Numeric reply indication in FTN subject lines
|
||||||
Revision Date: 19 October 1997
|
Author: Odinn Sorensen, 2:236/77
|
||||||
Expiry Date: 11 October 1999
|
Revision Date: 19 October 1997
|
||||||
----------------------------------------------------------------------
|
Expiry Date: 11 October 1999
|
||||||
Contents:
|
----------------------------------------------------------------------
|
||||||
1. Scope
|
Contents:
|
||||||
2. Format
|
1. Scope
|
||||||
3. Reply procedure
|
2. Format
|
||||||
----------------------------------------------------------------------
|
3. Reply procedure
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
|
||||||
Status of this document
|
|
||||||
-----------------------
|
Status of this document
|
||||||
|
-----------------------
|
||||||
This document is a Fidonet Standards Proposal (FSP).
|
|
||||||
|
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
|
This document specifies an optional Fidonet standard protocol for
|
||||||
improvements.
|
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 document is released to the public domain, and may be used,
|
||||||
|
copied or modified for any purpose whatever.
|
||||||
|
|
||||||
Abstract
|
|
||||||
--------
|
Abstract
|
||||||
|
--------
|
||||||
When making a reply to a message, there are currently three common
|
|
||||||
ways to handle the subject line:
|
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.
|
1. Don't change it.
|
||||||
3. Insert the string "Re^n: " in front of it, where 'n' is increased
|
2. Insert the string "Re: " in front of it.
|
||||||
by one if the original subject was already a reply.
|
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.
|
|
||||||
|
This document concerns itself with specifying the third variant.
|
||||||
|
|
||||||
1. Scope
|
|
||||||
--------
|
1. Scope
|
||||||
|
--------
|
||||||
This standard is specified for all FTN messages. Implementations
|
|
||||||
will typically be message editors and other software that creates
|
This standard is specified for all FTN messages. Implementations
|
||||||
replies to messages.
|
will typically be message editors and other software that creates
|
||||||
|
replies to messages.
|
||||||
|
|
||||||
2. Format
|
|
||||||
---------
|
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
|
The format is "Re^n: ", where n is an unsigned integer number with
|
||||||
255. Negative numbers are not allowed. Note that there must be a
|
one or more digits. The range of the number must be at least 0 to
|
||||||
space after the colon. The letters are not case sensitive, but
|
255. Negative numbers are not allowed. Note that there must be a
|
||||||
uppercase 'R' and lowercase 'e' is recommended.
|
space after the colon. The letters are not case sensitive, but
|
||||||
|
uppercase 'R' and lowercase 'e' is recommended.
|
||||||
|
|
||||||
3. Reply procedure
|
|
||||||
------------------
|
3. Reply procedure
|
||||||
|
------------------
|
||||||
When making a reply that conforms to this specification, this
|
|
||||||
procedure, or a functionally identical one, must be followed:
|
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
|
1. If the original subject does not have a leading "Re: " or
|
||||||
number here.
|
"Re^n: ", put the string "Re: " in front of it. Don't use a
|
||||||
|
number here.
|
||||||
Example: "Hello world" -> "Re: Hello world"
|
|
||||||
|
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.
|
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"
|
|
||||||
|
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.
|
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"
|
|
||||||
|
Example: "Re^4: Hello world" -> "Re^5: Hello world"
|
||||||
Notes:
|
|
||||||
|
Notes:
|
||||||
* The numbers 0 and 1 should not occur in the "Re^n: " string under
|
|
||||||
normal circumstances, but a robust implementation should just
|
* The numbers 0 and 1 should not occur in the "Re^n: " string under
|
||||||
increase the number in any case.
|
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
|
* The number should not be increased beyond the range of the number
|
||||||
roll around to zero. If it can't be increased, leave it alone.
|
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
|
* When inserting the "Re: " or "Re^n: " string in front of the
|
||||||
message storage or packet formats use fixed length subject fields.
|
subject, information from the end might be lost, because the
|
||||||
Intelligent subject-based reply linking software should be aware
|
message storage or packet formats use fixed length subject fields.
|
||||||
of this and try to link correctly anyway.
|
Intelligent subject-based reply linking software should be aware
|
||||||
|
of this and try to link correctly anyway.
|
||||||
|
|
||||||
A. Author contact data
|
|
||||||
----------------------
|
A. Author contact data
|
||||||
|
----------------------
|
||||||
Odinn Sorensen
|
|
||||||
Fidonet: 2:236/77
|
Odinn Sorensen
|
||||||
E-mail: odinn@goldware.dk
|
Fidonet: 2:236/77
|
||||||
WWW: http://www.goldware.dk
|
E-mail: odinn@goldware.dk
|
||||||
|
WWW: http://www.goldware.dk
|
||||||
|
|
||||||
B. History
|
|
||||||
----------
|
B. History
|
||||||
|
----------
|
||||||
Rev.1, 971011: First release.
|
|
||||||
Rev.2, 971019: Added note that "Re" is not case sensitive.
|
Rev.1, 971011: First release.
|
||||||
|
Rev.2, 971019: Added note that "Re" is not case sensitive.
|
||||||
|
|
||||||
**********************************************************************
|
|
||||||
</PRE>
|
**********************************************************************
|
||||||
|
</PRE>
|
||||||
<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>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,116 +1,117 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>Suggested use of Nodelist Fields.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>Suggested use of Nodelist Fields.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
**********************************************************************
|
<PRE>
|
||||||
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
**********************************************************************
|
||||||
**********************************************************************
|
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
||||||
|
**********************************************************************
|
||||||
Publication: FSP-1003
|
|
||||||
Revision: 1
|
Publication: FSP-1003
|
||||||
Title: Suggested use of Nodelist Fields
|
Revision: 1
|
||||||
Author: Lee Kindness
|
Title: Suggested use of Nodelist Fields
|
||||||
Revision Date: 15 May 1997
|
Author: Lee Kindness
|
||||||
Expiry Date: 15 May 1999
|
Revision Date: 15 May 1997
|
||||||
----------------------------------------------------------------------
|
Expiry Date: 15 May 1999
|
||||||
Contents:
|
----------------------------------------------------------------------
|
||||||
1. Field 3, Node Name
|
Contents:
|
||||||
2. Field 4, Location
|
1. Field 3, Node Name
|
||||||
3. Field 5, Sysop Name
|
2. Field 4, Location
|
||||||
----------------------------------------------------------------------
|
3. Field 5, Sysop Name
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
|
||||||
Status of this document
|
|
||||||
-----------------------
|
Status of this document
|
||||||
|
-----------------------
|
||||||
This document is a Fidonet Standards Proposal (FSP).
|
|
||||||
|
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
|
This document specifies an optional Fidonet standard protocol for
|
||||||
improvements.
|
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 document is released to the public domain, and may be used,
|
||||||
|
copied or modified for any purpose whatever.
|
||||||
|
|
||||||
Introduction
|
|
||||||
------------
|
Introduction
|
||||||
|
------------
|
||||||
This document makes recommendations on the use of various fields in
|
|
||||||
the distribution nodelist (St. Louis nodelist format", fts-0005).
|
This document makes recommendations on the use of various fields in
|
||||||
Naturally it is the choice of the *C's if they want to use them.
|
the distribution nodelist (St. Louis nodelist format", fts-0005).
|
||||||
Remember the fts-0005 requirements should still be adhered to.
|
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
|
|
||||||
---------------------
|
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!
|
The node name field should be no more than 20 characters long. For
|
||||||
and the average was 14.
|
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
|
For zone entries this field should contain a description of the
|
||||||
contain the country/state, for host entries the local area name and
|
zones area, (eg North America, Europe). For region entries it should
|
||||||
for hub entries a description of the area the hub serves.
|
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
|
|
||||||
--------------------
|
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.)
|
This field contains the location of the node. It should usually be
|
||||||
plus an identifier of the regional geopolitical administrative
|
expressed as the primary local location (town, suburb, city, etc.)
|
||||||
district (state, province, department, county, etc.). Wherever
|
plus an identifier of the regional geopolitical administrative
|
||||||
possible, standard postal abbreviations for the major regional
|
district (state, province, department, county, etc.). Wherever
|
||||||
district should be used (IL, BC, NSW, UK, etc.).
|
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
|
For zone and region entries this field should also have the julian
|
||||||
checks on the validity of the nodelist.
|
day of segment creation appended to it (eg "Somearea_(122)") to aid
|
||||||
|
checks on the validity of the nodelist.
|
||||||
|
|
||||||
3. Field 5, Sysop Name
|
|
||||||
----------------------
|
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
|
This field contains the name of the system operator. Entries such as
|
||||||
permitted in this field (as they give Fidonet a 'less respectable'
|
"postmaster" and "uucp" should not be used. Aliases should not be
|
||||||
image).
|
permitted in this field (as they give Fidonet a 'less respectable'
|
||||||
|
image).
|
||||||
|
|
||||||
A. Author contact data
|
|
||||||
----------------------
|
A. Author contact data
|
||||||
|
----------------------
|
||||||
Lee Kindness
|
|
||||||
Fidonet: n/a
|
Lee Kindness
|
||||||
E-mail: wangi@earthling.net
|
Fidonet: n/a
|
||||||
WWW: http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
|
E-mail: wangi@earthling.net
|
||||||
|
WWW: http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
|
||||||
|
|
||||||
B. History
|
|
||||||
----------
|
B. History
|
||||||
|
----------
|
||||||
Rev.1, 971101: First release as FSP, based on the Fidonews 14/20
|
|
||||||
article. Transformed into FSP document by Odinn
|
Rev.1, 971101: First release as FSP, based on the Fidonews 14/20
|
||||||
Sorensen.
|
article. Transformed into FSP document by Odinn
|
||||||
|
Sorensen.
|
||||||
|
|
||||||
**********************************************************************
|
|
||||||
</PRE>
|
**********************************************************************
|
||||||
|
</PRE>
|
||||||
<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>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,257 +1,258 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>Standard FidoNet Addressing.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>Standard FidoNet Addressing.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
**********************************************************************
|
<PRE>
|
||||||
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
**********************************************************************
|
||||||
**********************************************************************
|
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
||||||
|
**********************************************************************
|
||||||
Publication: FSP-1004
|
|
||||||
Revision: 1
|
Publication: FSP-1004
|
||||||
Title: Standard Fidonet Addressing
|
Revision: 1
|
||||||
Author: Lee Kindness
|
Title: Standard Fidonet Addressing
|
||||||
Revision Date: 15 May 1997
|
Author: Lee Kindness
|
||||||
Expiry Date: 15 May 1999
|
Revision Date: 15 May 1997
|
||||||
----------------------------------------------------------------------
|
Expiry Date: 15 May 1999
|
||||||
Contents:
|
----------------------------------------------------------------------
|
||||||
1. Standard Fidonet Addressing
|
Contents:
|
||||||
2. Internet Gateway Addressing
|
1. Standard Fidonet Addressing
|
||||||
3. Routing Address Syntax
|
2. Internet Gateway Addressing
|
||||||
----------------------------------------------------------------------
|
3. Routing Address Syntax
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
|
||||||
Status of this document
|
|
||||||
-----------------------
|
Status of this document
|
||||||
|
-----------------------
|
||||||
This document is a Fidonet Standards Proposal (FSP).
|
|
||||||
|
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
|
This document specifies an optional Fidonet standard protocol for
|
||||||
improvements.
|
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 document is released to the public domain, and may be used,
|
||||||
|
copied or modified for any purpose whatever.
|
||||||
|
|
||||||
Introduction
|
|
||||||
------------
|
Introduction
|
||||||
|
------------
|
||||||
This document describes the standard form of addressing in Fidonet
|
|
||||||
today along with the common method of addressing via internet
|
This document describes the standard form of addressing in Fidonet
|
||||||
gateways. In addition it proposes an extended addressing syntax,
|
today along with the common method of addressing via internet
|
||||||
useful for routing purposes. This is a draft for comments and
|
gateways. In addition it proposes an extended addressing syntax,
|
||||||
suggestions.
|
useful for routing purposes. This is a draft for comments and
|
||||||
|
suggestions.
|
||||||
|
|
||||||
1. Standard Fidonet Addressing
|
|
||||||
------------------------------
|
1. Standard Fidonet Addressing
|
||||||
|
------------------------------
|
||||||
Fidonet addressing uses the following format:
|
|
||||||
|
Fidonet addressing uses the following format:
|
||||||
ZZ:NN/FF.PP@DO
|
|
||||||
|
ZZ:NN/FF.PP@DO
|
||||||
where the fields refer to...
|
|
||||||
|
where the fields refer to...
|
||||||
ZZ - Zone Number: The zone the node is part of.
|
|
||||||
Min: 1 Max: 32767
|
ZZ - Zone Number: The zone the node is part of.
|
||||||
If 'ZZ:' is missing then assume 1 as the zone.
|
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
|
NN - Net Number: The network the node is a member of.
|
||||||
Must be present.
|
Min: 1 Max: 32767
|
||||||
|
Must be present.
|
||||||
FF - Node Number: The actual node number.
|
|
||||||
Min: -1 Max: 32767
|
FF - Node Number: The actual node number.
|
||||||
Must be present.
|
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.
|
PP - Point Number: If the system is a point rather than a node then
|
||||||
Min: 0 Max: 32767
|
this is their point number off the node.
|
||||||
If '.PP' is missing then assume 0 (ie not a
|
Min: 0 Max: 32767
|
||||||
point) as the point number.
|
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
|
DO - Domain: The name of the 'Fidonet Technology Network'.
|
||||||
should not include periods, thus 'fidonet.org'
|
Maximum length of 8 characters. The domain
|
||||||
is invalid (should be fidonet).
|
should not include periods, thus 'fidonet.org'
|
||||||
If '@DO' is missing then fidonet can be assumed.
|
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
|
The following are all valid examples:
|
||||||
2:34/6.78 (a '4D' address) => 2:34/6.78@fidonet
|
1:234/5.6@fidonet (a '5D' address) => 1:234/5.6@fidonet
|
||||||
4:610/34 (a '3D' address) => 4:610/34.0@fidonet
|
2:34/6.78 (a '4D' address) => 2:34/6.78@fidonet
|
||||||
123/45 (a '2D' address) => 1:123/45.0@fidonet
|
4:610/34 (a '3D' address) => 4:610/34.0@fidonet
|
||||||
955:95/2@othernet (another FTN) => 955:95/2.0@othernet
|
123/45 (a '2D' address) => 1:123/45.0@fidonet
|
||||||
2:259/-1 (node application) => 2:259/-1.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
|
The limits on each various part of the address are a result of
|
||||||
(-1 node address for node application).
|
fts-0005 (zone, net, node, point), fsc-0045 (domain) and Policy 4
|
||||||
|
(-1 node address for node application).
|
||||||
|
|
||||||
2. Internet Gateway Addressing
|
|
||||||
------------------------------
|
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
|
An internet user can send email/netmail to a fidonet user via one of
|
||||||
this document to describe the semantics of posting). The internet
|
the fidonet->internet gateway systems (it's out-with the scope of
|
||||||
user would send an email to a Fidonet user by using an email address
|
this document to describe the semantics of posting). The internet
|
||||||
of the following syntax:
|
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
|
|
||||||
|
user.name@pPP.fFF.nNN.zZZ.gateway.domain
|
||||||
where the fields refer to...
|
|
||||||
|
where the fields refer to...
|
||||||
user.name - Name: Name of the user the email is being sent
|
|
||||||
to, spaces replaced by periods.
|
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.
|
PP - Point Number: As Fidonet address (FA)
|
||||||
|
If '.pPP' is missing 0 is assumed.
|
||||||
FF - Node Number: As FA
|
|
||||||
Must be present.
|
FF - Node Number: As FA
|
||||||
|
Must be present.
|
||||||
NN - Net Number: As FA
|
|
||||||
Must be present.
|
NN - Net Number: As FA
|
||||||
|
Must be present.
|
||||||
ZZ - Zone 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'.
|
gate.way - Gateway: Internet domain of the gateway, for
|
||||||
Must be present.
|
example 'fidonet.org'.
|
||||||
|
Must be present.
|
||||||
The following are all valid examples (assuming 'fidonet.org' is an
|
|
||||||
internet gateway):
|
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
|
joe.bloggs@p6.f5.n234.z1.fidonet.org => 1:234/5.6@fidonet
|
||||||
i.be.jolly@f34.n610.z4.fidonet.org => 4:610/34.0@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':
|
|
||||||
|
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
|
|
||||||
|
louise.hat@f2.n95.z955.foo.bar.org.uk => 955:95/2.0@othernet
|
||||||
|
|
||||||
3. Routing Address Syntax
|
|
||||||
-------------------------
|
3. Routing Address Syntax
|
||||||
|
-------------------------
|
||||||
The two previous address types (Fidonet and Internet->Fidonet
|
|
||||||
gateway) are common practice, this however is a suggested standard
|
The two previous address types (Fidonet and Internet->Fidonet
|
||||||
of addressing for routing tables. The routing address has the
|
gateway) are common practice, this however is a suggested standard
|
||||||
following syntax:
|
of addressing for routing tables. The routing address has the
|
||||||
|
following syntax:
|
||||||
DD:ZZ:RR:NN:HH:FF:PP
|
|
||||||
|
DD:ZZ:RR:NN:HH:FF:PP
|
||||||
where the fields refer to:
|
|
||||||
|
where the fields refer to:
|
||||||
DD - Domain: As FA
|
|
||||||
Must be present, even if blank (ie a leading
|
DD - Domain: As FA
|
||||||
':') to ensure we always have 6 ':'s in an
|
Must be present, even if blank (ie a leading
|
||||||
address to aid pattern matching.
|
':') to ensure we always have 6 ':'s in an
|
||||||
|
address to aid pattern matching.
|
||||||
ZZ - Zone Number: As FA
|
|
||||||
Must be present.
|
ZZ - Zone Number: As FA
|
||||||
|
Must be present.
|
||||||
RR - Region Number: The region (from fts-0005 nodelist) that the
|
|
||||||
following network is in.
|
RR - Region Number: The region (from fts-0005 nodelist) that the
|
||||||
Min: 1 Max: 32767
|
following network is in.
|
||||||
Must be present.
|
Min: 1 Max: 32767
|
||||||
|
Must be present.
|
||||||
NN - Net Number: As FA
|
|
||||||
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).
|
HH - Hub: The hub (from fts-0005 nodelist) that the node
|
||||||
Min: 1 Max: 32767
|
is under, or 0 (host hub).
|
||||||
Must be present.
|
Min: 1 Max: 32767
|
||||||
|
Must be present.
|
||||||
FF - Node Number: As FA
|
|
||||||
Must be present.
|
FF - Node Number: As FA
|
||||||
|
Must be present.
|
||||||
PP - Point 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
|
':' has been chosen as the separator as it is not a POSIX regular
|
||||||
always easy use of wildcards on the address. The following points
|
expression character or globing character (where as '.' is) and thus
|
||||||
should be noted:
|
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
|
1. All addresses have 6 ':'s
|
||||||
the right
|
2. The domain is at the front, the address gets more specific to
|
||||||
3. Nodes have 0 as their point number
|
the right
|
||||||
4. A zone net has identical zone, region and net fields
|
3. Nodes have 0 as their point number
|
||||||
5. A region net has identical region and net fields
|
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:
|
|
||||||
|
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
|
fidonet:2:25:259:0:7:0 => 2:259/7.0@fidonet, region 25, hub 0
|
||||||
:955:9551:95:300:45:0 => 955:95/45.0, region 9551, hub 300
|
fidonet:1:1:1:0:23:0 => 1:1/23.0@fidonet, zone 1 net
|
||||||
fidonet:2:25:25:0:0:0 => 2:25/0.0@fidonet, R25C
|
:955:9551:95:300:45:0 => 955:95/45.0, region 9551, hub 300
|
||||||
cnet:12:34:341:100:1:7 => 12:341/1.7@cnet, region 34, hub 100
|
fidonet:2:25:25:0:0:0 => 2:25/0.0@fidonet, R25C
|
||||||
:2:25:259:300:300:0 => 2:259/300.0, region 25, hub 300
|
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:
|
|
||||||
|
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)
|
[a-z]*:[0-9]+:[0-9]+:[0-9]+:[0-9]+:[0-9]+:[0-9]+ (any address)
|
||||||
fidonet:2:25:[0-9]+:[0-9]+:[0-9]+:[0-9]+ (region 25 node)
|
[a-z]*(:[0-9]+)+ (any address)
|
||||||
fidonet:2:25(:[0-9]+)+ (region 25 node)
|
fidonet:2:25:[0-9]+:[0-9]+:[0-9]+:[0-9]+ (region 25 node)
|
||||||
fidonet:1:12:125(:[0-9]+)+ (all net 1:125 nodes)
|
fidonet:2:25(:[0-9]+)+ (region 25 node)
|
||||||
fidonet:1:12:125:200(:[0-9]+)+ (all hub 1:125/200 downlinks)
|
fidonet:1:12:125(:[0-9]+)+ (all net 1:125 nodes)
|
||||||
fidonet:1:12:125:200:2:[0-9]+ (all 1:125/2 points)
|
fidonet:1:12:125:200(:[0-9]+)+ (all hub 1:125/200 downlinks)
|
||||||
fidonet:1:12:125:[0-9]+:(25|34|56):0
|
fidonet:1:12:125:200:2:[0-9]+ (all 1:125/2 points)
|
||||||
(nodes 1:125/25.0, 1:125/34.0 and 1:125/56.0)
|
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:
|
|
||||||
|
Example 'DOS style' patterns on routing addresses:
|
||||||
*:*:*:*:*:*:* (any address)
|
|
||||||
fidonet:2:25:*:*:*:* (region 25 node)
|
*:*:*:*:*:*:* (any address)
|
||||||
fidonet:1:12:125:*:*:* (all net 1:125 nodes)
|
fidonet:2:25:*:*:*:* (region 25 node)
|
||||||
fidonet:1:12:125:200:*:* (all hub 1:125/200 downlinks)
|
fidonet:1:12:125:*:*:* (all net 1:125 nodes)
|
||||||
fidonet:1:12:125:200:2:* (all 1:125/2 points)
|
fidonet:1:12:125:200:*:* (all hub 1:125/200 downlinks)
|
||||||
fidonet:1:12:125:*:3*:0 (any net 1:125 nodes starting with 3)
|
fidonet:1:12:125:200:2:* (all 1:125/2 points)
|
||||||
fidonet:1:12:125:*:3?:0 (net 1:125 nodes 30 thru 39)
|
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
|
The standard doesn't define which standard of pattern matching to
|
||||||
be used in routing tables and configurations.
|
use, only the format of the addresses. These routing addresses would
|
||||||
|
be used in routing tables and configurations.
|
||||||
|
|
||||||
A. Author contact data
|
|
||||||
----------------------
|
A. Author contact data
|
||||||
|
----------------------
|
||||||
Lee Kindness
|
|
||||||
Fidonet: n/a
|
Lee Kindness
|
||||||
E-mail: wangi@earthling.net
|
Fidonet: n/a
|
||||||
WWW: http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
|
E-mail: wangi@earthling.net
|
||||||
|
WWW: http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
|
||||||
|
|
||||||
B. History
|
|
||||||
----------
|
B. History
|
||||||
|
----------
|
||||||
Rev.1, 971101: First release as FSP, based on the Fidonews 14/20
|
|
||||||
article. Transformed into FSP document by Odinn
|
Rev.1, 971101: First release as FSP, based on the Fidonews 14/20
|
||||||
Sorensen.
|
article. Transformed into FSP document by Odinn
|
||||||
|
Sorensen.
|
||||||
|
|
||||||
**********************************************************************
|
|
||||||
</PRE>
|
**********************************************************************
|
||||||
|
</PRE>
|
||||||
<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>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,450 +1,451 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>Zone 2 nodelist flags.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>Zone 2 nodelist flags.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
**********************************************************************
|
<PRE>
|
||||||
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
**********************************************************************
|
||||||
**********************************************************************
|
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
||||||
|
**********************************************************************
|
||||||
Publication: FSP-1005
|
|
||||||
Revision: 6
|
Publication: FSP-1005
|
||||||
Title: Zone 2 nodelist flags
|
Revision: 6
|
||||||
Author: Frank Ellermann, 2:240/5815.1
|
Title: Zone 2 nodelist flags
|
||||||
Revision Date: 27 November 1997
|
Author: Frank Ellermann, 2:240/5815.1
|
||||||
Expiry Date: 27 November 1999
|
Revision Date: 27 November 1997
|
||||||
---------------------------------------------------------------------
|
Expiry Date: 27 November 1999
|
||||||
Contents:
|
---------------------------------------------------------------------
|
||||||
1. Introduction
|
Contents:
|
||||||
2. FTS-0005 flags
|
1. Introduction
|
||||||
3. User flags
|
2. FTS-0005 flags
|
||||||
4. Approved zone 2 user flags
|
3. User flags
|
||||||
5. Flag implications
|
4. Approved zone 2 user flags
|
||||||
6. Invalid combinations
|
5. Flag implications
|
||||||
7. Baud rate field
|
6. Invalid combinations
|
||||||
8. Thanks to...
|
7. Baud rate field
|
||||||
---------------------------------------------------------------------
|
8. Thanks to...
|
||||||
|
---------------------------------------------------------------------
|
||||||
|
|
||||||
1. Introduction
|
|
||||||
---------------
|
1. Introduction
|
||||||
This document informs about known differences of FidoNet zone 2
|
---------------
|
||||||
nodelist flags from FTS-0005.003. The ultimate sources for these
|
This document informs about known differences of FidoNet zone 2
|
||||||
informations are the current Z2 nodelist epilogue and the setup
|
nodelist flags from FTS-0005.003. The ultimate sources for these
|
||||||
for flag corrections at Z2C, but it may be difficult to get these
|
informations are the current Z2 nodelist epilogue and the setup
|
||||||
sources for readers in other zones.
|
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
|
| All changes since version 5 are marked by a bar at the left edge.
|
||||||
V32B or V42B is not more enforced. Currently new flags needed for
|
It is (again) possible to list V32b and V42b in zone 2, upper case
|
||||||
IP-connectivity are under test in zone 2 (only internally), e.g.
|
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-
|
-> VM VModem, default port 3141, dummy country code 000-
|
||||||
-> BND BinkP, default port 24544, dummy country code 000-
|
-> IFC IFCico, default port 60179, dummy country code 000-
|
||||||
-> IP general IP connectivity, dummy country code 000-
|
-> BND BinkP, default port 24544, dummy country code 000-
|
||||||
-> TELN Telnet dummy country code 000-
|
-> IP general IP connectivity, dummy country code 000-
|
||||||
|
-> TELN Telnet dummy country code 000-
|
||||||
|
|
||||||
2. FTS-0005 flags
|
|
||||||
-----------------
|
2. FTS-0005 flags
|
||||||
The following flags are used as specified in FTS-0005.003:
|
-----------------
|
||||||
|
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)
|
CM Continuous Mail, node accepts mail 24 hours a day
|
||||||
LO Listed Only, node accepts calls only from listed
|
MO Mailer Only (no BBS)
|
||||||
node numbers in the current FidoNet nodelist
|
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)
|
-> 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 zone 2 the value 1200 in the baud rate field implies V22. Only
|
||||||
| in the zone 2 segment. Flag V22 is almost obsolete, and V21 is
|
| two nodes not supporting at least V22bis, ISDN, or IP still exist
|
||||||
| already removed in Z2. Both flags should be dropped from the next
|
| in the zone 2 segment. Flag V22 is almost obsolete, and V21 is
|
||||||
| FTS-0005 version.
|
| 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)
|
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
|
V33 cannot be used in connecting FidoNet nodes over public dial-up
|
||||||
similar argument is applicable on V29, all nodes flying this flag
|
lines and is most probably a historical error in FTS-0005. A very
|
||||||
support at least V32. Today only one node in Z2 still flies V29,
|
similar argument is applicable on V29, all nodes flying this flag
|
||||||
and V33 is already removed in Z2. Both flags should be dropped in
|
support at least V32. Today only one node in Z2 still flies V29,
|
||||||
the next FTS-0005 version.
|
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)
|
V32 ITU-T V32 9600 bps full duplex
|
||||||
| V34 ITU-T V34 28800 bps full duplex (33600 bps option)
|
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
|
FTS-0005 specifies V32b and V42b (capital V and small b), current
|
||||||
capital letters for flags. This was no problem before FSC-0062
|
nodelist practice in FidoNet shows all combinations of small and
|
||||||
introduced case-sensitive flags. The best solution is to stick to
|
capital letters for flags. This was no problem before FSC-0062
|
||||||
the current practice and treat all old flags as case-insensitive.
|
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)
|
H96 Hayes V9600
|
||||||
H14 USR Courier HST up to 14400 (implies HST)
|
HST USR Courier HST up to 9600 (implies MNP)
|
||||||
-> H16 USR Courier HST up to 16800 (implies H14 and V42b)
|
H14 USR Courier HST up to 14400 (implies HST)
|
||||||
MAX Microcom AX/96xx series (almost obsolete)
|
-> H16 USR Courier HST up to 16800 (implies H14 and V42b)
|
||||||
PEP Packet Ensemble Protocol
|
MAX Microcom AX/96xx series (almost obsolete)
|
||||||
CSP Compucom Speedmodem
|
PEP Packet Ensemble Protocol
|
||||||
-> ZYX Zyxel series 16800 bps (implies V32b and V42b)
|
CSP Compucom Speedmodem
|
||||||
-> V32T V.32 Terbo 19200 bps (implies V32b)
|
-> ZYX Zyxel series 16800 bps (implies V32b and V42b)
|
||||||
VFC V.Fast Class 28800 bps (should imply 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
|
If a flag directly or indirectly implies other flags, then these
|
||||||
be redundant. Unfortunately the rules for redundancies in zone 2
|
other flags are not shown in a nodelist entry, because this would
|
||||||
and FTS-0005 are different. Zone 2 continued to avoid redundancy
|
be redundant. Unfortunately the rules for redundancies in zone 2
|
||||||
with most "new" flags, but FTS-0005.003 specified no redundancies
|
and FTS-0005 are different. Zone 2 continued to avoid redundancy
|
||||||
for "new" flags like ZYX, H16, V32T, or VFC. "New" flags in this
|
with most "new" flags, but FTS-0005.003 specified no redundancies
|
||||||
context are flags approved by FidoNet International Coordinators
|
for "new" flags like ZYX, H16, V32T, or VFC. "New" flags in this
|
||||||
since 1989, when FTS-0005.TXT, the predecesssor of FTS-0005.003,
|
context are flags approved by FidoNet International Coordinators
|
||||||
was published.
|
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,
|
For details see the chapter "implications" below, for now only
|
||||||
and V32T implies V32b.
|
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,
|
Zone 1 and zone 2 have introduced a user flag Z19 approved by the
|
||||||
for now only note, that in zone 2 ZYX is specified as Zyxel 16k8,
|
corresponding Zone Coordinator. User flags are discussed later,
|
||||||
while FTS-0005.003 not knowing Z19 specifies ZYX as generic flag
|
for now only note, that in zone 2 ZYX is specified as Zyxel 16k8,
|
||||||
for all Zyxel protocol speeds.
|
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
|
Today only one node in FidoNet still really flies MAX, this flag
|
||||||
(7 nodes worldwide) and H96 should be marked as obsolescent.
|
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
|
| MNP Microcom Networking Protocol 2-4 error correction
|
||||||
| V42b ITU-T V.42bis BTLZ data compression over V.42 LAP-M
|
| 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
|
The next version of FTS-0005 should adopt the better V42b and
|
||||||
specifies an implication of V42 by V42b, but the exact meaning of
|
MNP definitions of the zone 3 nodelist epilogue. FTS-0005.003
|
||||||
the flag MNP is unclear. Most probably this flag was meant to
|
specifies an implication of V42 by V42b, but the exact meaning of
|
||||||
| indicate support of MNP 2-4, and in this sense V42 implies MNP.
|
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
|
| Note the difference between the flag V42b (implying V42) and the
|
||||||
| layer protocol), without this difference the flag V42b would be
|
| standard V.42bis (not necessarily based on LAP-M as data link
|
||||||
| ambiguous for combined modem and ISDN node entries.
|
| 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
|
|
||||||
|
MN No compression supported in insecure inbound
|
||||||
XA Bark and WaZOO file/update requests
|
|
||||||
XB Bark file/update requests, WaZOO file requests
|
XA Bark and WaZOO file/update requests
|
||||||
XC Bark file requests, WaZOO file/update requests
|
XB Bark file/update requests, WaZOO file requests
|
||||||
XP Bark file/update requests
|
XC Bark file requests, WaZOO file/update requests
|
||||||
XR Bark and WaZOO file requests
|
XP Bark file/update requests
|
||||||
XW WaZOO file requests
|
XR Bark and WaZOO file requests
|
||||||
XX WaZOO file/update requests
|
XW WaZOO file requests
|
||||||
|
XX WaZOO file/update requests
|
||||||
These flags are equivalent in FTS-0005 and in the zone 2 segment.
|
|
||||||
|
These flags are equivalent in FTS-0005 and in the zone 2 segment.
|
||||||
Gx..x Gateway to domain 'x..x'
|
|
||||||
|
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
|
Valid values for this flag are assigned by the Fido International
|
||||||
only GUUCP gateways are flagged.
|
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
|
#01 Zone 5 mail hour (01:00 - 02:00 UTC) w/ Bell 212A
|
||||||
-> #08 Zone 4 mail hour (08:00 - 09:00 UTC) w/ Bell 212A
|
#02 Zone 2 mail hour (02:30 - 03:30 UTC) w/ Bell 212A
|
||||||
#09 Zone 1 mail hour (09:00 - 10:00 UTC) w/ Bell 212A
|
-> #08 Zone 4 mail hour (08:00 - 09:00 UTC) w/ Bell 212A
|
||||||
#18 Zone 3 mail hour (18:00 - 19:00 UTC) w/ Bell 212A
|
#09 Zone 1 mail hour (09:00 - 10:00 UTC) w/ Bell 212A
|
||||||
#20 Zone 6 mail hour (20:00 - 21: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
|
The variants !01, !02, !08, !09, !18, and !20 indicate missing
|
||||||
redundant.
|
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
|
Today less than four 1200 modems (V22 or Bell 212A) are listed.
|
||||||
with V21 and V22 flags.
|
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
|
Further most non-CM systems flagging #mn or !mn today probably
|
||||||
hours. As soon as FSC-0062 flags have been approved by the IC
|
want to show additional online times instead of additional mail
|
||||||
or adopted as FTS by the FTSC, the following version of FTS-0005
|
hours. As soon as FSC-0062 flags have been approved by the IC
|
||||||
should mark #mn as obsolescent and recommend the more flexible
|
or adopted as FTS by the FTSC, the following version of FTS-0005
|
||||||
FSC-0062 flags (see below).
|
should mark #mn as obsolescent and recommend the more flexible
|
||||||
|
FSC-0062 flags (see below).
|
||||||
|
|
||||||
3. User flags
|
|
||||||
-------------
|
3. User flags
|
||||||
An example for one of several problems in zone 2 with user flags:
|
-------------
|
||||||
|
An example for one of several problems in zone 2 with user flags:
|
||||||
...,U,Z19,V110H,V120L,V120H,X75,ENC,NEC
|
|
||||||
|
...,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
|
These flags indicate a modern Zyxel ISDN-modem and two additional
|
||||||
34 characters, but at most 32 characters are allowed in FTS-0005.
|
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
|
|
||||||
|
...,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
|
During the period for the replacement of old by new ISDN flags
|
||||||
maximal compatibility, and no problems with nodelist compilers
|
(several months !) many nodes listed both old and new flags for
|
||||||
or mailers caused by too long user flags strings were reported.
|
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
|
Therefore the length limit in FTS-0005 is probably unnecessary
|
||||||
name are unlimited, so why only restrict the user flags string ?
|
and at least inconsequent: Other nodelist fields like the system
|
||||||
To help developpers an upper limit of e.g. 255 characters for a
|
name are unlimited, so why only restrict the user flags string ?
|
||||||
nodelist line and 63 characters for fields 3 to 6 would be more
|
To help developpers an upper limit of e.g. 255 characters for a
|
||||||
useful.
|
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:
|
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
|
Nodelist compilers could parse ...,UISDN,USR in user flags ISDN
|
||||||
combination ...,USR,UISDN would then be parsed in SR and UISDN.
|
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
|
Other side effects of the FTS-0005 specification are additional
|
||||||
by a comma, only the first user flag can be an exception to this
|
difficulties in finding flags. Almost all flags are separated
|
||||||
simple rule. If the order of user flags has no meaning, then...
|
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
|
...,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
|
... are equivalent. A "simple" solution of this problem could be
|
||||||
V120H. Similar problems show up, if user flags are counted, etc.
|
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
|
Obviously a nodelist compiler looking for user flags has always
|
||||||
this idea was simply extended to the first user flag:
|
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
|
All flags are separated by commas. Flags not yet approved by the
|
||||||
experimentally or locally) are separated by a new pseudo flag U.
|
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
|
|
||||||
|
-> 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
|
All flags following this pseudo flag U are user flags, all flags
|
||||||
approved by the International Coordinator.
|
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
|
Because this definition should be compatible with any reasonable
|
||||||
handling of user flags significantly, a future FTS-0005 version
|
software implementation based on FTS-0005.003, and simplifies the
|
||||||
will hopefully adopt it.
|
handling of user flags significantly, a future FTS-0005 version
|
||||||
|
will hopefully adopt it.
|
||||||
|
|
||||||
4. Approved zone 2 user flags
|
|
||||||
-----------------------------
|
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:
|
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)
|
-> V110L ITU-T V.110 19k2 async 'Low' (former ISDNA)
|
||||||
-> V120L ITU-T V.120 56k6 async, N1 = 259, W = 7, modulo 8
|
-> V110H ITU-T V.110 38k4 async 'High' (former ISDNB)
|
||||||
-> V120H ITU-T V.120 64k async, N1 = 259, W = 7, modulo 8
|
-> V120L ITU-T V.120 56k6 async, N1 = 259, W = 7, modulo 8
|
||||||
-> X75 ITU-T X.75 SLP (single link procedure),
|
-> V120H ITU-T V.120 64k async, N1 = 259, W = 7, modulo 8
|
||||||
64kbit/s B channel; layer 2 max. framesize N1 = 2048,
|
-> X75 ITU-T X.75 SLP (single link procedure),
|
||||||
window size W = 2, frame numbering modulo 8;
|
64kbit/s B channel; layer 2 max. framesize N1 = 2048,
|
||||||
layer 3 transparent (no packet layer)
|
window size W = 2, frame numbering modulo 8;
|
||||||
-> ISDN Other configuration, used only if none of above fits
|
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.
|
|
||||||
|
These ISDN flags follow the specification in FSC-0091.
|
||||||
-> Tyz Online time flags as specified in FSC-0062
|
|
||||||
|
-> 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
|
The flag Tyz is used by non-CM nodes online not only during ZMH,
|
||||||
end of the online period as defined below (times in UTC):
|
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,
|
A 0:00, a 0:30, B 1:00, b 1:30, C 2:00, c 2:30,
|
||||||
G 6:00, g 6:30, H 7:00, h 7:30, I 8:00, i 8:30,
|
D 3:00, d 3:30, E 4:00, e 4:30, F 5:00, f 5:30,
|
||||||
J 9:00, j 9:30, K 10:00, k 10:30, L 11:00, l 11:30,
|
G 6:00, g 6:30, H 7:00, h 7:30, I 8:00, i 8:30,
|
||||||
M 12:00, m 12:30, N 13:00, n 13:30, O 14:00, o 14:30,
|
J 9:00, j 9:30, K 10:00, k 10:30, L 11:00, l 11:30,
|
||||||
P 15:00, p 15:30, Q 16:00, q 16:30, R 17:00, r 17:30,
|
M 12:00, m 12:30, N 13:00, n 13:30, O 14:00, o 14:30,
|
||||||
S 18:00, s 18:30, T 19:00, t 19:30, U 20:00, u 20:30,
|
P 15:00, p 15:30, Q 16:00, q 16:30, R 17:00, r 17:30,
|
||||||
V 21:00, v 21:30, W 20:00, w 20:30, X 23:00, x 23: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.
|
|
||||||
|
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)
|
-> Z19 Zyxel series 19200 bps (implies ZYX)
|
||||||
-> X2S x2 server w/ 64000 bps (should imply V34 and V42b)
|
-> 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
|
-> 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)
|
-> NC Network Coordinator (only if the NC is not the host)
|
||||||
-> REC Region Echomail Coordinator (at most one per region)
|
-> 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
|
Redundant AKAs used to indicate echomail coordination in zone 2
|
||||||
a given sysop.
|
are no longer permitted. One *EC flag is valid for all AKAs of
|
||||||
|
a given sysop.
|
||||||
|
|
||||||
5. Flag implications
|
|
||||||
--------------------
|
5. Flag implications
|
||||||
Flag implications directly or indirectly specified in FTS-0005:
|
--------------------
|
||||||
|
Flag implications directly or indirectly specified in FTS-0005:
|
||||||
HST => MNP
|
|
||||||
H14 => MNP HST
|
HST => MNP
|
||||||
H16 => MNP HST H14
|
H14 => MNP HST
|
||||||
V42b => V42 (MNP ?)
|
H16 => MNP HST H14
|
||||||
V32b => V32
|
V42b => V42 (MNP ?)
|
||||||
|
V32b => V32
|
||||||
Flag implications specified in the zone 2 nodelist epilogue:
|
|
||||||
|
Flag implications specified in the zone 2 nodelist epilogue:
|
||||||
HST => MNP
|
|
||||||
H14 => HST MNP
|
HST => MNP
|
||||||
-> H16 => V42 MNP V42b H14 HST
|
H14 => HST MNP
|
||||||
-> V42b => V42 MNP
|
-> H16 => V42 MNP V42b H14 HST
|
||||||
-> ZYX => V42 MNP V42b V32 V32b
|
-> V42b => V42 MNP
|
||||||
-> Z19 => V42 MNP V42b V32 V32b ZYX
|
-> ZYX => V42 MNP V42b V32 V32b
|
||||||
V32b => V32
|
-> Z19 => V42 MNP V42b V32 V32b ZYX
|
||||||
-> V32T => V32 V32b
|
V32b => V32
|
||||||
|
-> V32T => V32 V32b
|
||||||
-> V110L => ISDN
|
|
||||||
-> V110H => ISDN
|
-> V110L => ISDN
|
||||||
-> V120L => ISDN
|
-> V110H => ISDN
|
||||||
-> V120H => ISDN
|
-> V120L => ISDN
|
||||||
-> X75 => 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:
|
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
|
VFC => V32 V32b MNP V42 V42b
|
||||||
X2S => V34 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
|
Flag implications (i.e. not listing redundant flags) have several
|
||||||
lines. Old flags like HST, MNP, V42, or V32 vanish automatically,
|
advantages: Some old nodelist tools are unable to handle too long
|
||||||
if they are implied by H16, V42b, V32b, or better. Redundancies
|
lines. Old flags like HST, MNP, V42, or V32 vanish automatically,
|
||||||
defined globally for the whole nodelist help to avoid flag errors.
|
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
|
|
||||||
-----------------------
|
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
|
All file request flags exclude each other (at most 1 is possible):
|
||||||
implications a good approximation based on FTS-0005 definitions is
|
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,
|
| XA => XW XR XP XB XC XX,
|
||||||
| XC => XW XR XX,
|
| XB => XW XR XP,
|
||||||
| XR => XW,
|
| XC => XW XR XX,
|
||||||
| XX => XW.
|
| 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.
|
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:
|
Some modem protocols are "proprietary" in a sense, that all today
|
||||||
MAX, CSP, H96, PEP, HST, H14, H16, ZYX, and Z19.
|
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
|
A few "old" modem protocol flags are known to be invalid if used
|
||||||
all "new" flags and vice versa:
|
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.
|
"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
|
For Z2 add ZYX as "old" and Z19 as "new". A simple REXX script to
|
||||||
the site of the author. While erroneously listing redundant flags
|
test some known inconsistencies is available as NLSCHECK.REX at
|
||||||
causes no harm, other errors like combining V34 with HST or Z19
|
the site of the author. While erroneously listing redundant flags
|
||||||
with H16 indicate serious problems, which can result in connection
|
causes no harm, other errors like combining V34 with HST or Z19
|
||||||
failures or other damage.
|
with H16 indicate serious problems, which can result in connection
|
||||||
|
failures or other damage.
|
||||||
|
|
||||||
7. Baud rate field
|
|
||||||
------------------
|
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
|
The baud rate field 7 in the nodelist as specified in FTS-0005 is
|
||||||
nodes almost all nodelist entries show either 9600 for all modem
|
nearly useless today: Except from a few remaining 1200 and 2400
|
||||||
protocols better than V22bis or 300 for ISDN (or IP) only nodes.
|
nodes almost all nodelist entries show either 9600 for all modem
|
||||||
No more V21 or Bell 103 modems are listed for more than 2 years.
|
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
|
The baud rate values 19200 and 38400 specified in FTS-0005.003
|
||||||
nodelist compiler can do today, is treat 300 as indicator for
|
have not been used in the FidoNet nodelist. So all a reasonable
|
||||||
ISDN or IP only, and treat unknown or missing values in field 7
|
nodelist compiler can do today, is treat 300 as indicator for
|
||||||
like 9600.
|
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
|
A new meaning for field 7 as speed field could be really useful.
|
||||||
as speed values, then their combination with ZYX is all we need
|
An example is ZYX, if we would have 16800, 19200, 28800, and 33600
|
||||||
technically, Z19 would be unnecessary. Another example is HST,
|
as speed values, then their combination with ZYX is all we need
|
||||||
flags H14 and H16 are unnecessary, if HST is combined with 9600,
|
technically, Z19 would be unnecessary. Another example is HST,
|
||||||
14400, 16800, 28800, or better. Variants of PEP could be shown in
|
flags H14 and H16 are unnecessary, if HST is combined with 9600,
|
||||||
the speed field without new flags. "Enhanced V32.terbo" could be
|
14400, 16800, 28800, or better. Variants of PEP could be shown in
|
||||||
shown by 21600.
|
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
|
Most important: V34 may have the famous bug not allowing connects
|
||||||
"V34+" is indicated by speed 33600 or better, then an appropriate
|
from new "V34+", unless the caller disabled symbol rate 3429. If
|
||||||
setup for all kinds of V34 connects is possible.
|
"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:
|
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)
|
300 reserved for ISDN or IP only (for historical reasons)
|
||||||
2400 implies V22bis, qualifies as least common denominator
|
1200 obsolete (either V.22 in Z2 / Z3, or Bell 212A in Z1)
|
||||||
9600 default, used with PEP, V32, HST, H96, (CSP), (MAX)
|
2400 implies V22bis, qualifies as least common denominator
|
||||||
12000 rare variant of V32
|
9600 default, used with PEP, V32, HST, H96, (CSP), (MAX)
|
||||||
14400 used with V32b or HST (obsoleting H14)
|
12000 rare variant of V32
|
||||||
16800 used with ZYX or HST (obsoleting H16)
|
14400 used with V32b or HST (obsoleting H14)
|
||||||
19200 used with V32T or ZYX (obsoleting Z19)
|
16800 used with ZYX or HST (obsoleting H16)
|
||||||
21600 rare variant of V32T (no "H21" needed)
|
19200 used with V32T or ZYX (obsoleting Z19)
|
||||||
28800 used with VFC or V34
|
21600 rare variant of V32T (no "H21" needed)
|
||||||
33600 used with V34 (no V34+ or V34b needed)
|
28800 used with VFC or V34
|
||||||
| 56000 used with X2C, X2S, or V.PCM
|
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
|
Allowing more than 12 speed values or allowing speed values above
|
||||||
next step in FidoNet could be, to add 12000, 14400, 16800, 19200,
|
64000 could break existing software (MakeNL, V7). Therefore the
|
||||||
21600, 28800, 33600, and 56000, where 19200 is already specified
|
next step in FidoNet could be, to add 12000, 14400, 16800, 19200,
|
||||||
in FTS-5 since 1989.
|
21600, 28800, 33600, and 56000, where 19200 is already specified
|
||||||
|
in FTS-5 since 1989.
|
||||||
|
|
||||||
8. Thanks to...
|
|
||||||
---------------
|
8. Thanks to...
|
||||||
Ben Baker St. Louis nodelist format
|
---------------
|
||||||
Rick Moore FTS-0005.TXT
|
Ben Baker St. Louis nodelist format
|
||||||
David Nugent FTS-0005.003 and NLTOOLS
|
Rick Moore FTS-0005.TXT
|
||||||
Jonny Bergdahl ERRFLAGS 2.6
|
David Nugent FTS-0005.003 and NLTOOLS
|
||||||
Ward Dossche Zone 2 nodelist epilogue
|
Jonny Bergdahl ERRFLAGS 2.6
|
||||||
David J. Thomas FSC-0062.003 (FRL-0062)
|
Ward Dossche Zone 2 nodelist epilogue
|
||||||
Jan Ceuleers FSC-0075.001 (FRL-0075)
|
David J. Thomas FSC-0062.003 (FRL-0062)
|
||||||
Arjen Lentz FSC-0091.001 (FRL-0091)
|
Jan Ceuleers FSC-0075.001 (FRL-0075)
|
||||||
Leonard Erickson CHECKNL 2.14 and many discussions in NET_DEV
|
Arjen Lentz FSC-0091.001 (FRL-0091)
|
||||||
Jim Barchuk LNDL 2.7
|
Leonard Erickson CHECKNL 2.14 and many discussions in NET_DEV
|
||||||
Marius Ellen FASTV7 2.04
|
Jim Barchuk LNDL 2.7
|
||||||
| Jan Vermeulen, Ian Smith, Gisbert Rudolph, Carlos Fernandez Sanz,
|
Marius Ellen FASTV7 2.04
|
||||||
| Tom Schlangen, Craig Ford, Pedro Lima, and many others...
|
| Jan Vermeulen, Ian Smith, Gisbert Rudolph, Carlos Fernandez Sanz,
|
||||||
|
| Tom Schlangen, Craig Ford, Pedro Lima, and many others...
|
||||||
|
|
||||||
**********************************************************************
|
|
||||||
</PRE>
|
**********************************************************************
|
||||||
|
</PRE>
|
||||||
<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>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,159 +1,160 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>Kludge for specifying addition e-mail reply addresses.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>Kludge for specifying addition e-mail reply addresses.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
**********************************************************************
|
<PRE>
|
||||||
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
**********************************************************************
|
||||||
**********************************************************************
|
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
||||||
|
**********************************************************************
|
||||||
Publication: FSP-1006
|
|
||||||
Revision: 1
|
Publication: FSP-1006
|
||||||
Title: Kludge for specifying addition e-mail reply addresses
|
Revision: 1
|
||||||
Author: Ramon van der Winkel, 1:320/42.46
|
Title: Kludge for specifying addition e-mail reply addresses
|
||||||
ramon@wsd.wline.se
|
Author: Ramon van der Winkel, 1:320/42.46
|
||||||
Revision Date: 12 December 1997
|
ramon@wsd.wline.se
|
||||||
Expiry Date: 12 December 1999
|
Revision Date: 12 December 1997
|
||||||
----------------------------------------------------------------------
|
Expiry Date: 12 December 1999
|
||||||
Contents:
|
----------------------------------------------------------------------
|
||||||
1. Scope
|
Contents:
|
||||||
2. Background
|
1. Scope
|
||||||
3. Format
|
2. Background
|
||||||
4. Implementation notes
|
3. Format
|
||||||
5. Example
|
4. Implementation notes
|
||||||
----------------------------------------------------------------------
|
5. Example
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
|
||||||
Status of this document
|
|
||||||
-----------------------
|
Status of this document
|
||||||
|
-----------------------
|
||||||
This document is a Fidonet Standards Proposal (FSP).
|
|
||||||
|
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
|
This document specifies an optional Fidonet standard protocol for
|
||||||
improvements.
|
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 document is released to the public domain, and may be used,
|
||||||
|
copied or modified for any purpose whatever.
|
||||||
|
|
||||||
Abstract
|
|
||||||
--------
|
Abstract
|
||||||
|
--------
|
||||||
An Internet message can have several reply addresses. After gating
|
|
||||||
to FidoNet, the recipient is only presented with one of the reply
|
An Internet message can have several reply addresses. After gating
|
||||||
addresses. The others are lost. This is a suggestion for an
|
to FidoNet, the recipient is only presented with one of the reply
|
||||||
additional kludge to FSC-0035 to change that.
|
addresses. The others are lost. This is a suggestion for an
|
||||||
|
additional kludge to FSC-0035 to change that.
|
||||||
|
|
||||||
1. Scope
|
|
||||||
--------
|
1. Scope
|
||||||
|
--------
|
||||||
This standard is specified for FTN netmail messages sent by a
|
|
||||||
FidoNet-to-Internet gateway to a recipient. Message editors will
|
This standard is specified for FTN netmail messages sent by a
|
||||||
have to support this to allow the user to select the reply address
|
FidoNet-to-Internet gateway to a recipient. Message editors will
|
||||||
to use.
|
have to support this to allow the user to select the reply address
|
||||||
|
to use.
|
||||||
|
|
||||||
2. Background
|
|
||||||
-------------
|
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
|
An Internet message has three headers to indicate where to send a
|
||||||
From:. When a message is distributed by a mailing list, then one of
|
reply. These are, in order of priority, Reply-To:, Sender: and
|
||||||
the headers could contain the e-mail address of the poster and one
|
From:. When a message is distributed by a mailing list, then one of
|
||||||
of the other headers the address of the mailing list.
|
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
|
When the message is gated to FidoNet, the gateway currently selects
|
||||||
return at the gateway and sent to this one address. The other
|
of the reply addresses and creates the message so that a reply will
|
||||||
addresses are lost.
|
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
|
The FSC-0035 kludges REPLYTO and REPLYADDR allow for one return
|
||||||
by the gateway to specify an addtional reply address. The message
|
address only. This is a proposal for an additional kludge inserted
|
||||||
editor used by the recipient will present a list of all reply
|
by the gateway to specify an addtional reply address. The message
|
||||||
addresses and allows the user to select the appropriate address.
|
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.
|
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
|
|
||||||
---------
|
3. Format
|
||||||
|
---------
|
||||||
Following the REPLYTO and REPLYADDR kludges, one or more kludges
|
|
||||||
with the name REPLYALSO can be inserted, each listing one possible
|
Following the REPLYTO and REPLYADDR kludges, one or more kludges
|
||||||
reply address.
|
with the name REPLYALSO can be inserted, each listing one possible
|
||||||
|
reply address.
|
||||||
@REPLYALSO <e-mail address>
|
|
||||||
|
@REPLYALSO <e-mail address>
|
||||||
Where <e-mail address> is in the form of
|
|
||||||
|
Where <e-mail address> is in the form of
|
||||||
ramon@wsd.wline.se
|
|
||||||
or
|
ramon@wsd.wline.se
|
||||||
wsd.wline.se!ramon
|
or
|
||||||
|
wsd.wline.se!ramon
|
||||||
Each line MUST contain one address only.
|
|
||||||
|
Each line MUST contain one address only.
|
||||||
|
|
||||||
4. Implementation notes
|
|
||||||
-----------------------
|
4. Implementation notes
|
||||||
|
-----------------------
|
||||||
Gateways supporting the REPLYALSO kludge MUST put the the reply
|
|
||||||
address with the highest priority in the REPLYADDR kludge. The order
|
Gateways supporting the REPLYALSO kludge MUST put the the reply
|
||||||
of priority is Reply-To:, Sender: and From: header. The other
|
address with the highest priority in the REPLYADDR kludge. The order
|
||||||
addresses may be listed in any priority.
|
of priority is Reply-To:, Sender: and From: header. The other
|
||||||
|
addresses may be listed in any priority.
|
||||||
|
|
||||||
5. Example
|
|
||||||
----------
|
5. Example
|
||||||
|
----------
|
||||||
From: odinn@goldware.dk, 1:320/42
|
|
||||||
To: Ramon van der Winkel, 1:320/42.46
|
From: odinn@goldware.dk, 1:320/42
|
||||||
Subj: Another test
|
To: Ramon van der Winkel, 1:320/42.46
|
||||||
---------------------------------------
|
Subj: Another test
|
||||||
@INTL 1:320/42 1:320/42
|
---------------------------------------
|
||||||
@TOPT 46
|
@INTL 1:320/42 1:320/42
|
||||||
@MSGID: wgmid$<123455@goldware.dk> 45AB23CD
|
@TOPT 46
|
||||||
@REPLYTO UUCP 1:320/42
|
@MSGID: wgmid$<123455@goldware.dk> 45AB23CD
|
||||||
@REPLYADDR odinn@goldware.dk
|
@REPLYTO UUCP 1:320/42
|
||||||
@REPLYALSO newftsc-l@brazerko.com
|
@REPLYADDR odinn@goldware.dk
|
||||||
This message was distributed by the mailing list "New FTSC"
|
@REPLYALSO newftsc-l@brazerko.com
|
||||||
at brazerko.com.
|
This message was distributed by the mailing list "New FTSC"
|
||||||
|
at brazerko.com.
|
||||||
...
|
|
||||||
|
...
|
||||||
|
|
||||||
A. Author contact data
|
|
||||||
----------------------
|
A. Author contact data
|
||||||
|
----------------------
|
||||||
Ramon van der Winkel
|
|
||||||
Fidonet: 1:320/42.46
|
Ramon van der Winkel
|
||||||
E-mail: ramon@wsd.wline.se
|
Fidonet: 1:320/42.46
|
||||||
WWW: http://www2.sbbs.se/hp/ramon
|
E-mail: ramon@wsd.wline.se
|
||||||
|
WWW: http://www2.sbbs.se/hp/ramon
|
||||||
|
|
||||||
B. History
|
|
||||||
----------
|
B. History
|
||||||
|
----------
|
||||||
Rev.1, 971212: First release.
|
|
||||||
|
Rev.1, 971212: First release.
|
||||||
|
|
||||||
**********************************************************************
|
|
||||||
</PRE>
|
**********************************************************************
|
||||||
|
</PRE>
|
||||||
<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>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,162 +1,163 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>Multiple recipient address specification to gateway.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>Multiple recipient address specification to gateway.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
**********************************************************************
|
<PRE>
|
||||||
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
**********************************************************************
|
||||||
**********************************************************************
|
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
||||||
|
**********************************************************************
|
||||||
Publication: FSP-1007
|
|
||||||
Revision: 1
|
Publication: FSP-1007
|
||||||
Title: Multiple recipient address specification to gateway
|
Revision: 1
|
||||||
Author: Ramon van der Winkel, 1:320/42.46
|
Title: Multiple recipient address specification to gateway
|
||||||
ramon@wsd.wline.se
|
Author: Ramon van der Winkel, 1:320/42.46
|
||||||
Revision Date: 12 December 1997
|
ramon@wsd.wline.se
|
||||||
Expiry Date: 12 December 1999
|
Revision Date: 12 December 1997
|
||||||
----------------------------------------------------------------------
|
Expiry Date: 12 December 1999
|
||||||
Contents:
|
----------------------------------------------------------------------
|
||||||
1. Scope
|
Contents:
|
||||||
2. Background
|
1. Scope
|
||||||
3. Format
|
2. Background
|
||||||
4. Implementation notes for gateways
|
3. Format
|
||||||
5. Example
|
4. Implementation notes for gateways
|
||||||
----------------------------------------------------------------------
|
5. Example
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
|
||||||
Status of this document
|
|
||||||
-----------------------
|
Status of this document
|
||||||
|
-----------------------
|
||||||
This document is a Fidonet Standards Proposal (FSP).
|
|
||||||
|
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
|
This document specifies an optional Fidonet standard protocol for
|
||||||
improvements.
|
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 document is released to the public domain, and may be used,
|
||||||
|
copied or modified for any purpose whatever.
|
||||||
|
|
||||||
Abstract
|
|
||||||
--------
|
Abstract
|
||||||
|
--------
|
||||||
Private messages within FidoNet only have one recipient address.
|
|
||||||
Multiple copies of the same message have to be sent to a FidoNet-
|
Private messages within FidoNet only have one recipient address.
|
||||||
to-Internet gateway in order to address multiple recipients. This is
|
Multiple copies of the same message have to be sent to a FidoNet-
|
||||||
a proposal to indicate the addresses of multiple recipients in the
|
to-Internet gateway in order to address multiple recipients. This is
|
||||||
body of the message sent to the gateway.
|
a proposal to indicate the addresses of multiple recipients in the
|
||||||
|
body of the message sent to the gateway.
|
||||||
|
|
||||||
1. Scope
|
|
||||||
--------
|
1. Scope
|
||||||
|
--------
|
||||||
This standard is specified for FTN netmail messages sent to a
|
|
||||||
FidoNet-to-Internet gateway. Users are able to add this information
|
This standard is specified for FTN netmail messages sent to a
|
||||||
manually, although message editors could support this and make it
|
FidoNet-to-Internet gateway. Users are able to add this information
|
||||||
transparent to the user.
|
manually, although message editors could support this and make it
|
||||||
|
transparent to the user.
|
||||||
|
|
||||||
2. Background
|
|
||||||
-------------
|
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
|
Three types of recipient addresses can be specified on the Internet
|
||||||
primary recipient(s) of the message. "Cc" is short for Carbon Copy
|
and are reflected in this suggestion: To, Cc and Bcc. "To" are the
|
||||||
and lists the recipients that are intended to receive the message as
|
primary recipient(s) of the message. "Cc" is short for Carbon Copy
|
||||||
"informational". The last option "Bcc" is short for Blind Carbon
|
and lists the recipients that are intended to receive the message as
|
||||||
Copy. Recipients lists as Bcc recipients will not show up in the
|
"informational". The last option "Bcc" is short for Blind Carbon
|
||||||
headers of the Internet message, but get a copy anyway.
|
Copy. Recipients lists as Bcc recipients will not show up in the
|
||||||
|
headers of the Internet message, but get a copy anyway.
|
||||||
|
|
||||||
3. Format
|
|
||||||
---------
|
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
|
Immediately following the kludge lines, one or more of the following
|
||||||
these lines follow the To: line.
|
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-To: <e-mail address>[,<e-mail address>[...]]
|
||||||
GW-Bcc: <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
|
|
||||||
|
Where <e-mail address> is in the form of
|
||||||
ramon@wsd.wline.se
|
|
||||||
or
|
ramon@wsd.wline.se
|
||||||
wsd.wline.se!ramon
|
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
|
Multiple addresses can be specified on the same line, separated by a
|
||||||
regarding the length of the line. The line must be terminated by a
|
comma with optionally spaces around the comma. There is no limit
|
||||||
single carriage return.
|
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 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.
|
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
|
|
||||||
------------------------------------
|
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
|
Gateways supporting this format add the e-mail addresses mentioned
|
||||||
outbound (probably UUCP or SMTP) body text message. Rules for the
|
in any of these three headers to the envelope file and create on
|
||||||
maximum length of envelope files (if any) apply.
|
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
|
The headers section of the RFC822 message will list the e-mail
|
||||||
added!
|
addresses under the To: and Cc: headers. A Bcc: header must not be
|
||||||
|
added!
|
||||||
|
|
||||||
5. Example
|
|
||||||
----------
|
5. Example
|
||||||
|
----------
|
||||||
From: Ramon van der Winkel, 1:320/42.46
|
|
||||||
To: UUCP, 1:320/42
|
From: Ramon van der Winkel, 1:320/42.46
|
||||||
Subj: New header test
|
To: UUCP, 1:320/42
|
||||||
---------------------------------------
|
Subj: New header test
|
||||||
@INTL 1:320/42 1:320/42
|
---------------------------------------
|
||||||
@FMPT 46
|
@INTL 1:320/42 1:320/42
|
||||||
GW-To: groupElist@newftsc.org
|
@FMPT 46
|
||||||
GW-Cc: odinn@goldware.dk
|
GW-To: groupElist@newftsc.org
|
||||||
GW-Bcc: groupAadmin@newftsc.org
|
GW-Cc: odinn@goldware.dk
|
||||||
Hi!
|
GW-Bcc: groupAadmin@newftsc.org
|
||||||
|
Hi!
|
||||||
This is a test
|
|
||||||
|
This is a test
|
||||||
Ramon
|
|
||||||
|
Ramon
|
||||||
|
|
||||||
A. Author contact data
|
|
||||||
----------------------
|
A. Author contact data
|
||||||
|
----------------------
|
||||||
Ramon van der Winkel
|
|
||||||
Fidonet: 1:320/42.46
|
Ramon van der Winkel
|
||||||
E-mail: ramon@wsd.wline.se
|
Fidonet: 1:320/42.46
|
||||||
WWW: http://www2.sbbs.se/hp/ramon
|
E-mail: ramon@wsd.wline.se
|
||||||
|
WWW: http://www2.sbbs.se/hp/ramon
|
||||||
|
|
||||||
B. History
|
|
||||||
----------
|
B. History
|
||||||
|
----------
|
||||||
Rev.1, 971212: First release.
|
|
||||||
|
Rev.1, 971212: First release.
|
||||||
|
|
||||||
**********************************************************************
|
|
||||||
</PRE>
|
**********************************************************************
|
||||||
|
</PRE>
|
||||||
<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>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,275 +1,276 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>New control lines for forwarding messages.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>New control lines for forwarding messages.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
**********************************************************************
|
<PRE>
|
||||||
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
**********************************************************************
|
||||||
**********************************************************************
|
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
||||||
|
**********************************************************************
|
||||||
Publication: FSP-1008
|
|
||||||
Revision: 2
|
Publication: FSP-1008
|
||||||
Title: New control lines for forwarded messages
|
Revision: 2
|
||||||
Author: Michael Hohner, 2:2490/2520.17
|
Title: New control lines for forwarded messages
|
||||||
Revision Date: 29 December 1997
|
Author: Michael Hohner, 2:2490/2520.17
|
||||||
Expiry Date: 29 December 1999
|
Revision Date: 29 December 1997
|
||||||
----------------------------------------------------------------------
|
Expiry Date: 29 December 1999
|
||||||
Contents:
|
----------------------------------------------------------------------
|
||||||
1. Specifications
|
Contents:
|
||||||
2. Usage
|
1. Specifications
|
||||||
3. Compatiblity
|
2. Usage
|
||||||
4. Known implementations
|
3. Compatiblity
|
||||||
----------------------------------------------------------------------
|
4. Known implementations
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
|
||||||
Status of this document
|
|
||||||
-----------------------
|
Status of this document
|
||||||
|
-----------------------
|
||||||
This document is a Fidonet Standards Proposal (FSP).
|
|
||||||
|
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
|
This document specifies an optional Fidonet standard protocol for
|
||||||
improvements.
|
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 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.
|
This revision is an update to FRL-0092.001. The basic specifications
|
||||||
|
are unchanged.
|
||||||
|
|
||||||
Abstract
|
|
||||||
--------
|
Abstract
|
||||||
|
--------
|
||||||
Most fidonet message editors offer a "forward" function. Using this
|
|
||||||
function a user A ("forwarder") can sort of "redirect" a message
|
Most fidonet message editors offer a "forward" function. Using this
|
||||||
from user B ("author") to another user C ("final recipient"), maybe
|
function a user A ("forwarder") can sort of "redirect" a message
|
||||||
because the forwarder is not the correct recipient, or because the
|
from user B ("author") to another user C ("final recipient"), maybe
|
||||||
final recipient is a better person to answer the message. The name
|
because the forwarder is not the correct recipient, or because the
|
||||||
and address of the author are usually included in the forward in
|
final recipient is a better person to answer the message. The name
|
||||||
free-text format. The message text is included in non-quoted format.
|
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
|
A problem arises when the final recipient wants to reply to the
|
||||||
as the sender. So the final recipient must insert the name and
|
author of the forwarded message. The forward contains the forwarder
|
||||||
address of the author manually, using the information contained in
|
as the sender. So the final recipient must insert the name and
|
||||||
the message text. The message editor of the final recipient can't do
|
address of the author manually, using the information contained in
|
||||||
this automatically because of the free-text format. The editor will
|
the message text. The message editor of the final recipient can't do
|
||||||
also use incorrect quote initials, which is at least irritating.
|
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
|
This document introduces 7 new control lines which contain the
|
||||||
the message editor can use the original header information
|
header information of the original message. With these control lines
|
||||||
automatically.
|
the message editor can use the original header information
|
||||||
|
automatically.
|
||||||
|
|
||||||
1. Specifications
|
|
||||||
-----------------
|
1. Specifications
|
||||||
|
-----------------
|
||||||
There are 7 new control lines: FWDFROM, FWDTO, FWDORIG, FWDDEST,
|
|
||||||
FWDSUBJ, FWDAREA, FWDMSGID. As all control lines they start with an
|
There are 7 new control lines: FWDFROM, FWDTO, FWDORIG, FWDDEST,
|
||||||
ASCII 01 character (SOH) followed by the control line name followed
|
FWDSUBJ, FWDAREA, FWDMSGID. As all control lines they start with an
|
||||||
by whitespace followed by the control line's content followed by
|
ASCII 01 character (SOH) followed by the control line name followed
|
||||||
ASCII 13 (CR).
|
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.
|
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
|
|
||||||
-------
|
FWDFROM
|
||||||
|
-------
|
||||||
This control line contains the name of the original sender as found
|
|
||||||
in the FROM field of the original message. Leading and trailing
|
This control line contains the name of the original sender as found
|
||||||
whitespace should be removed. This control line should be omitted
|
in the FROM field of the original message. Leading and trailing
|
||||||
altogether if the FROM field is empty.
|
whitespace should be removed. This control line should be omitted
|
||||||
|
altogether if the FROM field is empty.
|
||||||
FWDTO
|
|
||||||
-----
|
FWDTO
|
||||||
|
-----
|
||||||
This control line contains the name of the original recipient as
|
|
||||||
found in the TO field of the original message. Leading and trailing
|
This control line contains the name of the original recipient as
|
||||||
whitespace should be removed. This control line should be omitted
|
found in the TO field of the original message. Leading and trailing
|
||||||
altogether if the TO field is empty.
|
whitespace should be removed. This control line should be omitted
|
||||||
|
altogether if the TO field is empty.
|
||||||
FWDORIG
|
|
||||||
-------
|
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
|
This control line contains the address of the original sender as
|
||||||
notation (zone:net/node.point@domain) should be used. This control
|
found in the ORIG field of the original message. The usual 5D ASCII
|
||||||
line should be omitted altogether if the address is not known.
|
notation (zone:net/node.point@domain) should be used. This control
|
||||||
|
line should be omitted altogether if the address is not known.
|
||||||
FWDDEST
|
|
||||||
-------
|
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
|
This control line contains the address of the original recipient as
|
||||||
notation (zone:net/node.point@domain) should be used. This control
|
found in the DEST field of the original message. The usual 5D ASCII
|
||||||
line should be omitted altogether if the address is not known or
|
notation (zone:net/node.point@domain) should be used. This control
|
||||||
unsure (as it is the case with forwarded echomail messages).
|
line should be omitted altogether if the address is not known or
|
||||||
|
unsure (as it is the case with forwarded echomail messages).
|
||||||
FWDSUBJ
|
|
||||||
-------
|
FWDSUBJ
|
||||||
|
-------
|
||||||
This control line contains the subject line of the original message.
|
|
||||||
This control line should be omitted altogether if the SUBJ field is
|
This control line contains the subject line of the original message.
|
||||||
empty.
|
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.
|
This control line should by made optional for security reasons. Echo
|
||||||
|
manager passwords are too easily revealed with it.
|
||||||
FWDAREA
|
|
||||||
-------
|
FWDAREA
|
||||||
|
-------
|
||||||
This control line contains the name of the echomail area where the
|
|
||||||
original message was forwarded from. It should be omitted altogether
|
This control line contains the name of the echomail area where the
|
||||||
if the original message was not forwarded from an echomail area.
|
original message was forwarded from. It should be omitted altogether
|
||||||
|
if the original message was not forwarded from an echomail area.
|
||||||
FWDMSGID
|
|
||||||
--------
|
FWDMSGID
|
||||||
|
--------
|
||||||
This control line contains the MSGID control line of the original
|
|
||||||
message. It should be omitted altogether if a MSGID control line is
|
This control line contains the MSGID control line of the original
|
||||||
not present in the original message.
|
message. It should be omitted altogether if a MSGID control line is
|
||||||
|
not present in the original message.
|
||||||
|
|
||||||
2. Usage
|
|
||||||
--------
|
2. Usage
|
||||||
|
--------
|
||||||
When the "forward" function of the message editor is invoked, the
|
|
||||||
editor program should generate the proposed control lines from the
|
When the "forward" function of the message editor is invoked, the
|
||||||
header of the original message. If the original message already was
|
editor program should generate the proposed control lines from the
|
||||||
a forwarded one (indicated by the presence of at least a FWDORIG
|
header of the original message. If the original message already was
|
||||||
control line), the editor should keep all FWD* control lines and
|
a forwarded one (indicated by the presence of at least a FWDORIG
|
||||||
should not add any FWD* control lines. This preserves the FWD*
|
control line), the editor should keep all FWD* control lines and
|
||||||
control lines of the first forwarder, containing the header data of
|
should not add any FWD* control lines. This preserves the FWD*
|
||||||
the author of the original message.
|
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
|
The editor should not generate FWD* control lines, if the message
|
||||||
these control lines, if it not just readdresses 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
|
When the "reply" function of the editor is invoked the program
|
||||||
information. The control lines should not be included in the reply.
|
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
|
Since it may not be immediately clear whether the user wants to
|
||||||
offer a means to ignore the proposed control lines and start a
|
reply to the forwarder or to the original sender, the editor should
|
||||||
"normal" reply instead, e.g. by two distinct functions, by user
|
offer a means to ignore the proposed control lines and start a
|
||||||
preference or a dialog.
|
"normal" reply instead, e.g. by two distinct functions, by user
|
||||||
|
preference or a dialog.
|
||||||
|
|
||||||
Pseudo code:
|
|
||||||
|
Pseudo code:
|
||||||
forwarding_message:
|
|
||||||
if is_forwarded_message then
|
forwarding_message:
|
||||||
don't change FWD* control lines
|
if is_forwarded_message then
|
||||||
else
|
don't change FWD* control lines
|
||||||
add FWD* control lines
|
else
|
||||||
|
add FWD* control lines
|
||||||
quoting_message:
|
|
||||||
if is_forwarded_message then
|
quoting_message:
|
||||||
if reply_to_forwarder then
|
if is_forwarded_message then
|
||||||
use header data (normal quoting)
|
if reply_to_forwarder then
|
||||||
else
|
use header data (normal quoting)
|
||||||
use FWD* control lines
|
else
|
||||||
remove FWD* control lines from reply
|
use FWD* control lines
|
||||||
else
|
remove FWD* control lines from reply
|
||||||
use header data (normal quoting)
|
else
|
||||||
|
use header data (normal quoting)
|
||||||
other_functions:
|
|
||||||
remove/ignore FWD* control lines
|
other_functions:
|
||||||
|
remove/ignore FWD* control lines
|
||||||
|
|
||||||
Example:
|
|
||||||
|
Example:
|
||||||
Message from Joe User to my boss node:
|
|
||||||
|
Message from Joe User to my boss node:
|
||||||
From: Joe User 1:234/567
|
|
||||||
To: Harry Herrmannsdoerfer 2:2490/2520
|
From: Joe User 1:234/567
|
||||||
Subj: Some questions
|
To: Harry Herrmannsdoerfer 2:2490/2520
|
||||||
@MSGID: 1:234/567 12345678
|
Subj: Some questions
|
||||||
Text: Hello Harry!
|
@MSGID: 1:234/567 12345678
|
||||||
...
|
Text: Hello Harry!
|
||||||
|
...
|
||||||
Harry forwards the message to me:
|
|
||||||
|
Harry forwards the message to me:
|
||||||
From: Harry Herrmannsdoerfer 2:2490/2520
|
|
||||||
To: Michael Hohner 2:2490/2520.17
|
From: Harry Herrmannsdoerfer 2:2490/2520
|
||||||
Subj: Joe's message
|
To: Michael Hohner 2:2490/2520.17
|
||||||
@FWDFROM Joe User
|
Subj: Joe's message
|
||||||
@FWDORIG 1:234/567
|
@FWDFROM Joe User
|
||||||
@FWDTO Harry Herrmannsdoerfer
|
@FWDORIG 1:234/567
|
||||||
@FWDDEST 2:2490/2520
|
@FWDTO Harry Herrmannsdoerfer
|
||||||
@FWDSUBJ Some questions
|
@FWDDEST 2:2490/2520
|
||||||
@FWDMSGID 1:234/567 12345678
|
@FWDSUBJ Some questions
|
||||||
Text: Hi Michael!
|
@FWDMSGID 1:234/567 12345678
|
||||||
...
|
Text: Hi Michael!
|
||||||
|
...
|
||||||
My answer using the new control lines:
|
|
||||||
|
My answer using the new control lines:
|
||||||
From: Michael Hohner 2:2490/2520.17
|
|
||||||
To: Joe User 1:234/567
|
From: Michael Hohner 2:2490/2520.17
|
||||||
Subj: Some questions
|
To: Joe User 1:234/567
|
||||||
@REPLY: 1:234/567 12345678
|
Subj: Some questions
|
||||||
Text: Hi Joe!
|
@REPLY: 1:234/567 12345678
|
||||||
|
Text: Hi Joe!
|
||||||
JU> ...
|
|
||||||
...
|
JU> ...
|
||||||
|
...
|
||||||
|
|
||||||
3. Compatiblity
|
|
||||||
---------------
|
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
|
Editor programs which are not prepared for these proposed control
|
||||||
goes to the forwarder. Nothing gained and nothing lost.
|
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
|
|
||||||
------------------------
|
4. Known implementations
|
||||||
|
------------------------
|
||||||
This proposal is implemented in the author's Fidonet editor
|
|
||||||
"FleetStreet for OS/2" (versions 1.17 and newer).
|
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).
|
Also implemented in Odinn Sorensens Fidonet editor "GoldED"
|
||||||
|
(versions 3.00.Alpha5 and newer).
|
||||||
|
|
||||||
A. Contacting the author
|
|
||||||
------------------------
|
A. Contacting the author
|
||||||
|
------------------------
|
||||||
The author may be contacted electronically at the following
|
|
||||||
addresses:
|
The author may be contacted electronically at the following
|
||||||
|
addresses:
|
||||||
Fidonet: 2:2490/2520.17
|
|
||||||
Internet: miho@osn.de
|
Fidonet: 2:2490/2520.17
|
||||||
|
Internet: miho@osn.de
|
||||||
Suggestions, comments and corrections are always welcome.
|
|
||||||
|
Suggestions, comments and corrections are always welcome.
|
||||||
|
|
||||||
B. History
|
|
||||||
----------
|
B. History
|
||||||
|
----------
|
||||||
Rev.1, 19960912: First release as FSC-0092.001.
|
|
||||||
Rev.2, 19971229: Submitted as FSP.
|
Rev.1, 19960912: First release as FSC-0092.001.
|
||||||
|
Rev.2, 19971229: Submitted as FSP.
|
||||||
|
|
||||||
**********************************************************************
|
|
||||||
</PRE>
|
**********************************************************************
|
||||||
|
</PRE>
|
||||||
<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>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,142 +1,143 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>Year 2000 issues in FTN software.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>Year 2000 issues in FTN software.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
**********************************************************************
|
<PRE>
|
||||||
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
**********************************************************************
|
||||||
**********************************************************************
|
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
||||||
|
**********************************************************************
|
||||||
Publication: FSP-1009
|
|
||||||
Revision: 1
|
Publication: FSP-1009
|
||||||
Title: Year 2000 issues in FTN software
|
Revision: 1
|
||||||
Author: Michael Hohner, 2:2490/2520.17
|
Title: Year 2000 issues in FTN software
|
||||||
Revision Date: 29 December 1997
|
Author: Michael Hohner, 2:2490/2520.17
|
||||||
Expiry Date: 29 December 1999
|
Revision Date: 29 December 1997
|
||||||
----------------------------------------------------------------------
|
Expiry Date: 29 December 1999
|
||||||
Contents:
|
----------------------------------------------------------------------
|
||||||
1. Introduction
|
Contents:
|
||||||
2. Generating Fidonet timestamps
|
1. Introduction
|
||||||
3. Interpreting Fidonet timestamps
|
2. Generating Fidonet timestamps
|
||||||
----------------------------------------------------------------------
|
3. Interpreting Fidonet timestamps
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
|
||||||
Status of this document
|
|
||||||
-----------------------
|
Status of this document
|
||||||
|
-----------------------
|
||||||
This document is a Fidonet Standards Proposal (FSP).
|
|
||||||
|
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
|
This document specifies an optional Fidonet standard protocol for
|
||||||
improvements.
|
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 document is released to the public domain, and may be used,
|
||||||
|
copied or modified for any purpose whatever.
|
||||||
|
|
||||||
Abstract
|
|
||||||
--------
|
Abstract
|
||||||
|
--------
|
||||||
The year 2000 causes problems in many computer programs which use
|
|
||||||
two-digit year numbers. Current Fidonet software faces the very same
|
The year 2000 causes problems in many computer programs which use
|
||||||
problems. This FSP specifies procedures which enable FTN software to
|
two-digit year numbers. Current Fidonet software faces the very same
|
||||||
run without problems after the year 2000.
|
problems. This FSP specifies procedures which enable FTN software to
|
||||||
|
run without problems after the year 2000.
|
||||||
|
|
||||||
1. Introduction
|
|
||||||
---------------
|
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 using two-digit year numbers may cause problems in the year
|
||||||
software may interpret the resulting year number as "1900" instead
|
2000. When the year number rolls over from "99" to "00", some
|
||||||
of "2000". Such programs may contain code like this:
|
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! */
|
|
||||||
|
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
|
Fidonet software faces the very same problem: the year number in
|
||||||
interpreting this number incorrectly may decide that messages from
|
packed messages (see FTS-0001) has only two digits. Some programs
|
||||||
the year 1900 are too old and discard them. Other programs probably
|
interpreting this number incorrectly may decide that messages from
|
||||||
just display a wrong calendar year.
|
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
|
The long-term solution would be a transition to four-digit year
|
||||||
every existing software to fail. So a short-term solution is
|
numbers. However, this would require new data formats and cause
|
||||||
required, resulting in only minimal changes in software. This FSP
|
every existing software to fail. So a short-term solution is
|
||||||
contains guidelines for proper year-number interpretation. The
|
required, resulting in only minimal changes in software. This FSP
|
||||||
author encourages all FTN software authors to check their software
|
contains guidelines for proper year-number interpretation. The
|
||||||
for possible year-2000 problems (and release fixed versions during
|
author encourages all FTN software authors to check their software
|
||||||
the next three years).
|
for possible year-2000 problems (and release fixed versions during
|
||||||
|
the next three years).
|
||||||
|
|
||||||
2. Generating Fidonet timestamps
|
|
||||||
--------------------------------
|
2. Generating Fidonet timestamps
|
||||||
|
--------------------------------
|
||||||
This should not cause much headache. However, some software may use
|
|
||||||
the following algorithm:
|
This should not cause much headache. However, some software may use
|
||||||
|
the following algorithm:
|
||||||
year_number = calendar_year - 1900 /* wrong! */
|
|
||||||
|
year_number = calendar_year - 1900 /* wrong! */
|
||||||
This will result in a three-digit year number in 2000 and lead to
|
|
||||||
incorrect Fidonet timestamps.
|
This will result in a three-digit year number in 2000 and lead to
|
||||||
|
incorrect Fidonet timestamps.
|
||||||
One correct algorithm is:
|
|
||||||
|
One correct algorithm is:
|
||||||
year_number = calendar_year mod 100 /* correct! */
|
|
||||||
|
year_number = calendar_year mod 100 /* correct! */
|
||||||
|
|
||||||
3. Interpreting Fidonet timestamps
|
|
||||||
----------------------------------
|
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
|
We can make use of the fact that Fidonet didn't exist before 1980,
|
||||||
smaller than 80 can't mean "year 19xx", but can only mean "year
|
i.e. no messages were created before 1980. So any year number
|
||||||
20xx". One algorithm for correct year number interpretation is:
|
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
|
if year_number < 80 then
|
||||||
else
|
calendar_year = 2000 + year_number
|
||||||
calendar_year = 1900 + 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.
|
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.
|
This solution will work until 2080, giving us another 80+ years to
|
||||||
|
finally let some innovation happen in Fidonet.
|
||||||
|
|
||||||
A. Contacting the author
|
|
||||||
------------------------
|
A. Contacting the author
|
||||||
|
------------------------
|
||||||
The author may be contacted electronically at the following
|
|
||||||
addresses:
|
The author may be contacted electronically at the following
|
||||||
|
addresses:
|
||||||
Fidonet: 2:2490/2520.17
|
|
||||||
Internet: miho@osn.de
|
Fidonet: 2:2490/2520.17
|
||||||
|
Internet: miho@osn.de
|
||||||
Suggestions, comments and corrections are always welcome.
|
|
||||||
|
Suggestions, comments and corrections are always welcome.
|
||||||
|
|
||||||
B. History
|
|
||||||
----------
|
B. History
|
||||||
|
----------
|
||||||
Rev.1, 19971229: Submitted as FSP.
|
|
||||||
|
Rev.1, 19971229: Submitted as FSP.
|
||||||
|
|
||||||
**********************************************************************
|
|
||||||
</PRE>
|
**********************************************************************
|
||||||
|
</PRE>
|
||||||
<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>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,242 +1,243 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>FTSC Document FSP-1010, Revision 001</TITLE>
|
<HEAD>
|
||||||
<BODY
|
<TITLE>FTSC Document FSP-1010, Revision 001</TITLE>
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
**********************************************************************
|
<PRE>
|
||||||
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
**********************************************************************
|
||||||
**********************************************************************
|
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
||||||
|
**********************************************************************
|
||||||
Publication: FSP-1010
|
|
||||||
Revision: 1
|
Publication: FSP-1010
|
||||||
Title: Via kludge specification
|
Revision: 1
|
||||||
Author: Colin Turner,
|
Title: Via kludge specification
|
||||||
Joaquim Homrighausen
|
Author: Colin Turner,
|
||||||
Revision Date: 26 April 1999
|
Joaquim Homrighausen
|
||||||
Expiry Date: 26 April 2001
|
Revision Date: 26 April 1999
|
||||||
----------------------------------------------------------------------
|
Expiry Date: 26 April 2001
|
||||||
Contents:
|
----------------------------------------------------------------------
|
||||||
1. Current practice
|
Contents:
|
||||||
2. Kludge specification
|
1. Current practice
|
||||||
3. Examples
|
2. Kludge specification
|
||||||
4. Deprecated formats
|
3. Examples
|
||||||
----------------------------------------------------------------------
|
4. Deprecated formats
|
||||||
|
----------------------------------------------------------------------
|
||||||
Status of this document
|
|
||||||
-----------------------
|
Status of this document
|
||||||
|
-----------------------
|
||||||
This document is a Fidonet Standards Proposal (FSP).
|
|
||||||
|
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
|
This document specifies an optional Fidonet standard protocol for
|
||||||
improvements.
|
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 document is released to the public domain, and may be used,
|
||||||
|
copied or modified for any purpose whatever.
|
||||||
|
|
||||||
Abstract
|
|
||||||
--------
|
Abstract
|
||||||
|
--------
|
||||||
Current practice for Fidonet Technology Network (FTN) NetMail
|
|
||||||
messages is to track their progress through the network and
|
Current practice for Fidonet Technology Network (FTN) NetMail
|
||||||
programs by using control lines. These control lines are in
|
messages is to track their progress through the network and
|
||||||
the form of a kludge named Via.
|
programs by using control lines. These control lines are in
|
||||||
|
the form of a kludge named Via.
|
||||||
|
|
||||||
1. Current practice
|
|
||||||
-------------------
|
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
|
As NetMail messages are routed through a FidoNet Technology Network
|
||||||
track their progress.
|
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.
|
|
||||||
|
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
|
The Via control lines are stored in a block which starts after any
|
||||||
separated from the preceding control line by a single ASCII <CR>
|
message text. New Via lines should be added to the end of the block
|
||||||
character (0Dh).
|
separated from the preceding control line by a single ASCII <CR>
|
||||||
|
character (0Dh).
|
||||||
A Via control line is typically added:
|
|
||||||
|
A Via control line is typically added:
|
||||||
when a netmail packer packs the NetMail for transmission to
|
|
||||||
another system;
|
when a netmail packer packs the NetMail for transmission to
|
||||||
|
another system;
|
||||||
when a netmail tracker inspects a NetMail.
|
|
||||||
|
when a netmail tracker inspects a NetMail.
|
||||||
2. Kludge specification
|
|
||||||
-----------------------
|
2. Kludge specification
|
||||||
|
-----------------------
|
||||||
The Via control line is formatted as a number of fields, separated
|
|
||||||
by single space (20h) characters, as follows
|
The Via control line is formatted as a number of fields, separated
|
||||||
|
by single space (20h) characters, as follows
|
||||||
^AVia: <FTN Address> @YYYYMMDD.HHMMSS[.Precise][.Time Zone]
|
|
||||||
<Program Name> <Version> [Serial Number]<CR>
|
^AVia: <FTN Address> @YYYYMMDD.HHMMSS[.Precise][.Time Zone]
|
||||||
|
<Program Name> <Version> [Serial Number]<CR>
|
||||||
Where ^A denotes the ASCII <SOH> (01h) character, and <CR> is the
|
|
||||||
character (0Dh).
|
Where ^A denotes the ASCII <SOH> (01h) character, and <CR> is the
|
||||||
|
character (0Dh).
|
||||||
The fields are defined as follows:
|
|
||||||
|
The fields are defined as follows:
|
||||||
FTN Address
|
|
||||||
-----------
|
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
|
This field is mandatory and is the FidoNet Technology address of
|
||||||
domain indicator.
|
the system inserting the kludge. This may or may not include a
|
||||||
|
domain indicator.
|
||||||
@YYYYMMDD.HHMMSS
|
|
||||||
----------------
|
@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
|
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
|
YYYY, the calendar year, in full four digit, decimal form;
|
||||||
zero padded, two digit decimal number;
|
MM, the calendar month, in the range 01 to 12, this must be a
|
||||||
DD, the day of the month, in the range 01 to 31, this must be a
|
zero padded, two digit decimal number;
|
||||||
zero padded, two digit decimal number;
|
DD, the day of the month, in the range 01 to 31, this must be a
|
||||||
HH, hours, in the range 00 to 23, this must be a zero padded,
|
zero padded, two digit decimal number;
|
||||||
two digit decimal number;
|
HH, hours, in the range 00 to 23, this must be a zero padded,
|
||||||
MM, minutes, in the range 00 to 59, this must be a zero padded,
|
two digit decimal number;
|
||||||
two digit decimal number;
|
MM, minutes, in the range 00 to 59, this must be a zero padded,
|
||||||
SS. seconds, in the range 00 to 59, this must be a zero padded,
|
two digit decimal number;
|
||||||
two digit decimal number.
|
SS. seconds, in the range 00 to 59, this must be a zero padded,
|
||||||
|
two digit decimal number.
|
||||||
Precise
|
|
||||||
-------
|
Precise
|
||||||
|
-------
|
||||||
This field is optional and takes the form of extra precision in the
|
|
||||||
time stamp.
|
This field is optional and takes the form of extra precision in the
|
||||||
|
time stamp.
|
||||||
If this field is present:
|
|
||||||
|
If this field is present:
|
||||||
it must begin with a single period character;
|
|
||||||
|
it must begin with a single period character;
|
||||||
this period must be followed by one or more decimal digits;
|
|
||||||
|
this period must be followed by one or more decimal digits;
|
||||||
the field has ended when another period or space is encountered;
|
|
||||||
|
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,
|
each decimal digit in the field following this character
|
||||||
such that the the first digit represents tenths of a second,
|
represents the time of the via line in fractions of a second,
|
||||||
the second digit represents hundreds of a second and so on.
|
such that the the first digit represents tenths of a second,
|
||||||
|
the second digit represents hundreds of a second and so on.
|
||||||
Time Zone
|
|
||||||
---------
|
Time Zone
|
||||||
|
---------
|
||||||
This field is optional, and must be a short, widely accepted
|
|
||||||
alphabetical abbreviation of the time zone that the time stamp
|
This field is optional, and must be a short, widely accepted
|
||||||
in the Via line pertains to.
|
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
|
The use of various Time Zone values is deprecated, implementations
|
||||||
Time (GMT or UTC) and use the "UTC" Time Zone indicator, where
|
should attempt to convert the timestamp in the kludge to Universal
|
||||||
possible.
|
Time (GMT or UTC) and use the "UTC" Time Zone indicator, where
|
||||||
|
possible.
|
||||||
The Time Zone field may only be ommitted when it is not possible
|
|
||||||
for the implementation to determine the correct offset from UTC,
|
The Time Zone field may only be ommitted when it is not possible
|
||||||
and in this case the time stamp must represent local time on the
|
for the implementation to determine the correct offset from UTC,
|
||||||
generating system.
|
and in this case the time stamp must represent local time on the
|
||||||
|
generating system.
|
||||||
Program Name
|
|
||||||
------------
|
Program Name
|
||||||
|
------------
|
||||||
This field is mandatory, and must follow the format used in the PID
|
|
||||||
control line (detailed in FSC-46).
|
This field is mandatory, and must follow the format used in the PID
|
||||||
|
control line (detailed in FSC-46).
|
||||||
Version
|
|
||||||
-------
|
Version
|
||||||
|
-------
|
||||||
This field is mandatory, and must follow the format used in the PID
|
|
||||||
control line (detailed in FSC-46).
|
This field is mandatory, and must follow the format used in the PID
|
||||||
|
control line (detailed in FSC-46).
|
||||||
Serial Number
|
|
||||||
-------------
|
Serial Number
|
||||||
|
-------------
|
||||||
This field is optional, and must follow the format used in the PID
|
|
||||||
control line (detailed in FSC-46).
|
This field is optional, and must follow the format used in the PID
|
||||||
|
control line (detailed in FSC-46).
|
||||||
Note that unlike many kludges, the "Via" text of the kludge itself
|
|
||||||
is in mixed, and not all upper case.
|
Note that unlike many kludges, the "Via" text of the kludge itself
|
||||||
|
is in mixed, and not all upper case.
|
||||||
3. Examples
|
|
||||||
-----------
|
3. Examples
|
||||||
|
-----------
|
||||||
Example of valid usage are
|
|
||||||
|
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 @19990305.043212.UTC O/T-Track+ 2.69
|
||||||
^AVia 2:443/13.0 @19990101.002102.UTC FastEcho 1.46.1 21321
|
^AVia 2:443/13@fidonet @19980331.231202.UTC FrontDoor 2.32.mL
|
||||||
^AVia 2:443/13 @19990323.230132 FakeMail 1.2
|
^AVia 2:443/13.0 @19990101.002102.UTC FastEcho 1.46.1 21321
|
||||||
^AVia 2:2480/18@fidonet @19990307.182128.47.UTC ITrack+ 1.3/G6 FP000069
|
^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
|
|
||||||
---------------------
|
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
|
Some other formats for the Via line are in use today, but these
|
||||||
the format specified above is both more widespread and more
|
formats are rather variable and inconsistent in nature, while
|
||||||
consistent.
|
the format specified above is both more widespread and more
|
||||||
|
consistent.
|
||||||
New implentations may need to parse these formats, but must not
|
|
||||||
generate them.
|
New implentations may need to parse these formats, but must not
|
||||||
|
generate them.
|
||||||
The formats in use include, but are not limited to
|
|
||||||
|
The formats in use include, but are not limited to
|
||||||
<NAME> [VERSION] [SERIAL] <ADDRESS> <TIMESTAMP> <TIMEZONE>
|
|
||||||
<NAME> <ADDRESS>, <TIMESTAMP> <TIMEZONE> <VERSION>
|
<NAME> [VERSION] [SERIAL] <ADDRESS> <TIMESTAMP> <TIMEZONE>
|
||||||
|
<NAME> <ADDRESS>, <TIMESTAMP> <TIMEZONE> <VERSION>
|
||||||
Not that the time stamp in the above formats is also widely
|
|
||||||
variable, and takes forms which include, but may not be limited to
|
Not that the time stamp in the above formats is also widely
|
||||||
|
variable, and takes forms which include, but may not be limited to
|
||||||
<Day> <Month> <Year> AT <Hour>:<Min>:[Sec]
|
|
||||||
<Day of Week> <Month> <Day of Month> <Year> <Hour>:<Min>:<Sec>
|
<Day> <Month> <Year> AT <Hour>:<Min>:[Sec]
|
||||||
ON <Day of Month> <Month> <Year> <Hour>:<Min>:<Sec>
|
<Day of Week> <Month> <Day of Month> <Year> <Hour>:<Min>:<Sec>
|
||||||
<Month>/<Day> <Hour>:<Min>
|
ON <Day of Month> <Month> <Year> <Hour>:<Min>:<Sec>
|
||||||
@YYMMDDHHMMSS
|
<Month>/<Day> <Hour>:<Min>
|
||||||
|
@YYMMDDHHMMSS
|
||||||
In the last listed format, observe in particular the two digit year
|
|
||||||
and lack of period to seperate the date from time.
|
In the last listed format, observe in particular the two digit year
|
||||||
|
and lack of period to seperate the date from time.
|
||||||
A. References
|
|
||||||
-------------
|
A. References
|
||||||
|
-------------
|
||||||
[FTS-1] "A Basic FidoNet(r) Technical Standard Revision 16", Randy
|
|
||||||
Bush. September 1995.
|
[FTS-1] "A Basic FidoNet(r) Technical Standard Revision 16", Randy
|
||||||
|
Bush. September 1995.
|
||||||
[FSC-46] "A Product Identifier for FidoNet Message Handlers",
|
|
||||||
Joaquim Homrighausen, August 1994.
|
[FSC-46] "A Product Identifier for FidoNet Message Handlers",
|
||||||
|
Joaquim Homrighausen, August 1994.
|
||||||
|
|
||||||
B. Author contact data
|
|
||||||
----------------------
|
B. Author contact data
|
||||||
|
----------------------
|
||||||
Colin Turner
|
|
||||||
Fidonet: 2:443/13
|
Colin Turner
|
||||||
E-mail: ct@piglets.com
|
Fidonet: 2:443/13
|
||||||
WWW: http://www.piglets.com
|
E-mail: ct@piglets.com
|
||||||
|
WWW: http://www.piglets.com
|
||||||
Joaquim Homrighausen
|
|
||||||
Fidonet: 2:201/330
|
Joaquim Homrighausen
|
||||||
E-mail: joho@defsol.se
|
Fidonet: 2:201/330
|
||||||
WWW: http://www.defsol.se
|
E-mail: joho@defsol.se
|
||||||
|
WWW: http://www.defsol.se
|
||||||
|
|
||||||
C. History
|
|
||||||
----------
|
C. History
|
||||||
|
----------
|
||||||
Rev.1, 990426: First release.
|
|
||||||
|
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>
|
</PRE>
|
||||||
</BODY>
|
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
|
||||||
|
</BODY>
|
||||||
|
|
||||||
|
|||||||
File diff suppressed because it is too large
Load Diff
@ -1,268 +1,269 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>FTSC Product ID List.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>FTSC Product ID List.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
**********************************************************************
|
<PRE>
|
||||||
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
**********************************************************************
|
||||||
**********************************************************************
|
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
||||||
|
**********************************************************************
|
||||||
Publication: FTA-1005
|
|
||||||
Revision: 3
|
Publication: FTA-1005
|
||||||
Title: FTSC Product Codes
|
Revision: 3
|
||||||
Author: Administrator
|
Title: FTSC Product Codes
|
||||||
Revision Date: 22 March 1998
|
Author: Administrator
|
||||||
Expiry Date: 22 March 1998
|
Revision Date: 22 March 1998
|
||||||
----------------------------------------------------------------------
|
Expiry Date: 22 March 1998
|
||||||
Contents:
|
----------------------------------------------------------------------
|
||||||
1. Format of product code list
|
Contents:
|
||||||
2. Application for a product code
|
1. Format of product code list
|
||||||
----------------------------------------------------------------------
|
2. Application for a product code
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
|
||||||
1. Format of product code list
|
|
||||||
------------------------------
|
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
|
The FTSC publishes a list of all product codes issued. The filename
|
||||||
revision.
|
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
|
The list is an ASCII text file with one line per product. Each line
|
||||||
contain more than one value. In this case, the different values are
|
contains a number of fields, delimited by commas. Some fields may
|
||||||
delimited with a forward slash ('/'). Spaces in fields are replaced
|
contain more than one value. In this case, the different values are
|
||||||
with underscores ('_'). Fields are not case-sensitive.
|
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:
|
|
||||||
|
These are the fields which are currently defined:
|
||||||
code,name,platform,type,contact,netaddr[,assigned[,updated]]
|
|
||||||
|
code,name,platform,type,contact,netaddr[,assigned[,updated]]
|
||||||
code The product code. 4 digits hexadecimal.
|
|
||||||
name Product name.
|
code The product code. 4 digits hexadecimal.
|
||||||
platform Platforms(s) supported.
|
name Product name.
|
||||||
type Type(s) of product.
|
platform Platforms(s) supported.
|
||||||
contact Name of contact person.
|
type Type(s) of product.
|
||||||
netaddr FidoNet address of contact person.
|
contact Name of contact person.
|
||||||
assigned Date the product code was originally assigned.
|
netaddr FidoNet address of contact person.
|
||||||
updated Date of last update of the product code data.
|
assigned Date the product code was originally assigned.
|
||||||
|
updated Date of last update of the product code data.
|
||||||
Platforms
|
|
||||||
---------
|
Platforms
|
||||||
See the list for examples. (Will be specified more firmly later).
|
---------
|
||||||
|
See the list for examples. (Will be specified more firmly later).
|
||||||
Product types
|
|
||||||
-------------
|
Product types
|
||||||
Mailer A mailer is a product that exchanges mail with FTS-0001,
|
-------------
|
||||||
FTS-0006, EMSI or other protocols that include a product
|
Mailer A mailer is a product that exchanges mail with FTS-0001,
|
||||||
code field.
|
FTS-0006, EMSI or other protocols that include a product
|
||||||
Packer A packer is a product that creates .PKT files.
|
code field.
|
||||||
|
Packer A packer is a product that creates .PKT files.
|
||||||
Dates
|
|
||||||
-----
|
Dates
|
||||||
The format is YYYYMMDD. A date field may also be blank.
|
-----
|
||||||
|
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
|
If you write software which is dependant on this format, please make
|
||||||
compatibility.
|
it tolerant of additional fields after these for upwards
|
||||||
|
compatibility.
|
||||||
|
|
||||||
2. Application for a product code
|
|
||||||
---------------------------------
|
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
|
FidoNet products without an allocated product code which either
|
||||||
product code FEh (254d) in Type-2 compatible packet headers. This
|
create Type-2 packets, or negotiate FTS-0001 sessions must use a
|
||||||
code as been reserved for that purpose (use by product without a
|
product code FEh (254d) in Type-2 compatible packet headers. This
|
||||||
product code). The product code FFh (255d) has been reserved to
|
code as been reserved for that purpose (use by product without a
|
||||||
indicate that the product code is stored elsewhere in the packet
|
product code). The product code FFh (255d) has been reserved to
|
||||||
header at an as yet unallocated offset.
|
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
|
The FTSC is currently working on an update to the Type-2 packet
|
||||||
compatibility with 8-bit codes (something which the current Type-2
|
specification, to allow 16-bit codes while keeping full backward
|
||||||
proposals in the FSC's are not). Until the specification is ready,
|
compatibility with 8-bit codes (something which the current Type-2
|
||||||
16-bit codes are issued with the low byte set to FFh (255d).
|
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
|
Below is an application form for an FTSC product code, which is used
|
||||||
by which you can be contacted should your product be found
|
to identify your product when used in FidoNet, and providing a means
|
||||||
responsible for problems encountered during its use. The issuance of
|
by which you can be contacted should your product be found
|
||||||
this product code in no way implies authorisation or approval of
|
responsible for problems encountered during its use. The issuance of
|
||||||
your product for use on the network, only provides a means of ready
|
this product code in no way implies authorisation or approval of
|
||||||
identification.
|
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
|
This application should be completed and submitted for only `real'
|
||||||
are currently developing a product which is not yet ready for use on
|
and completed products which will be used by FidoNet systems. If you
|
||||||
the network out of experimental stage, use product code 0 (zero)
|
are currently developing a product which is not yet ready for use on
|
||||||
which is, by convention, reserved for this purpose.
|
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
|
Please answer the questions as accurately and completely as
|
||||||
describe only the current product, and leave future features and
|
possible. We need to know what will actually be used on the net, so
|
||||||
plans for the comments section.
|
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.
|
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
|
We hope that you will take the time to revise your answers by
|
||||||
information you provide is compiled into a list of all product codes
|
submitting updates as your product changes. A summary of the
|
||||||
published and updated periodically by the FTSC called
|
information you provide is compiled into a list of all product codes
|
||||||
"FTSCPROD.nnn".
|
published and updated periodically by the FTSC called
|
||||||
|
"FTSCPROD.nnn".
|
||||||
|
|
||||||
A. Application Form
|
|
||||||
-------------------
|
A. Application Form
|
||||||
|
-------------------
|
||||||
--- Cut along here ---------------------------------------------------
|
|
||||||
|
--- Cut along here ---------------------------------------------------
|
||||||
FTSC Product Code Application
|
|
||||||
=============================
|
FTSC Product Code Application
|
||||||
|
=============================
|
||||||
Type of application
|
|
||||||
-------------------
|
Type of application
|
||||||
|
-------------------
|
||||||
1. Mark whichever is appropriate:
|
|
||||||
|
1. Mark whichever is appropriate:
|
||||||
____ New product application
|
|
||||||
____ Update existing product for existing product code ____
|
____ 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.)
|
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
|
|
||||||
-------------------
|
Product information
|
||||||
|
-------------------
|
||||||
3. What is the name of the product and the current version name or
|
|
||||||
number?
|
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
|
4. What is the name, FidoNet node, and postal address, and voice
|
||||||
product? Where should inquiries be directed and who should be
|
number of the person(s) or organization responsible for the
|
||||||
contacted if the product is thought to cause errors on the
|
product? Where should inquiries be directed and who should be
|
||||||
network?
|
contacted if the product is thought to cause errors on the
|
||||||
|
network?
|
||||||
__________________________________________________________________
|
|
||||||
__________________________________________________________________
|
__________________________________________________________________
|
||||||
__________________________________________________________________
|
__________________________________________________________________
|
||||||
__________________________________________________________________
|
__________________________________________________________________
|
||||||
__________________________________________________________________
|
__________________________________________________________________
|
||||||
|
__________________________________________________________________
|
||||||
|
|
||||||
5. What operating systems does it currently run on?
|
|
||||||
|
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,
|
6. Does the product contain a 'mailer'? E.g. the package transmits
|
||||||
though it may handle other protocols.
|
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
|
7. If the answer to question (6) is yes, what additional protocols
|
||||||
specific FTSC document which details this protocol, if any.
|
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?
|
|
||||||
|
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?
|
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?
|
|
||||||
|
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
|
9. Is your software capable of functioning as a Continuous Mail
|
||||||
FidoNet nodelist?
|
system? i.e. nodes running it might be marked as such in the
|
||||||
|
FidoNet nodelist?
|
||||||
__________________________________________________________________
|
|
||||||
|
__________________________________________________________________
|
||||||
|
|
||||||
10. How is the product distributed?
|
|
||||||
|
10. How is the product distributed?
|
||||||
Public Domain ____________ Shareware ______________
|
|
||||||
Commercial ____________ Other ______________
|
Public Domain ____________ Shareware ______________
|
||||||
Object code ____________ Source code ______________
|
Commercial ____________ Other ______________
|
||||||
|
Object code ____________ Source code ______________
|
||||||
Comments: ________________________________________________________
|
|
||||||
__________________________________________________________________
|
Comments: ________________________________________________________
|
||||||
__________________________________________________________________
|
__________________________________________________________________
|
||||||
|
__________________________________________________________________
|
||||||
|
|
||||||
11. Please give additional comments to describe your product.
|
|
||||||
|
11. Please give additional comments to describe your product.
|
||||||
__________________________________________________________________
|
|
||||||
__________________________________________________________________
|
__________________________________________________________________
|
||||||
__________________________________________________________________
|
__________________________________________________________________
|
||||||
__________________________________________________________________
|
__________________________________________________________________
|
||||||
__________________________________________________________________
|
__________________________________________________________________
|
||||||
__________________________________________________________________
|
__________________________________________________________________
|
||||||
__________________________________________________________________
|
__________________________________________________________________
|
||||||
|
__________________________________________________________________
|
||||||
--- Cut along here ---------------------------------------------------
|
|
||||||
|
--- Cut along here ---------------------------------------------------
|
||||||
|
|
||||||
B. Acknowledgements
|
|
||||||
-------------------
|
B. Acknowledgements
|
||||||
|
-------------------
|
||||||
The application form was inspired by one originally published in
|
|
||||||
FSC-0022 and later FSC-0090, originally by Bob Hartman, Jim Long,
|
The application form was inspired by one originally published in
|
||||||
and Randy Bush and modified by Rick Moore and David Nugent.
|
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
|
|
||||||
----------
|
C. History
|
||||||
|
----------
|
||||||
Rev.1, 19970407: First non-draft release. Author Adrian Walker.
|
|
||||||
Rev.2, 19971229: Author changed to Administrator. Reformatted
|
Rev.1, 19970407: First non-draft release. Author Adrian Walker.
|
||||||
document slightly. Changed all dates in the lists
|
Rev.2, 19971229: Author changed to Administrator. Reformatted
|
||||||
to 4 digit centuries. Added information about
|
document slightly. Changed all dates in the lists
|
||||||
status of 16-bit product codes.
|
to 4 digit centuries. Added information about
|
||||||
Rev.3, 19980322: Moved the product code list out of the document and
|
status of 16-bit product codes.
|
||||||
into a separate list, FTSCPROD.nnn. Added an
|
Rev.3, 19980322: Moved the product code list out of the document and
|
||||||
application form. Revised text about 16 bit codes.
|
into a separate list, FTSCPROD.nnn. Added an
|
||||||
|
application form. Revised text about 16 bit codes.
|
||||||
|
|
||||||
**********************************************************************
|
|
||||||
</PRE>
|
**********************************************************************
|
||||||
|
</PRE>
|
||||||
<A HREF="./"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
|
|
||||||
|
<A HREF="./"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
|
||||||
</BODY>
|
|
||||||
</HTML>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
File diff suppressed because it is too large
Load Diff
@ -1,414 +1,415 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>Echomail Specification.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>Echomail Specification.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
FTS-0004 EchoMail Specification
|
<PRE>
|
||||||
|
FTS-0004 EchoMail Specification
|
||||||
This document is directly derived from the documentation of
|
|
||||||
|
This document is directly derived from the documentation of
|
||||||
-------------------------------------------------------------------------------
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
The Conference Mail System
|
|
||||||
|
The Conference Mail System
|
||||||
By
|
|
||||||
Bob Hartman
|
By
|
||||||
Sysop of FidoNet(tm) node 132/101
|
Bob Hartman
|
||||||
|
Sysop of FidoNet(tm) node 132/101
|
||||||
(C) Copyright 1986,87, Spark Software, Inc.
|
|
||||||
|
(C) Copyright 1986,87, Spark Software, Inc.
|
||||||
427-3 Amherst Street
|
|
||||||
CS 2032, Suite 232
|
427-3 Amherst Street
|
||||||
Nashua, N.H. 03061
|
CS 2032, Suite 232
|
||||||
|
Nashua, N.H. 03061
|
||||||
ALL RIGHTS RESERVED.
|
|
||||||
|
ALL RIGHTS RESERVED.
|
||||||
-------------------------------------------------------------------------------
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
version 3.31 of 12 December, 1987.
|
|
||||||
|
version 3.31 of 12 December, 1987.
|
||||||
With Bob Hartman's kind consent, copying for the purpose of technological
|
|
||||||
research and advancement is allowed.
|
With Bob Hartman's kind consent, copying for the purpose of technological
|
||||||
|
research and advancement is allowed.
|
||||||
|
|
||||||
-------------------------------------------------------------------------------
|
|
||||||
-------------------------------------------------------------------------------
|
-------------------------------------------------------------------------------
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
|
||||||
WHAT IS THE CONFERENCE MAIL SYSTEM?
|
|
||||||
|
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
|
Conference Mail is a technique to permit several nodes on a
|
||||||
conferences available on many of the computer services, but it is
|
network to share a message base, similar in concept to the
|
||||||
most closely related to the Usenet system consisting of more than
|
conferences available on many of the computer services, but it is
|
||||||
8,000 systems world wide. All systems sharing a given conference
|
most closely related to the Usenet system consisting of more than
|
||||||
see any messages entered into the conference by any of the
|
8,000 systems world wide. All systems sharing a given conference
|
||||||
participating systems. This can be implemented in such a way as
|
see any messages entered into the conference by any of the
|
||||||
to be totally transparent to the users of a particular node. In
|
participating systems. This can be implemented in such a way as
|
||||||
fact, they may not even be aware of the network being used to
|
to be totally transparent to the users of a particular node. In
|
||||||
move their messages about from node to node! Unfortunately, this
|
fact, they may not even be aware of the network being used to
|
||||||
has its disadvantages also - most users who are not educated
|
move their messages about from node to node! Unfortunately, this
|
||||||
about Conference Mail do not realize the messages transmitted
|
has its disadvantages also - most users who are not educated
|
||||||
cost MANY sysops (system operators) money, not just the local
|
about Conference Mail do not realize the messages transmitted
|
||||||
sysop. This is an important consideration in Conference Mail and
|
cost MANY sysops (system operators) money, not just the local
|
||||||
should not be taken lightly. In a conference with 100 systems as
|
sysop. This is an important consideration in Conference Mail and
|
||||||
participants the cost per message can get quite high.
|
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
|
The Conference Mail System is designed to operate in conjunction
|
||||||
mail servers are Fido(tm), SEAdog(tm), Opus, and Dutchie. Since
|
with a FidoNet compatible mail server. The currently supported
|
||||||
the mail server is a prerequisite to using the Conference Mail
|
mail servers are Fido(tm), SEAdog(tm), Opus, and Dutchie. Since
|
||||||
System, it will be assumed you already have your mail server
|
the mail server is a prerequisite to using the Conference Mail
|
||||||
operating correctly on your system, and you are connected into
|
System, it will be assumed you already have your mail server
|
||||||
FidoNet or a compatible network.
|
operating correctly on your system, and you are connected into
|
||||||
|
FidoNet or a compatible network.
|
||||||
|
|
||||||
HISTORY OF THE CONFERENCE MAIL SYSTEM
|
|
||||||
|
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.
|
In late 1985, Jeff Rush, a Fido sysop in Dallas, wanted a
|
||||||
He created a system of programs he called Echomail, and the
|
convenient means of sharing ideas with the other Dallas sysops.
|
||||||
Dallas sysops' Conference was born.
|
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.
|
Within a short time sysops in other areas began hearing of this
|
||||||
Today, a scant year and a half later, the FidoNet public network
|
marvelous new gadget and Echomail took on a life of its own.
|
||||||
boasts a myriad of conferences varying in size from the dozen-or-
|
Today, a scant year and a half later, the FidoNet public network
|
||||||
so participants in the FidoNet Technical Standards Committee
|
boasts a myriad of conferences varying in size from the dozen-or-
|
||||||
Conference to the Sysops' Conference with several hundred
|
so participants in the FidoNet Technical Standards Committee
|
||||||
participants. It is not uncommon for a node to carry 30 or more
|
Conference to the Sysops' Conference with several hundred
|
||||||
conferences and share those conferences with 10 or more nodes.
|
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
|
|
||||||
|
HOW IT WORKS
|
||||||
The Conference Mail System is functionally compatible with the
|
|
||||||
original Echomail utilities. In general, the process is:
|
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.
|
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
|
2. This message is "Exported" along with some control information
|
||||||
system.
|
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.
|
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
|
4. The receiving systems then "Export" these messages, along with
|
||||||
links.
|
additional control information, to each of their conference
|
||||||
|
links.
|
||||||
5. Return to step 3.
|
|
||||||
|
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
|
As you can see, the method is quite simple - in general. Of
|
||||||
never stop being Exported and transmitted to other systems. This
|
course, following the steps literally would mean messages would
|
||||||
obviously would not be desired or the network would quickly
|
never stop being Exported and transmitted to other systems. This
|
||||||
become overburdened. The information contained in the 'control
|
obviously would not be desired or the network would quickly
|
||||||
information' section is used to prevent transmitting the same
|
become overburdened. The information contained in the 'control
|
||||||
message more than once to a single system.
|
information' section is used to prevent transmitting the same
|
||||||
|
message more than once to a single system.
|
||||||
|
|
||||||
CONFERENCE MAIL MESSAGE CONTROL INFORMATION
|
|
||||||
|
CONFERENCE MAIL MESSAGE CONTROL INFORMATION
|
||||||
There are five pieces of control information associated with a
|
|
||||||
Conference Mail message. Some are optional, some are not.
|
There are five pieces of control information associated with a
|
||||||
Normally this information is never entered by the person creating
|
Conference Mail message. Some are optional, some are not.
|
||||||
the message. The following control fields determine how
|
Normally this information is never entered by the person creating
|
||||||
Conference Mail is handled:
|
the message. The following control fields determine how
|
||||||
|
Conference Mail is handled:
|
||||||
1. Area line
|
|
||||||
|
1. Area line
|
||||||
This is the first line of a conference mail message. Its
|
|
||||||
actual appearance is:
|
This is the first line of a conference mail message. Its
|
||||||
|
actual appearance is:
|
||||||
AREA:CONFERENCE
|
|
||||||
|
AREA:CONFERENCE
|
||||||
Where CONFERENCE is the name of the conference. This line is
|
|
||||||
added when a conference is being "Exported" to another
|
Where CONFERENCE is the name of the conference. This line is
|
||||||
system. It is based upon information found in the AREAS.BBS
|
added when a conference is being "Exported" to another
|
||||||
(configuration) File for the designated message area. This
|
system. It is based upon information found in the AREAS.BBS
|
||||||
field is REQUIRED by the receiving system to "Import" a
|
(configuration) File for the designated message area. This
|
||||||
message into the correct Conference Mail area.
|
field is REQUIRED by the receiving system to "Import" a
|
||||||
|
message into the correct Conference Mail area.
|
||||||
2. Tear Line
|
|
||||||
|
2. Tear Line
|
||||||
This line is near the end of a message and consists of three
|
|
||||||
dashes (---) followed by an optional program specifier.
|
This line is near the end of a message and consists of three
|
||||||
This is used to show the first program used to add Echomail
|
dashes (---) followed by an optional program specifier.
|
||||||
compatible control information to the message. The tear line
|
This is used to show the first program used to add Echomail
|
||||||
generated by Conference Mail looks like:
|
compatible control information to the message. The tear line
|
||||||
|
generated by Conference Mail looks like:
|
||||||
--- <a small product-specific banner>
|
|
||||||
|
--- <a small product-specific banner>
|
||||||
This field is optional for most Echomail compatible
|
|
||||||
processors, and is added by the Conference Mail System to
|
This field is optional for most Echomail compatible
|
||||||
ensure complete compatibility. Some systems will place this
|
processors, and is added by the Conference Mail System to
|
||||||
line in the message when it is first created, but it is
|
ensure complete compatibility. Some systems will place this
|
||||||
normally added when the message is first "exported."
|
line in the message when it is first created, but it is
|
||||||
|
normally added when the message is first "exported."
|
||||||
3. Origin line
|
|
||||||
|
3. Origin line
|
||||||
This line appears near the bottom of a message and gives a
|
|
||||||
small amount of information about the system where it
|
This line appears near the bottom of a message and gives a
|
||||||
originated. It looks like:
|
small amount of information about the system where it
|
||||||
|
originated. It looks like:
|
||||||
* Origin: The Conference Mail BBS (1:132/101)
|
|
||||||
|
* 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
|
The " * Origin: " part of the line is a constant field.
|
||||||
AREAS.BBS file or a file named ORIGIN located in the DOS
|
This is followed by the name of the system as taken from the
|
||||||
directory of the designated message area. The complete
|
AREAS.BBS file or a file named ORIGIN located in the DOS
|
||||||
network address (1:132/101 in this case) is added by the
|
directory of the designated message area. The complete
|
||||||
program inserting the line. This field is generated at the
|
network address (1:132/101 in this case) is added by the
|
||||||
same time as the tear line, and therefore may either be
|
program inserting the line. This field is generated at the
|
||||||
generated at the time of creation or during the first
|
same time as the tear line, and therefore may either be
|
||||||
"export" processing. Although the Origin line is not
|
generated at the time of creation or during the first
|
||||||
required by all Echomail processors, it is added by the
|
"export" processing. Although the Origin line is not
|
||||||
Conference Mail System to ensure complete compatibility.
|
required by all Echomail processors, it is added by the
|
||||||
|
Conference Mail System to ensure complete compatibility.
|
||||||
|
|
||||||
4. Seen-by Lines
|
|
||||||
|
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
|
There can be many seen-by lines at the end of Conference
|
||||||
information. They are used to determine the systems to
|
Mail messages, and they are the real "meat" of the control
|
||||||
receive the exported messages. The format of the line is:
|
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
|
|
||||||
|
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
|
The net/node numbers correspond to the net/node numbers of
|
||||||
a message is never sent to a system twice. In a conference
|
the systems having already received the message. In this way
|
||||||
with many participants the number of seen-by lines can be
|
a message is never sent to a system twice. In a conference
|
||||||
very large. This line is added if it is not already a part
|
with many participants the number of seen-by lines can be
|
||||||
of the message, or added to if it already exists, each time
|
very large. This line is added if it is not already a part
|
||||||
a message is exported to other systems. This is a REQUIRED
|
of the message, or added to if it already exists, each time
|
||||||
field, and Conference Mail will not function correctly if
|
a message is exported to other systems. This is a REQUIRED
|
||||||
this field is not put in place by other Echomail compatible
|
field, and Conference Mail will not function correctly if
|
||||||
programs.
|
this field is not put in place by other Echomail compatible
|
||||||
|
programs.
|
||||||
5. PATH Lines
|
|
||||||
|
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
|
These are the last lines in a Conference Mail message and
|
||||||
Echomail processors. It appears as follows:
|
are a new addition, and therefore is not supported by all
|
||||||
|
Echomail processors. It appears as follows:
|
||||||
^aPATH: 132/101 1014/1
|
|
||||||
|
^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
|
Where the ^a stands for Control-A (ASCII character 1) and
|
||||||
processed the message before it reached the current system.
|
the net/nodes listed correspond to those systems having
|
||||||
This is not the same as the seen-by lines, because those
|
processed the message before it reached the current system.
|
||||||
lines list all systems the message has been sent to, while
|
This is not the same as the seen-by lines, because those
|
||||||
the path line contains all systems having actually processed
|
lines list all systems the message has been sent to, while
|
||||||
the message. This is not a required field, and few echomail
|
the path line contains all systems having actually processed
|
||||||
processors currently support it, however it can be used
|
the message. This is not a required field, and few echomail
|
||||||
safely with any other system, since the line(s) will be
|
processors currently support it, however it can be used
|
||||||
ignored. For a discussion on how the path line can be
|
safely with any other system, since the line(s) will be
|
||||||
helpful, see the "Advanced Features" section of this manual.
|
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
|
|
||||||
|
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
|
To this point the issue of how Conference Mail is actually sent
|
||||||
is exported to another system." What exactly does this mean?
|
has been glossed over entirely. The phrase has been, "the message
|
||||||
Well, for starters lets show what is called the "basic" setup:
|
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
|
In this setup exported mail is placed into the FidoNet mail area.
|
||||||
message generated for each receiving system. This mail is then
|
Each message exported from a Conference Mail area has one
|
||||||
sent the same as any other network mail. When Echomail was first
|
message generated for each receiving system. This mail is then
|
||||||
created this was the only way mail could be sent.
|
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
|
The "basic" method has some disadvantages. First, since Echomail
|
||||||
day imported into various message bases. It is also not uncommon
|
has grown so large it is not uncommon to get 200 new messages per
|
||||||
for a system to be exporting messages to 4 or 5 other systems.
|
day imported into various message bases. It is also not uncommon
|
||||||
Simple arithmetic shows 800-1000 messages per day would be sent
|
for a system to be exporting messages to 4 or 5 other systems.
|
||||||
in normal netmail! This puts a tremendous strain on any netmail
|
Simple arithmetic shows 800-1000 messages per day would be sent
|
||||||
system, not to mention transmission time and the resultant phone
|
in normal netmail! This puts a tremendous strain on any netmail
|
||||||
charges. When this limitation of Echomail was first noticed a lot
|
system, not to mention transmission time and the resultant phone
|
||||||
of people started scratching their heads wondering what to do. If
|
charges. When this limitation of Echomail was first noticed a lot
|
||||||
a solution could not be found it appeared Echomail would
|
of people started scratching their heads wondering what to do. If
|
||||||
certainly overrun the capabilities of FidoNet.
|
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
|
Thom Henderson (from System Enhancement Associates) came up with
|
||||||
file archiving and compression program, he knew the savings
|
the original ARCmail program. Having previously written the ARC
|
||||||
achievable by having all of the netmail messages placed in .ARC
|
file archiving and compression program, he knew the savings
|
||||||
format for transmission. As a byproduct, the messages no longer
|
achievable by having all of the netmail messages placed in .ARC
|
||||||
appeared in the netmail area, but were included in a file
|
format for transmission. As a byproduct, the messages no longer
|
||||||
attached to a message (see your FidoNet mailer manual for file
|
appeared in the netmail area, but were included in a file
|
||||||
attaches). In this way the tremendous number of messages
|
attached to a message (see your FidoNet mailer manual for file
|
||||||
generated, and the phone bill problems were both solved.
|
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
|
Unfortunately, ARCmail required the messages to first be placed
|
||||||
caused the messages to be scanned once when they were exported,
|
into the netmail area before it could be run. In effect, it
|
||||||
once during the ARCmail phase, once when ARCmail was run at the
|
caused the messages to be scanned once when they were exported,
|
||||||
other end to get the messages out of .ARC format, and once when
|
once during the ARCmail phase, once when ARCmail was run at the
|
||||||
those messages were later imported into a message base on the
|
other end to get the messages out of .ARC format, and once when
|
||||||
receiving system. The Conference Mail System solves this problem
|
those messages were later imported into a message base on the
|
||||||
by eliminating the ARCmail program. Conference Mail builds the
|
receiving system. The Conference Mail System solves this problem
|
||||||
ARCmail files during Export, and unpacks them during Import. This
|
by eliminating the ARCmail program. Conference Mail builds the
|
||||||
way messages are exported directly to ARCmail style file
|
ARCmail files during Export, and unpacks them during Import. This
|
||||||
attaches, and imported directly from ARCmail style file attaches.
|
way messages are exported directly to ARCmail style file
|
||||||
The scanning phases between importing and exporting messages are
|
attaches, and imported directly from ARCmail style file attaches.
|
||||||
totally removed and processing time is proportionally reduced.
|
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
|
This is now the most common method for sending Conference Mail
|
||||||
importing and exporting phases is much less than what is involved
|
between systems. The overhead involved in doing it during the
|
||||||
if ARCmailing is not utilized. This was a primary consideration
|
importing and exporting phases is much less than what is involved
|
||||||
in the design and implementation of the Conference Mail System,
|
if ARCmailing is not utilized. This was a primary consideration
|
||||||
and as a result the entire system is optimized for this type of
|
in the design and implementation of the Conference Mail System,
|
||||||
use. Please refer to the Import and Export functions for
|
and as a result the entire system is optimized for this type of
|
||||||
specifics on how to use the ARCmailing feature.
|
use. Please refer to the Import and Export functions for
|
||||||
|
specifics on how to use the ARCmailing feature.
|
||||||
|
|
||||||
CONFERENCE TOPOLOGY
|
|
||||||
|
CONFERENCE TOPOLOGY
|
||||||
The way in which systems link together for a particular
|
|
||||||
conference is called the "conference topology." It is important
|
The way in which systems link together for a particular
|
||||||
to know this structure for two reasons: 1) It is important to
|
conference is called the "conference topology." It is important
|
||||||
have a topology which is efficient in the transfer of the
|
to know this structure for two reasons: 1) It is important to
|
||||||
Conference Mail messages, and 2) It is important to have a
|
have a topology which is efficient in the transfer of the
|
||||||
topology which will not cause systems to see the same messages
|
Conference Mail messages, and 2) It is important to have a
|
||||||
more than once.
|
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
|
Efficiency can be measured in a number of ways; least time
|
||||||
systems to receive a message, and fewest phone calls required for
|
involved for all systems to receive a message, least cost for all
|
||||||
all systems to receive a message are all valid indicators of
|
systems to receive a message, and fewest phone calls required for
|
||||||
efficiency. Users of Echomail compatible systems have determined
|
all systems to receive a message are all valid indicators of
|
||||||
(through trial and error) the best measure of efficiency is a
|
efficiency. Users of Echomail compatible systems have determined
|
||||||
combination of all three of the measurements given above.
|
(through trial and error) the best measure of efficiency is a
|
||||||
Balancing the equation is not trivial, but some guidelines can be
|
combination of all three of the measurements given above.
|
||||||
given:
|
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"
|
1. Never have two systems attempting to send Conference mail
|
||||||
that will cause both systems to fail. To avoid this, one
|
to each other at the same time. This results in "collisions"
|
||||||
system should be responsible for polling while the other
|
that will cause both systems to fail. To avoid this, one
|
||||||
system is holding mail. This arrangement can alternate based
|
system should be responsible for polling while the other
|
||||||
upon various criteria, but both systems should never be
|
system is holding mail. This arrangement can alternate based
|
||||||
attempting to call each other at the same time.
|
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
|
2. Have nodes form "stars" for distribution of Conference
|
||||||
Conference Mail from the same system. In general the systems
|
Mail. This arrangement has several nodes all receiving their
|
||||||
on the "outside" of the star poll the system on the
|
Conference Mail from the same system. In general the systems
|
||||||
"inside". The system on the "inside" in turn polls other
|
on the "outside" of the star poll the system on the
|
||||||
systems to receive the Conference Mail that is being passed
|
"inside". The system on the "inside" in turn polls other
|
||||||
on to the "outside" systems.
|
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
|
3. Utilize fully connected polygons with a few vertices.
|
||||||
sends to A and C, C sends to A and B) or a fully connected
|
Nodes can be connected in a triangle (A sends to B and C, B
|
||||||
square (all corners of the square send to all of the other
|
sends to A and C, C sends to A and B) or a fully connected
|
||||||
corners). This method is useful for getting Conference Mail
|
square (all corners of the square send to all of the other
|
||||||
messages to each node as quickly as possible.
|
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
|
All of these efficiency guidelines have to be tempered with the
|
||||||
exported. Duplicates will occur in any topology that forms a
|
guidelines dealing with keeping duplicate messages from being
|
||||||
closed polygon that is not fully connected. Take for example the
|
exported. Duplicates will occur in any topology that forms a
|
||||||
following configuration:
|
closed polygon that is not fully connected. Take for example the
|
||||||
|
following configuration:
|
||||||
A ----- B
|
|
||||||
| |
|
A ----- B
|
||||||
| |
|
| |
|
||||||
C ----- D
|
| |
|
||||||
|
C ----- D
|
||||||
This square is a closed polygon that is not fully connected. It
|
|
||||||
is capable of generating duplicates as follows:
|
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.
|
|
||||||
|
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.
|
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.
|
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.
|
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
|
At this point node D has received the same message twice - a
|
||||||
simple as a square. Generally it will be caused by a system on
|
duplicate was generated. Normally a "dup-ring" will not be as
|
||||||
one end of a long chain accidentally connecting to a system on
|
simple as a square. Generally it will be caused by a system on
|
||||||
the other end of the chain. This causes the two ends of the chain
|
one end of a long chain accidentally connecting to a system on
|
||||||
to become connected, forming a polygon.
|
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
|
In FidoNet this problem is reduced somewhat by having "Regional
|
||||||
connections within their regions of the world. A further rule
|
Echomail Coordinators" (RECS) that try to keep track of Echomail
|
||||||
which is followed is that only the RECS are allowed to make
|
connections within their regions of the world. A further rule
|
||||||
inter-regional connections for the larger conferences. In return,
|
which is followed is that only the RECS are allowed to make
|
||||||
the RECS have established a very efficient topology which gets
|
inter-regional connections for the larger conferences. In return,
|
||||||
messages from coast to coast, and onto over 200 systems in less
|
the RECS have established a very efficient topology which gets
|
||||||
than 24 hours. If no one were willing to follow the rules, then
|
messages from coast to coast, and onto over 200 systems in less
|
||||||
this system would collapse, but due to the excellent efficiency
|
than 24 hours. If no one were willing to follow the rules, then
|
||||||
it has remained intact for over a year.
|
this system would collapse, but due to the excellent efficiency
|
||||||
|
it has remained intact for over a year.
|
||||||
|
|
||||||
Why a PATH line?
|
|
||||||
|
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
|
As was previously mentioned, the PATH line is a new concept in
|
||||||
actually processed a message. This information is useful in
|
Echomail. It stores the net/node numbers of each system having
|
||||||
correcting the biggest problem encountered by nodes running an
|
actually processed a message. This information is useful in
|
||||||
Echomail compatible system - the problem of finding the cause of
|
correcting the biggest problem encountered by nodes running an
|
||||||
duplicate messages. How does the PATH line help solve this
|
Echomail compatible system - the problem of finding the cause of
|
||||||
problem? Take the following path line as an example:
|
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
|
|
||||||
|
^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
|
This shows the message was processed by system 107/6 and
|
||||||
transferred the message to 132/101, and 132/101 processed it
|
transferred to system 107/312. It further shows system 107/312
|
||||||
again. Now take the following path line as the example:
|
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
|
|
||||||
|
^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
|
This shows the message having been processed by node 107/312 on
|
||||||
'information control' fields in Echomail messages, this clearly
|
more than one occasion. Based upon the earlier description of the
|
||||||
is an error in processing (see the section entitled "How it
|
'information control' fields in Echomail messages, this clearly
|
||||||
Works"). This further shows node 107/528 as the node which
|
is an error in processing (see the section entitled "How it
|
||||||
apparently processed the message incorrectly. In this case the
|
Works"). This further shows node 107/528 as the node which
|
||||||
path line can be used to quickly locate the source of duplicate
|
apparently processed the message incorrectly. In this case the
|
||||||
messages.
|
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
|
In a conference with many participants it becomes almost
|
||||||
the use of the path line can help a coordinator of the conference
|
impossible to determine the exact topology used. In these cases
|
||||||
track any possible breakdowns in the overall topology, while not
|
the use of the path line can help a coordinator of the conference
|
||||||
substantially increasing the amount of information transmitted.
|
track any possible breakdowns in the overall topology, while not
|
||||||
Having this small amount of information added to the end of each
|
substantially increasing the amount of information transmitted.
|
||||||
message pays for itself very quickly when it can be used to help
|
Having this small amount of information added to the end of each
|
||||||
detect a topology problem causing duplicate messages to be
|
message pays for itself very quickly when it can be used to help
|
||||||
transmitted to each system.
|
detect a topology problem causing duplicate messages to be
|
||||||
|
transmitted to each system.
|
||||||
-30-
|
|
||||||
</PRE>
|
-30-
|
||||||
|
</PRE>
|
||||||
<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>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -1,485 +1,491 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>Bark file-request protocol extension.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>Bark file-request protocol extension.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
Document: FTS-0008
|
<PRE>
|
||||||
Version: 003
|
Document: FTS-0008
|
||||||
Date: 15-Oct-1990
|
Version: 003
|
||||||
Updates: FTS-0001
|
Date: 15-Oct-1990
|
||||||
|
Updates: FTS-0001
|
||||||
|
|
||||||
|
|
||||||
An Enhanced FidoNet(r) Technical Standard
|
|
||||||
Extending FTS-0001 to include Bark requests
|
An Enhanced FidoNet(r) Technical Standard
|
||||||
|
Extending FTS-0001 to include Bark requests
|
||||||
October 15, 1990
|
|
||||||
|
October 15, 1990
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Status of this document:
|
|
||||||
|
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,
|
This document specifies an optional standard for the FidoNet community.
|
||||||
but all implementations of these protocols are expected to adhere to this
|
Implementation of the protocols defined in this document is not mandatory,
|
||||||
standard. Distribution of this document is subject to the limitations of
|
but all implementations of these protocols are expected to adhere to this
|
||||||
the copyright notice displayed below.
|
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.
|
Copyright 1989-90 by Philip L. Becker. Portions of this document are
|
||||||
All rights reserved. A right to distribute only without modification and
|
copyright 1986-90 by Randy Bush and are incorporated with his consent.
|
||||||
only at no charge is granted. Under no circumstances is this document to
|
All rights reserved. A right to distribute only without modification and
|
||||||
be reproduced or distributed as part of or packaged with any product or
|
only at no charge is granted. Under no circumstances is this document to
|
||||||
other sales transaction for which any fee is charged. Any and all other
|
be reproduced or distributed as part of or packaged with any product or
|
||||||
reproduction or excerpting requires the explicit written consent of the
|
other sales transaction for which any fee is charged. Any and all other
|
||||||
copyright holders.
|
reproduction or excerpting requires the explicit written consent of the
|
||||||
|
copyright holders.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
A. Introduction
|
|
||||||
|
A. Introduction
|
||||||
1. This Document
|
|
||||||
|
1. This Document
|
||||||
This document describes the standard for "Bark" type FidoNet file
|
|
||||||
request operation. Bark file requests are an extension to the basic
|
This document describes the standard for "Bark" type FidoNet file
|
||||||
FTS-0001 mail session, and this document presents these requests as a
|
request operation. Bark file requests are an extension to the basic
|
||||||
modification to that document.
|
FTS-0001 mail session, and this document presents these requests as a
|
||||||
|
modification to that document.
|
||||||
2. What are File Requests?
|
|
||||||
|
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
|
File Requests are a way of requesting that a specific file be sent during
|
||||||
a BBS and downloading a file:
|
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 need not be a validated user
|
||||||
o You don't have to spend time searching for the file on the BBS
|
|
||||||
|
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.
|
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
|
There are two commonly used types of file requests on FidoNet today, WaZOO
|
||||||
are not documented here. See the document FTS-0006 by V. Perriello for a
|
and Bark requests. WaZOO requests are used by Opus and BinkleyTerm, and
|
||||||
description of these. Bark requests were the first file request extension
|
are not documented here. See the document FTS-0006 by V. Perriello for a
|
||||||
to the FTS-0001 protocol, and are supported (at least partially) by many
|
description of these. Bark requests were the first file request extension
|
||||||
mailers, including SEAdog, Dutchie, BinkleyTerm, and to a certain extent
|
to the FTS-0001 protocol, and are supported (at least partially) by many
|
||||||
Opus. This document describes how to implement Bark-type file requests.
|
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
|
|
||||||
|
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.
|
1. The diagrams and notations used in this document are the same as those used
|
||||||
This document should be considered as an extension to the FTS-0001 session
|
in the FTS-0001 document. Please see FTS-0001 for a description of these.
|
||||||
layer protocol, and you will require FTS-0001 in addition to this document
|
This document should be considered as an extension to the FTS-0001 session
|
||||||
to fully understand what is presented here.
|
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:
|
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
|
(* terminals *)
|
||||||
C. Performing File Requests
|
someName<max> - String of up to max chars, NOT null terminated
|
||||||
|
|
||||||
1. Introduction
|
|
||||||
|
C. Performing File Requests
|
||||||
A Bark request consists of transmitting a special Bark Request packet which
|
|
||||||
contains a filename, a date (used for update requests), and optionally a
|
1. Introduction
|
||||||
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
|
A Bark request consists of transmitting a special Bark Request packet which
|
||||||
to send attached files. Bark request handling is always controlled by the
|
contains a filename, a date (used for update requests), and optionally a
|
||||||
answering system, and consists of two phases. In phase one, the receiving
|
password. The system receiving the request then decides if it can send the
|
||||||
system asks the calling system to honor requests it may have to ask for
|
requested file or not, and if it can does so using the same protocol used
|
||||||
files from the caller. In phase two, the receiving system allows the
|
to send attached files. Bark request handling is always controlled by the
|
||||||
calling system to request files from it.
|
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
|
||||||
Update file requests are the same as normal file requests, with one
|
files from the caller. In phase two, the receiving system allows the
|
||||||
exception. If the date in the Bark Request packet (described below) is
|
calling system to request files from it.
|
||||||
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
|
Update file requests are the same as normal file requests, with one
|
||||||
the actual file on its own end if an update request is desired.
|
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
|
||||||
D. The Bark Request Packet
|
the actual file on its own end if an update request is desired.
|
||||||
|
|
||||||
1. Data Link Layer Data Definition.
|
|
||||||
|
D. The Bark Request Packet
|
||||||
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
|
1. Data Link Layer Data Definition.
|
||||||
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
|
The Bark Request packet is a variable-sized packet containing a header, a
|
||||||
that the CRC is sent in the reverse byte order of a normal CRC XMODEM data
|
filename, a date (which is used only for update requests - in a normal file
|
||||||
block (see FTS-0001 section G.1).
|
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
|
||||||
Note: some systems will send a password in the data block even if none is
|
that the CRC is sent in the reverse byte order of a normal CRC XMODEM data
|
||||||
needed. Incoming passwords should be ignored unless the other system is
|
block (see FTS-0001 section G.1).
|
||||||
trying to request a passworded file.
|
|
||||||
|
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
|
|
||||||
.-----------------------------------------------.
|
Bark File Request Packet
|
||||||
0 0 | ACK - Start of Bark Request - 06H |
|
Offset
|
||||||
+-----------------------------------------------+
|
dec hex
|
||||||
1 1 | Filename - Packed DOS file format |
|
.-----------------------------------------------.
|
||||||
+-----------------------------------------------+
|
0 0 | ACK - Start of Bark Request - 06H |
|
||||||
n n | SPACE - 20H |
|
+-----------------------------------------------+
|
||||||
+-----------------------------------------------+
|
1 1 | Filename - Packed DOS file format |
|
||||||
n n | Date (0 if not Update Request) |
|
+-----------------------------------------------+
|
||||||
+-----------------------------------------------+
|
n n | SPACE - 20H |
|
||||||
n n | SPACE - 20H (only if pswd follows) |
|
+-----------------------------------------------+
|
||||||
+-----------------------------------------------+
|
n n | Date (0 if not Update Request) |
|
||||||
n n | Password (optional) |
|
+-----------------------------------------------+
|
||||||
+-----------------------------------------------+
|
n n | SPACE - 20H (only if pswd follows) |
|
||||||
n n | ETX - End of RESYNC packet - 03H |
|
+-----------------------------------------------+
|
||||||
+-----------------------------------------------+
|
n n | Password (optional) |
|
||||||
n n | (*1) CRC low order byte |
|
+-----------------------------------------------+
|
||||||
+-----------------------------------------------+
|
n n | ETX - End of RESYNC packet - 03H |
|
||||||
n n | (*1) CRC high order byte |
|
+-----------------------------------------------+
|
||||||
`-----------------------------------------------'
|
n n | (*1) CRC low order byte |
|
||||||
|
+-----------------------------------------------+
|
||||||
*1 - CRC does not include the ACK or ETX and is
|
n n | (*1) CRC high order byte |
|
||||||
in the reverse byte order from the CRC in a
|
`-----------------------------------------------'
|
||||||
normal XMODEM data packet.
|
|
||||||
2. Data Description Notation of Bark Request Packet
|
*1 - CRC does not include the ACK or ETX and is
|
||||||
|
in the reverse byte order from the CRC in a
|
||||||
DataBlock (no password) = ACK
|
normal XMODEM data packet.
|
||||||
Filename<12>
|
|
||||||
Space
|
2. Data Description Notation of Bark Request Packet
|
||||||
Date<11>
|
|
||||||
ETX
|
DataBlock (no password) = ACK
|
||||||
CRC
|
Filename<12>
|
||||||
|
Space
|
||||||
DataBlock (with password) = ACK
|
Date<11>
|
||||||
Filename<12>
|
ETX
|
||||||
Space
|
CRC
|
||||||
Date<11>
|
|
||||||
Space
|
DataBlock (with password) = ACK
|
||||||
Password<6|8>
|
Filename<12>
|
||||||
ETX
|
Space
|
||||||
CRC
|
Date<11>
|
||||||
|
Space
|
||||||
ACK = 06H (* Header for file request block *)
|
Password<6|8>
|
||||||
Space = 20H (* Space character *)
|
ETX
|
||||||
ETX = 03H (* End of block *)
|
CRC
|
||||||
|
|
||||||
Filename (* Name of file requested *)
|
ACK = 06H (* Header for file request block *)
|
||||||
Date (* ASCII string; the number of seconds
|
Space = 20H (* Space character *)
|
||||||
since midnight, January 1, 1970 *)
|
ETX = 03H (* End of block *)
|
||||||
Password (* The password needed to request this
|
|
||||||
file, if any. Maximum length is 6 for
|
Filename (* Name of file requested *)
|
||||||
BinkleyTerm and Opus, 8 for SEAdog
|
Date (* ASCII string; the number of seconds
|
||||||
and Dutchie. *)
|
since midnight, January 1, 1970 *)
|
||||||
|
Password (* The password needed to request this
|
||||||
CRC = crc[2] (* CCITT Cyclic Redundancy Check. The
|
file, if any. Maximum length is 6 for
|
||||||
same algorithm as used for XModem
|
BinkleyTerm and Opus, 8 for SEAdog
|
||||||
CRCs. The CRC is calculated on
|
and Dutchie. *)
|
||||||
all data in the block between but
|
|
||||||
not including the ACK and the ETX *)
|
CRC = crc[2] (* CCITT Cyclic Redundancy Check. The
|
||||||
E. Session Layer Protocol:
|
same algorithm as used for XModem
|
||||||
|
CRCs. The CRC is calculated on
|
||||||
This section describes the modified FTS-0001 session layer protocol. This
|
all data in the block between but
|
||||||
is the only area of FTS-0001 which is modified to implement Bark style file
|
not including the ACK and the ETX *)
|
||||||
requests. File Requests are performed at the end of the normal FidoNet
|
|
||||||
mail session, after any mail pickup is performed.
|
E. Session Layer Protocol:
|
||||||
|
|
||||||
The diagrams below desribe the session level protocol with Bark file
|
This section describes the modified FTS-0001 session layer protocol. This
|
||||||
requests implemented. The state tables have been broken into subroutines
|
is the only area of FTS-0001 which is modified to implement Bark style file
|
||||||
but the FTS-0001 portion is not functionally changed. FTS-0001 sender
|
requests. File Requests are performed at the end of the normal FidoNet
|
||||||
states S4 through S7 are now table "Send Mail SM0". FTS-0001 receiver
|
mail session, after any mail pickup is performed.
|
||||||
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
|
The diagrams below desribe the session level protocol with Bark file
|
||||||
to allow them to be used as subroutines. Finally Sender states S0 through
|
requests implemented. The state tables have been broken into subroutines
|
||||||
S3 are unchanged, as are Receiver states R0 through R2.
|
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
|
||||||
The remaining FTS-0001 states are enhanced to implement the Bark file
|
states R3 through R6 are now table "Receive Mail RM0". They are not
|
||||||
request protocol. In addition, the subroutine state tables "Send Bark SB0"
|
functionally changed in any way from FTS-0001, they are just broken out
|
||||||
and "Receive Bark RB0" have been added to handle the actual file requests.
|
to allow them to be used as subroutines. Finally Sender states S0 through
|
||||||
|
S3 are unchanged, as are Receiver states R0 through R2.
|
||||||
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 remaining FTS-0001 states are enhanced to implement the Bark file
|
||||||
the Bark File request feature.
|
request protocol. In addition, the subroutine state tables "Send Bark SB0"
|
||||||
Sender (Top level)
|
and "Receive Bark RB0" have been added to handle the actual file requests.
|
||||||
|
|
||||||
.-----+----------+-------------------------+-------------------------+-----.
|
The following diagrams fully replace the Session Layer protocol state
|
||||||
|State| State | Predicate(s) | Action(s) | Next|
|
tables in FTS-0001. No other changes to FTS-0001 are required to implement
|
||||||
| # | Name | | | St |
|
the Bark File request feature.
|
||||||
+-----+----------+-------------------------+-------------------------+-----+
|
|
||||||
| S0 | SendInit | | dial modem | S1 |
|
Sender (Top level)
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
|
||||||
| S1 | WaitCxD |1| carrier detected | delay 1-5 seconds | S2 |
|
.-----+----------+-------------------------+-------------------------+-----.
|
||||||
| | (*1) | | | Set SLO if > 2400bps, | |
|
|State| State | Predicate(s) | Action(s) | Next|
|
||||||
| | | | | Reset SLO if <= 2400bps | |
|
| # | Name | | | St |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
+-----+----------+-------------------------+-------------------------+-----+
|
||||||
| | |2| busy, etc. | report no connection | exit|
|
| S0 | SendInit | | dial modem | S1 |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
| | |3| voice | report no carrier | exit|
|
| S1 | WaitCxD |1| carrier detected | delay 1-5 seconds | S2 |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | (*1) | | | Set SLO if > 2400bps, | |
|
||||||
| | |4| carrier not detected | report no connection | exit|
|
| | | | | Reset SLO if <= 2400bps | |
|
||||||
| | | | within 60 seconds | | |
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
| | |2| busy, etc. | report no connection | exit|
|
||||||
| S2 | WhackCRs |1| over 30 seconds | report no response <cr> | exit|
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | |3| voice | report no carrier | exit|
|
||||||
| | |2| ?? <cr>s received | delay 1 sec | S3 |
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | |4| carrier not detected | report no connection | exit|
|
||||||
| | |3| <cr>s not received | send <cr> <sp> <cr> <sp>| S2 |
|
| | | | within 60 seconds | | |
|
||||||
| | | | | delay ??? secs | |
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
| S2 | WhackCRs |1| over 30 seconds | report no response <cr> | exit|
|
||||||
| S3 | WaitClear|1| no input for 0.5 secs | send TSYNCH = AEH | S4 |
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | |2| ?? <cr>s received | delay 1 sec | S3 |
|
||||||
| | |2| over 60 seconds | hang up, report garbage | exit|
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | | | and line not clear | | |
|
| | |3| <cr>s not received | send <cr> <sp> <cr> <sp>| S2 |
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
| | | | | delay ??? secs | |
|
||||||
| S4 | SendMail | | (Send Mail SM0) | S5 |
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
| S3 | WaitClear|1| no input for 0.5 secs | send TSYNCH = AEH | S4 |
|
||||||
| S5 | TryPickup|1| Rcv TSYNC | (Receive Mail RM0) | S5 |
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | (*2) +-+-----------------------+-------------------------+-----+
|
| | |2| over 60 seconds | hang up, report garbage | exit|
|
||||||
| | |2| Rcv SYN | (Receive Bark Req RB0) | S5 |
|
| | | | and line not clear | | |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
| | |3| Rcv ENQ | (Do Bark Requests SB0) | S5 |
|
| S4 | SendMail | | (Send Mail SM0) | S5 |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
| | |4| Rcv 'C' or NAK | Send EOT | S5 |
|
| S5 | TryPickup|1| Rcv TSYNC | (Receive Mail RM0) | S5 |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | (*2) +-+-----------------------+-------------------------+-----+
|
||||||
| | |5| Rcv Other Char | Send SUB | S5 |
|
| | |2| Rcv SYN | (Receive Bark Req RB0) | S5 |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | |6| No Data for 45 secs | Hang Up | exit|
|
| | |3| Rcv ENQ | (Do Bark Requests SB0) | S5 |
|
||||||
`-----+----------+-+-----------------------+-------------------------+-----'
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
|
| | |4| Rcv 'C' or NAK | Send EOT | S5 |
|
||||||
*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
|
| | |5| Rcv Other Char | Send SUB | S5 |
|
||||||
implementation, or if not implementing overdrive in SEAdog.
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
|
| | |6| No Data for 45 secs | Hang Up | exit|
|
||||||
*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
|
*1 - This state is shown for the extended SEAlink protocol. Omit the
|
||||||
recommended that a timeout of 5-20 seconds should initiate another TSYNCH.
|
set/reset SLO actions if adding Bark to a strict FTS-0001 protocol
|
||||||
The receiver should tolerate multiple TSYNCHs.
|
implementation, or if not implementing overdrive in SEAdog.
|
||||||
Receiver (Top Level)
|
|
||||||
|
*2 - To refuse to pickup mail (S5.1) may send a CAN and stay in (S5).
|
||||||
The receiving FSM is given an external timer, the expiration of which
|
|
||||||
will cause termination with a result of 'no calls' (R0.2).
|
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.
|
||||||
|State| State | Predicate(s) | Action(s) | Next|
|
The receiver should tolerate multiple TSYNCHs.
|
||||||
| # | Name | | | St |
|
Receiver (Top Level)
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
|
||||||
| R0 | WaitCxD |1| carrier detected | | R1 |
|
The receiving FSM is given an external timer, the expiration of which
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
will cause termination with a result of 'no calls' (R0.2).
|
||||||
| | |2| external timer expires| report no calls | exit|
|
.-----+----------+-------------------------+-------------------------+-----.
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
|State| State | Predicate(s) | Action(s) | Next|
|
||||||
| R1 | WaitBaud |1| baud rate detected | send signon with <cr>s | R2 |
|
| # | Name | | | St |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
| | |2| no detect in ?? secs | hang up, report no baud | exit|
|
| R0 | WaitCxD |1| carrier detected | | R1 |
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| R2 | WaitTsync|1| TSYNCH received | ignore input not TSYNCH | R3 |
|
| | |2| external timer expires| report no calls | exit|
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
| | |2| 60 seconds timeout | hang up, report not Fido| exit|
|
| R1 | WaitBaud |1| baud rate detected | send signon with <cr>s | R2 |
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| R3 | RecMail | | (Receive Mail RM0) | R4 |
|
| | |2| no detect in ?? secs | hang up, report no baud | exit|
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
| R4 | AllowPkup|1| Have pickup for sender| Send Tsync, | R5 |
|
| R2 | WaitTsync|1| TSYNCH received | ignore input not TSYNCH | R3 |
|
||||||
| | | | | Set T1=1 sec | |
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | |2| 60 seconds timeout | hang up, report not Fido| exit|
|
||||||
| | |2| No pickup for sender | | R6 |
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
| R3 | RecMail | | (Receive Mail RM0) | R4 |
|
||||||
| R5 | WtPickup |1| Rcv NAK or 'C' | (Send Mail SM0) | R6 |
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| R4 | AllowPkup|1| Have pickup for sender| Send Tsync, | R5 |
|
||||||
| | |2| Rcv SUB | Send Tsync, | R5 |
|
| | | | | Set T1=1 sec | |
|
||||||
| | | | | Set T1=1 sec | |
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | |2| No pickup for sender | | R6 |
|
||||||
| | |3| Rcv CAN | Report Mail Refused | R6 |
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| R5 | WtPickup |1| Rcv NAK or 'C' | (Send Mail SM0) | R6 |
|
||||||
| | |4| T1 expired | Send Tsync, | R5 |
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | | | | Set T1=1 sec | |
|
| | |2| Rcv SUB | Send Tsync, | R5 |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | | | | Set T1=1 sec | |
|
||||||
| | |5| 45 secs in R5 | Hang Up, report error | exit|
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
| | |3| Rcv CAN | Report Mail Refused | R6 |
|
||||||
| R6 | AskBark |1| Wish to make requests | Send SYN | R7 |
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | (*1) +-+-----------------------+-------------------------+-----+
|
| | |4| T1 expired | Send Tsync, | R5 |
|
||||||
| | |2| No requests to make | | R8 |
|
| | | | | Set T1=1 sec | |
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| R7 | DoRequest|1| Rcv CAN | Report Requests Refused | R8 |
|
| | |5| 45 secs in R5 | Hang Up, report error | exit|
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
| | |2| Rcv ENQ | (Send Bark SB0) | R8 |
|
| R6 | AskBark |1| Wish to make requests | Send SYN | R7 |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | (*1) +-+-----------------------+-------------------------+-----+
|
||||||
| | |3| Rcv SUB | Send SYN | R7 |
|
| | |2| No requests to make | | R8 |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
| | |4| Rcv NAK or 'C' | Send EOT | R6 |
|
| R7 | DoRequest|1| Rcv CAN | Report Requests Refused | R8 |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | |5| Rcv Other | eat character | R7 |
|
| | |2| Rcv ENQ | (Send Bark SB0) | R8 |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | |6| 5 sec, no input | Send SYN | R7 |
|
| | |3| Rcv SUB | Send SYN | R7 |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | |7| 45 secs in R7 | | R8 |
|
| | |4| Rcv NAK or 'C' | Send EOT | R6 |
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| R8 | WtPickup |1| Allow File Request | (Receive Bark RB0), | exit|
|
| | |5| Rcv Other | eat character | R7 |
|
||||||
| | | | | Hang Up | |
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | |6| 5 sec, no input | Send SYN | R7 |
|
||||||
| | |2| Disallow Requests | Hang Up | exit|
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
`-----+----------+-+-----------------------+-------------------------+-----'
|
| | |7| 45 secs in R7 | | R8 |
|
||||||
*1 - Some implementations always do (R6.1) even if they have no requests.
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
Sender - Send Mail
|
| R8 | WtPickup |1| Allow File Request | (Receive Bark RB0), | exit|
|
||||||
|
| | | | | Hang Up | |
|
||||||
.-----+----------+-------------------------+-------------------------+-----.
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
|State| State | Predicate(s) | Action(s) | Next|
|
| | |2| Disallow Requests | Hang Up | exit|
|
||||||
| # | Name | | | St |
|
`-----+----------+-+-----------------------+-------------------------+-----'
|
||||||
+-----+----------+-------------------------+-------------------------+-----+
|
*1 - Some implementations always do (R6.1) even if they have no requests.
|
||||||
| SM0 | SendMail | | (XMODEM send packet XS0)| SM1 |
|
Sender - Send Mail
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
|
||||||
| SM1 | CheckMail|1| XMODEM successful | (Fido registers success)| SM2 |
|
.-----+----------+-------------------------+-------------------------+-----.
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
|State| State | Predicate(s) | Action(s) | Next|
|
||||||
| | |2| XMODEM fail or timeout| hang up, report mail bad| exit|
|
| # | Name | | | St |
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
+-----+----------+-------------------------+-------------------------+-----+
|
||||||
| SM2 | SendFiles| | (BATCH send files BS0) | SM3 |
|
| SM0 | SendMail | | (XMODEM send packet XS0)| SM1 |
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
| SM3 | CheckFile|1| BATCH send successful | report success | exit|
|
| SM1 | CheckMail|1| XMODEM successful | (Fido registers success)| SM2 |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | |2| BATCH send failed | hang up, rept files fail| exit|
|
| | |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|
|
||||||
Sender - Send Bark
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
|
| | |2| BATCH send failed | hang up, rept files fail| exit|
|
||||||
.-----+----------+-------------------------+-------------------------+-----.
|
`-----+----------+-+-----------------------+-------------------------+-----'
|
||||||
|State| State | Predicate(s) | Action(s) | Next|
|
|
||||||
| # | Name | | | St |
|
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
|
||||||
| SB0 | SendBark |1| File to request | Build Bark Request Pkt, | SB1 |
|
Sender - Send Bark
|
||||||
| | | | | Set tries = 0 | |
|
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
.-----+----------+-------------------------+-------------------------+-----.
|
||||||
| | |2| No more files to req | Send ETB | exit|
|
|State| State | Predicate(s) | Action(s) | Next|
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
| # | Name | | | St |
|
||||||
| SB1 | AskFile | | Send Bark Packet | SB2 |
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
| SB0 | SendBark |1| File to request | Build Bark Request Pkt, | SB1 |
|
||||||
| SB2 | RcvFile |1| Rcv ACK | (Batch Receive BR0) | SB3 |
|
| | | | | Set tries = 0 | |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | |2| Tries > 5 | Send ETB, report failed | exit|
|
| | |2| No more files to req | Send ETB | exit|
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
| | |3| Rcv Other | Purge input, Incr tries | SB1 |
|
| SB1 | AskFile | | Send Bark Packet | SB2 |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
| | |4| 10 sec w/o ACK | Incr tries | SB1 |
|
| SB2 | RcvFile |1| Rcv ACK | (Batch Receive BR0) | SB3 |
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| SB3 | NxtFile |1| Rcv ENQ | | SB0 |
|
| | |2| Tries > 5 | Send ETB, report failed | exit|
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | |2| Rcv Other | Purge Input | SB3 |
|
| | |3| Rcv Other | Purge input, Incr tries | SB1 |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | |3| 5 sec, no input | Send SUB | SB3 |
|
| | |4| 10 sec w/o ACK | Incr tries | SB1 |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
| | |4| 45 sec in SB3 | Hang up, report error | exit|
|
| SB3 | NxtFile |1| Rcv ENQ | | SB0 |
|
||||||
`-----+----------+-+-----------------------+-------------------------+-----'
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
Sender & Receiver - Receive Mail
|
| | |2| Rcv Other | Purge Input | SB3 |
|
||||||
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
.-----+----------+-------------------------+-------------------------+-----.
|
| | |3| 5 sec, no input | Send SUB | SB3 |
|
||||||
|State| State | Predicate(s) | Action(s) | Next|
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| # | Name | | | St |
|
| | |4| 45 sec in SB3 | Hang up, report error | exit|
|
||||||
+-----+----------+-------------------------+-------------------------+-----+
|
`-----+----------+-+-----------------------+-------------------------+-----'
|
||||||
| RM0 | RecMail | | (XMODEM rec packet XR0) | RM1 |
|
Sender & Receiver - Receive Mail
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
|
||||||
| RM1 | XRecEnd |1| XMODEM successful | delay 1 second | RM2 |
|
.-----+----------+-------------------------+-------------------------+-----.
|
||||||
| | | | | flush input | |
|
|State| State | Predicate(s) | Action(s) | Next|
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| # | Name | | | St |
|
||||||
| | |2| XMODEM failed | hang up, rept mail fail | exit|
|
+-----+----------+-------------------------+-------------------------+-----+
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
| RM0 | RecMail | | (XMODEM rec packet XR0) | RM1 |
|
||||||
| RM2 | RecFiles | | (BATCH rec files BR0) | RM3 |
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
| RM1 | XRecEnd |1| XMODEM successful | delay 1 second | RM2 |
|
||||||
| RM3 | ChkFiles |1| BATCH recv successful | delay 2 secs, rprt good | exit|
|
| | | | | flush input | |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | |2| BATCH recv failed | hang up, report bad file| exit|
|
| | |2| XMODEM failed | hang up, rept mail fail | exit|
|
||||||
`-----+----------+-+-----------------------+-------------------------+-----'
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
|
| RM2 | RecFiles | | (BATCH rec files BR0) | RM3 |
|
||||||
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
Sender & Receiver - Receive Bark
|
| RM3 | ChkFiles |1| BATCH recv successful | delay 2 secs, rprt good | exit|
|
||||||
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
.-----+----------+-------------------------+-------------------------+-----.
|
| | |2| BATCH recv failed | hang up, report bad file| exit|
|
||||||
|State| State | Predicate(s) | Action(s) | Next|
|
`-----+----------+-+-----------------------+-------------------------+-----'
|
||||||
| # | Name | | | St |
|
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
|
||||||
| RB0 | HonorReq |1| Ok to honor request | Purge Input, Send ENQ, | RB1 |
|
Sender & Receiver - Receive Bark
|
||||||
| | | | | Set T1 = 2 seconds | |
|
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
.-----+----------+-------------------------+-------------------------+-----.
|
||||||
| | |2| Don't wish to honor | Send CAN | exit|
|
|State| State | Predicate(s) | Action(s) | Next|
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
| # | Name | | | St |
|
||||||
| RB1 | WaitBark |1| Got ACK | Rcv Bark Packet (*1) | RB2 |
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| RB0 | HonorReq |1| Ok to honor request | Purge Input, Send ENQ, | RB1 |
|
||||||
| | |2| Got ETB | Report done | exit|
|
| | | | | Set T1 = 2 seconds | |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | |3| Got ENQ | Send ETB | RB0 |
|
| | |2| Don't wish to honor | Send CAN | exit|
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
| | |4| T1 expired | Purge Input, Send ENQ, | RB1 |
|
| RB1 | WaitBark |1| Got ACK | Rcv Bark Packet (*1) | RB2 |
|
||||||
| | | | | Set T1 = 2 seconds | |
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | |2| Got ETB | Report done | exit|
|
||||||
| | |5| 20 seconds in RB1 | Hang Up, Report error | exit|
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
| | |3| Got ENQ | Send ETB | RB0 |
|
||||||
| RB2 | AckBark |1| Bark Pkt Rcvd Good | Send ACK | RB3 |
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | |4| T1 expired | Purge Input, Send ENQ, | RB1 |
|
||||||
| | |2| Bark Pkt Rcv Error | Send NAK | RB1 |
|
| | | | | Set T1 = 2 seconds | |
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| RB3 | WaitStrt |1| Got 'C' or NAK | | RB4 |
|
| | |5| 20 seconds in RB1 | Hang Up, Report error | exit|
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
| | |2| No data for 3 seconds | Send ACK | RB3 |
|
| RB2 | AckBark |1| Bark Pkt Rcvd Good | Send ACK | RB3 |
|
||||||
| | +-+-----------------------+-------------------------+-----+
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | |3| 15 seconds in RB3 | Hang Up, Report Error | exit|
|
| | |2| Bark Pkt Rcv Error | Send NAK | RB1 |
|
||||||
+-----+----------+-+-----------------------+-------------------------+-----+
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
| RB4 | SendFile |1| Can snd requested file| (Batch Send File BS0) | RB0 |
|
| RB3 | WaitStrt |1| Got 'C' or NAK | | RB4 |
|
||||||
| | (*2) +-+-----------------------+-------------------------+-----+
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
| | |2| Can't send file | Send EOT | RB0 |
|
| | |2| No data for 3 seconds | Send ACK | RB3 |
|
||||||
`-----+----------+-+-----------------------+-------------------------+-----'
|
| | +-+-----------------------+-------------------------+-----+
|
||||||
*1 - If SUB (16H) received before ETX go to RB0 to resync bark receive
|
| | |3| 15 seconds in RB3 | Hang Up, Report Error | exit|
|
||||||
|
+-----+----------+-+-----------------------+-------------------------+-----+
|
||||||
*2 - While deciding if file exists, and if the password allows it to be
|
| RB4 | SendFile |1| Can snd requested file| (Batch Send File BS0) | RB0 |
|
||||||
sent etc., a NUL may be sent to buy 20 seconds more on the timeout
|
| | (*2) +-+-----------------------+-------------------------+-----+
|
||||||
on the other end if it is using the SEAlink extended FTS-0001
|
| | |2| Can't send file | Send EOT | RB0 |
|
||||||
specification protocol. Sending a NUL is harmless for a strict
|
`-----+----------+-+-----------------------+-------------------------+-----'
|
||||||
FTS-0001 session, but will not buy more time.
|
*1 - If SUB (16H) received before ETX go to RB0 to resync bark receive
|
||||||
</PRE>
|
|
||||||
|
*2 - While deciding if file exists, and if the password allows it to be
|
||||||
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
|
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
|
||||||
</BODY>
|
specification protocol. Sending a NUL is harmless for a strict
|
||||||
</HTML>
|
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>
|
||||||
|
|
||||||
|
|||||||
@ -1,104 +1,105 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>Message identification and reply linkage.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>Message identification and reply linkage.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
Document: FTS-0009
|
<PRE>
|
||||||
Version: 001
|
Document: FTS-0009
|
||||||
Date: 17-Dec-91
|
Version: 001
|
||||||
|
Date: 17-Dec-91
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
MSGID / REPLY
|
|
||||||
A standard for unique message identifiers
|
MSGID / REPLY
|
||||||
and reply chain linkage
|
A standard for unique message identifiers
|
||||||
|
and reply chain linkage
|
||||||
17 December, 1991
|
|
||||||
|
17 December, 1991
|
||||||
jim nutt
|
|
||||||
1:114/30@fidonet
|
jim nutt
|
||||||
|
1:114/30@fidonet
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Status of this document:
|
|
||||||
|
Status of this document:
|
||||||
This FTS (FidoNet(r) Technical Standard) specifies an optional
|
|
||||||
standard for the FidoNet community. Implementation of the
|
This FTS (FidoNet(r) Technical Standard) specifies an optional
|
||||||
protocols defined in this document is not mandatory, but all
|
standard for the FidoNet community. Implementation of the
|
||||||
implementations of these protocols are expected to adhere to this
|
protocols defined in this document is not mandatory, but all
|
||||||
standard. Distribution of this document is unlimited.
|
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.
|
Fido and FidoNet are registered marks of Tom Jennings and Fido
|
||||||
|
Software.
|
||||||
|
|
||||||
MSGID
|
|
||||||
|
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
|
A MSGID line consists of the string "^AMSGID:" (where ^A is a
|
||||||
string), followed by a space, the address of the originating
|
control-A (hex 01) and the double-quotes are not part of the
|
||||||
system, and a serial number unique to that message on the
|
string), followed by a space, the address of the originating
|
||||||
originating system, i.e.:
|
system, and a serial number unique to that message on the
|
||||||
|
originating system, i.e.:
|
||||||
^AMSGID: origaddr serialno
|
|
||||||
|
^AMSGID: origaddr serialno
|
||||||
The originating address should be specified in a form that
|
|
||||||
constitutes a valid return address for the originating network.
|
The originating address should be specified in a form that
|
||||||
If the originating address is enclosed in double-quotes, the
|
constitutes a valid return address for the originating network.
|
||||||
entire string between the beginning and ending double-quotes is
|
If the originating address is enclosed in double-quotes, the
|
||||||
considered to be the orginating address. A double-quote character
|
entire string between the beginning and ending double-quotes is
|
||||||
within a quoted address is represented by by two consecutive
|
considered to be the orginating address. A double-quote character
|
||||||
double-quote characters. The serial number may be any eight
|
within a quoted address is represented by by two consecutive
|
||||||
character hexadecimal number, as long as it is unique - no two
|
double-quote characters. The serial number may be any eight
|
||||||
messages from a given system may have the same serial number
|
character hexadecimal number, as long as it is unique - no two
|
||||||
within a three years. The manner in which this serial number is
|
messages from a given system may have the same serial number
|
||||||
generated is left to the implementor.
|
within a three years. The manner in which this serial number is
|
||||||
|
generated is left to the implementor.
|
||||||
|
|
||||||
REPLY
|
|
||||||
|
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
|
A REPLY line consists of the string "^AREPLY:" (where ^A is a
|
||||||
string), followed by a space, and the origaddr and serialno
|
control-A (hex 01) and the double-quotes are not part of the
|
||||||
fields of the MSGID line of the message to which this message is a
|
string), followed by a space, and the origaddr and serialno
|
||||||
reply, i.e.:
|
fields of the MSGID line of the message to which this message is a
|
||||||
|
reply, i.e.:
|
||||||
^AREPLY: origaddr serialno
|
|
||||||
|
^AREPLY: origaddr serialno
|
||||||
The origaddr and serialno fields must be identical to the
|
|
||||||
corresponding fields in the MSGID of the message to which this
|
The origaddr and serialno fields must be identical to the
|
||||||
message is a reply. A REPLY line is never generated in a
|
corresponding fields in the MSGID of the message to which this
|
||||||
message that is a reply to a message that does not contain a
|
message is a reply. A REPLY line is never generated in a
|
||||||
MSGID line.
|
message that is a reply to a message that does not contain a
|
||||||
|
MSGID line.
|
||||||
|
|
||||||
GENERAL
|
|
||||||
|
GENERAL
|
||||||
MSGID and REPLY lines should be placed before the text body of the
|
|
||||||
message in which they appear.
|
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
|
Finally, a MSGID is generated only at the time of message
|
||||||
from a message passing through an intermediate system. No system
|
creation. An existing MSGID and/or REPLY should never be stripped
|
||||||
should ever add an MSGID and/or REPLY to, or modify an existing
|
from a message passing through an intermediate system. No system
|
||||||
MSGID / REPLY contained in, a message not originating on that
|
should ever add an MSGID and/or REPLY to, or modify an existing
|
||||||
system.
|
MSGID / REPLY contained in, a message not originating on that
|
||||||
|
system.
|
||||||
</PRE>
|
|
||||||
|
</PRE>
|
||||||
<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>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,192 +1,193 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>Addessing Control Paragraphs.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>Addessing Control Paragraphs.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<PRE>
|
>
|
||||||
**********************************************************************
|
<PRE>
|
||||||
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
**********************************************************************
|
||||||
**********************************************************************
|
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
||||||
|
**********************************************************************
|
||||||
Publication: FTS-4001
|
|
||||||
Revision: 1
|
Publication: FTS-4001
|
||||||
Title: ADDRESSING CONTROL PARAGRAPHS
|
Revision: 1
|
||||||
Author(s): FTSC
|
Title: ADDRESSING CONTROL PARAGRAPHS
|
||||||
|
Author(s): FTSC
|
||||||
Revision Date: 1 October 2000
|
|
||||||
Expiry Date: 1 October 2002
|
Revision Date: 1 October 2000
|
||||||
----------------------------------------------------------------------
|
Expiry Date: 1 October 2002
|
||||||
Contents:
|
----------------------------------------------------------------------
|
||||||
1. Credits
|
Contents:
|
||||||
2. General
|
1. Credits
|
||||||
3. FMPT
|
2. General
|
||||||
4. TOPT
|
3. FMPT
|
||||||
5. INTL
|
4. TOPT
|
||||||
----------------------------------------------------------------------
|
5. INTL
|
||||||
|
----------------------------------------------------------------------
|
||||||
Status of this document
|
|
||||||
-----------------------
|
Status of this document
|
||||||
|
-----------------------
|
||||||
This document is a Fidonet Standard (FTS).
|
|
||||||
|
This document is a Fidonet Standard (FTS).
|
||||||
This document specifies a Fidonet standard for the Fidonet
|
|
||||||
community.
|
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.
|
This document is released to the public domain, and may be used,
|
||||||
|
copied or modified for any purpose whatever.
|
||||||
|
|
||||||
1. Credits
|
|
||||||
----------
|
1. Credits
|
||||||
|
----------
|
||||||
This document is based on the work of Randy Bush and many others.
|
|
||||||
|
This document is based on the work of Randy Bush and many others.
|
||||||
|
|
||||||
2. General
|
|
||||||
----------
|
2. General
|
||||||
|
----------
|
||||||
The general control paragraph format is specified in separate FTSC
|
|
||||||
documents.
|
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.
|
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
|
While it would be technically correct to use them also in echomail,
|
||||||
there. It is therefore recommended that they should not be used in
|
it is known that certain programs will misbehave if they are present
|
||||||
echomail at the present time.
|
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
|
If a program processing messages detects these control paragraphs in
|
||||||
deleted from any copies of that message exported to other systems.
|
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
|
Addressing of and address resolution for echomail messages should
|
||||||
information. See separate FTSC documents.
|
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
|
To determine the address of the original sender of an echomail
|
||||||
separate FTSC documents.
|
message, the information in the Origin line should be used. See
|
||||||
|
separate FTSC documents.
|
||||||
|
|
||||||
3. FMPT
|
|
||||||
-------
|
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
|
The FMPT control paragraph shall be used to give information about
|
||||||
number is not 0. If the point number of the original sender of a
|
the point number of the original sender of a message if that point
|
||||||
message is 0 that message should not contain any FMPT control
|
number is not 0. If the point number of the original sender of a
|
||||||
paragraph.
|
message is 0 that message should not contain any FMPT control
|
||||||
|
paragraph.
|
||||||
The format of a FMPT control paragraph shall be:
|
|
||||||
|
The format of a FMPT control paragraph shall be:
|
||||||
<SOH>"FMPT <point number>"<CR>
|
|
||||||
|
<SOH>"FMPT <point number>"<CR>
|
||||||
where <point number> is the ASCII representation of the point number
|
|
||||||
of the sender. The point number shall be an unsigned integer in the
|
where <point number> is the ASCII representation of the point number
|
||||||
range 1-65535.
|
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
|
E.g. a message from point number 1 of a certain node shall contain
|
||||||
|
the following FMPT control paragraph
|
||||||
<SOH>"FMPT 1"<CR>
|
|
||||||
|
<SOH>"FMPT 1"<CR>
|
||||||
Note that the format of a FMPT control paragraph deviates from the
|
|
||||||
general format specified in separate FTSC documents in that it does
|
Note that the format of a FMPT control paragraph deviates from the
|
||||||
not contain any colon after the control tag.
|
general format specified in separate FTSC documents in that it does
|
||||||
|
not contain any colon after the control tag.
|
||||||
|
|
||||||
4. TOPT
|
|
||||||
-------
|
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
|
The TOPT control paragraph shall be used to give information about
|
||||||
point number is not 0. If the point number of the ultimate addressee
|
the point number of the ultimate addressee of a message if that
|
||||||
of a message is 0 that message should not contain any TOPT control
|
point number is not 0. If the point number of the ultimate addressee
|
||||||
paragraph.
|
of a message is 0 that message should not contain any TOPT control
|
||||||
|
paragraph.
|
||||||
The format of a TOPT control paragraph shall be:
|
|
||||||
|
The format of a TOPT control paragraph shall be:
|
||||||
<SOH>"TOPT "<point number><CR>
|
|
||||||
|
<SOH>"TOPT "<point number><CR>
|
||||||
where <point number> is the ASCII representation of the point number
|
|
||||||
of the addressee. The point number shall be an unsigned integer in
|
where <point number> is the ASCII representation of the point number
|
||||||
the range 1-65535.
|
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
|
E.g. a message to point number 1 of a certain node shall contain the
|
||||||
|
following TOPT control paragraph
|
||||||
<SOH>"TOPT 1"<CR>
|
|
||||||
|
<SOH>"TOPT 1"<CR>
|
||||||
Note that the format of a TOPT control paragraph deviates from the
|
|
||||||
general format specified in separate FTSC documents in that it does
|
Note that the format of a TOPT control paragraph deviates from the
|
||||||
not contain any colon after the control tag.
|
general format specified in separate FTSC documents in that it does
|
||||||
|
not contain any colon after the control tag.
|
||||||
|
|
||||||
5. INTL
|
|
||||||
-------
|
5. INTL
|
||||||
|
-------
|
||||||
The INTL control paragraph shall be used to give information about
|
|
||||||
the zone numbers of the original sender and the ultimate addressee
|
The INTL control paragraph shall be used to give information about
|
||||||
of a message.
|
the zone numbers of the original sender and the ultimate addressee
|
||||||
|
of a message.
|
||||||
The format of an INTL control paragraph shall be:
|
|
||||||
|
The format of an INTL control paragraph shall be:
|
||||||
<SOH>"INTL "<destination address>" "<origin address><CR>
|
|
||||||
|
<SOH>"INTL "<destination address>" "<origin address><CR>
|
||||||
where <destination address> shall be the representation of the
|
|
||||||
address of ultimate destination and <origin address> is the
|
where <destination address> shall be the representation of the
|
||||||
representation of the address of the original sender of the message
|
address of ultimate destination and <origin address> is the
|
||||||
in question. These addresses shall be given on the form
|
representation of the address of the original sender of the message
|
||||||
<zone>:<net>/<node> where <zone> is the ASCII representation of the
|
in question. These addresses shall be given on the form
|
||||||
zone number, <net> is the ASCII representation of the net number and
|
<zone>:<net>/<node> where <zone> is the ASCII representation of the
|
||||||
<node> is the ASCII representation of the node number. Any point
|
zone number, <net> is the ASCII representation of the net number and
|
||||||
number information shall be given in FMPT and TOPT control
|
<node> is the ASCII representation of the node number. Any point
|
||||||
paragraphs.
|
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
|
E.g. a message from address 1:123/4.5 to 2:345/6.7 shall contain the
|
||||||
|
following INTL control paragraph
|
||||||
<SOH>"INTL 2:345/6 1:123/4"<CR>
|
|
||||||
|
<SOH>"INTL 2:345/6 1:123/4"<CR>
|
||||||
Note that the format of an INTL control paragraph deviates from the
|
|
||||||
general format specified in separate FTSC documents in that it does
|
Note that the format of an INTL control paragraph deviates from the
|
||||||
not contain any colon after the control tag.
|
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
|
INTL control paragraphs are also often used even when both the
|
||||||
gives both the originating system and the destination system as well
|
originating and the destination systems are in the same zone. This
|
||||||
as any intermediate routing systems unambiguous zone information
|
gives both the originating system and the destination system as well
|
||||||
even in a situation where one system may be active in a number of
|
as any intermediate routing systems unambiguous zone information
|
||||||
different (possibly non-FidoNet) zones.
|
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
|
Although it is known that some programs may route messages
|
||||||
where both the originating and the destination systems are in the
|
incorrectly if the INTL control paragraph is present in messages
|
||||||
same zone, it is recommended that the INTL control paragraph is
|
where both the originating and the destination systems are in the
|
||||||
always inserted into netmail messages in packet files.
|
same zone, it is recommended that the INTL control paragraph is
|
||||||
|
always inserted into netmail messages in packet files.
|
||||||
|
|
||||||
|
|
||||||
A. History
|
|
||||||
----------
|
A. History
|
||||||
|
----------
|
||||||
Rev.1, 20001001: Initial Release.
|
|
||||||
Principal author Goran Eriksson.
|
Rev.1, 20001001: Initial Release.
|
||||||
|
Principal author Goran Eriksson.
|
||||||
**********************************************************************
|
|
||||||
</PRE>
|
**********************************************************************
|
||||||
|
</PRE>
|
||||||
<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>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,4 +1,5 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
|
<!-- $Id$ -->
|
||||||
<HEAD>
|
<HEAD>
|
||||||
<TITLE>The Distribution Nodelist.</TITLE>
|
<TITLE>The Distribution Nodelist.</TITLE>
|
||||||
</HEAD>
|
</HEAD>
|
||||||
@ -446,7 +447,7 @@ C. History<BR>
|
|||||||
<BR>
|
<BR>
|
||||||
</TT>
|
</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>
|
</BODY>
|
||||||
</HTML>
|
</HTML>
|
||||||
|
|||||||
@ -1,4 +1,5 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
|
<!-- $Id$ -->
|
||||||
<HEAD>
|
<HEAD>
|
||||||
<TITLE>The Distribution Nodelist.</TITLE>
|
<TITLE>The Distribution Nodelist.</TITLE>
|
||||||
</HEAD>
|
</HEAD>
|
||||||
@ -396,7 +397,7 @@ B. History<BR>
|
|||||||
<BR>
|
<BR>
|
||||||
</TT>
|
</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>
|
</BODY>
|
||||||
</HTML>
|
</HTML>
|
||||||
|
|||||||
@ -1,311 +1,312 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
<HEAD>
|
<!-- $Id$ -->
|
||||||
<TITLE>FTSC Product ID List.</TITLE>
|
<HEAD>
|
||||||
</HEAD>
|
<TITLE>FTSC Product ID List.</TITLE>
|
||||||
|
</HEAD>
|
||||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
||||||
<BODY
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||||
BGCOLOR="#FFFFFF"
|
<BODY
|
||||||
TEXT="#000000"
|
BGCOLOR="#FFFFFF"
|
||||||
LINK="#0000FF"
|
TEXT="#000000"
|
||||||
VLINK="#000080"
|
LINK="#0000FF"
|
||||||
ALINK="#FF0000"
|
VLINK="#000080"
|
||||||
>
|
ALINK="#FF0000"
|
||||||
<H2><DIV align=center>FTSC Product codes 22 jan 2000</DIV></H2><P>
|
>
|
||||||
<PRE>
|
<H2><DIV align=center>FTSC Product codes 22 jan 2000</DIV></H2><P>
|
||||||
0000,Fido,MS-DOS,Packer/mailer,Tom_Jennings,1:125/111
|
<PRE>
|
||||||
0001,Rover,MS-DOS,Packer/mailer,Bob_Hartman,1:104/501
|
0000,Fido,MS-DOS,Packer/mailer,Tom_Jennings,1:125/111
|
||||||
0002,SEAdog,MS-DOS,Packer/mailer,Thom_Henderson,1:107/542.1
|
0001,Rover,MS-DOS,Packer/mailer,Bob_Hartman,1:104/501
|
||||||
0003,WinDog,MS-DOS,Mailer,Solar_Wind_Computing,1:115/333
|
0002,SEAdog,MS-DOS,Packer/mailer,Thom_Henderson,1:107/542.1
|
||||||
0004,Slick-150,HP-150,Packer/mailer,Jerry_Bain,????
|
0003,WinDog,MS-DOS,Mailer,Solar_Wind_Computing,1:115/333
|
||||||
0005,Opus,MS-DOS,Packer/mailer,Doug_Boone,1:124/4227
|
0004,Slick-150,HP-150,Packer/mailer,Jerry_Bain,????
|
||||||
0006,Dutchie,MS-DOS,Packer/mailer,Henk_Wevers,2:500/1
|
0005,Opus,MS-DOS,Packer/mailer,Doug_Boone,1:124/4227
|
||||||
0007,WPL_Library,Amiga,Mailer,Russell_McOrmand,1:163/109
|
0006,Dutchie,MS-DOS,Packer/mailer,Henk_Wevers,2:500/1
|
||||||
0008,Tabby,Macintosh,Packer/mailer,Michael_Connick,1:107/412
|
0007,WPL_Library,Amiga,Mailer,Russell_McOrmand,1:163/109
|
||||||
0009,SWMail,OS/2,Mailer,Solar_Wind_Computing,1:115/333
|
0008,Tabby,Macintosh,Packer/mailer,Michael_Connick,1:107/412
|
||||||
000A,Wolf-68k,CPM-68k,Packer/mailer,Robert_Heller,1:321/153
|
0009,SWMail,OS/2,Mailer,Solar_Wind_Computing,1:115/333
|
||||||
000B,QMM,QNX,Packer/mailer,Rick_Duff,1:167/201
|
000A,Wolf-68k,CPM-68k,Packer/mailer,Robert_Heller,1:321/153
|
||||||
000C,FrontDoor,MS-DOS,Packer/mailer,Joaquim_Homrighausen,2:270/17
|
000B,QMM,QNX,Packer/mailer,Rick_Duff,1:167/201
|
||||||
000D,GOmail,MS-DOS,Packer,Scott_Green,????
|
000C,FrontDoor,MS-DOS,Packer/mailer,Joaquim_Homrighausen,2:270/17
|
||||||
000E,FFGate,MS-DOS,Packer,Ruedi_Kneubuehler,2:301/580
|
000D,GOmail,MS-DOS,Packer,Scott_Green,????
|
||||||
000F,FileMgr,MS-DOS,Packer,Erik_van_Emmerik,2:281/611
|
000E,FFGate,MS-DOS,Packer,Ruedi_Kneubuehler,2:301/580
|
||||||
0010,FIDZERCP,MS-DOS,Packer,Thorsten_Seidel,2:242/55
|
000F,FileMgr,MS-DOS,Packer,Erik_van_Emmerik,2:281/611
|
||||||
0011,MailMan,MS-DOS,Packer,Ron_Bemis,1:124/1113
|
0010,FIDZERCP,MS-DOS,Packer,Thorsten_Seidel,2:242/55
|
||||||
0012,OOPS,MS-DOS,Packer,Tom_Kashuba,1:322/379
|
0011,MailMan,MS-DOS,Packer,Ron_Bemis,1:124/1113
|
||||||
0013,GS-Point,Atari_ST,Packer/mailer,Harry_Lee,1:124/4230
|
0012,OOPS,MS-DOS,Packer,Tom_Kashuba,1:322/379
|
||||||
0014,BGMail,????,????,Ray_Gwinn,1:265/104
|
0013,GS-Point,Atari_ST,Packer/mailer,Harry_Lee,1:124/4230
|
||||||
0015,ComMotion/2,OS/2,Packer/mailer,Michael_Buenter,2:301/602
|
0014,BGMail,????,????,Ray_Gwinn,1:265/104
|
||||||
0016,OurBBS_Fidomailer,MS-DOS/Unix/Coherent,Packer/mailer,Brian_Keahl,1:133/524
|
0015,ComMotion/2,OS/2,Packer/mailer,Michael_Buenter,2:301/602
|
||||||
0017,FidoPcb,MS-DOS,Packer,Matjaz_Koce,2:380/100
|
0016,OurBBS_Fidomailer,MS-DOS/Unix/Coherent,Packer/mailer,Brian_Keahl,1:133/524
|
||||||
0018,WimpLink,Archimedes,Packer/mailer,Remco_de_Vreugd,2:283/307
|
0017,FidoPcb,MS-DOS,Packer,Matjaz_Koce,2:380/100
|
||||||
0019,BinkScan,MS-DOS,Packer,Shawn_Stoddard,1:362/101
|
0018,WimpLink,Archimedes,Packer/mailer,Remco_de_Vreugd,2:283/307
|
||||||
001A,D'Bridge,MS-DOS,Packer/mailer,Chris_Irwin,1:18/68
|
0019,BinkScan,MS-DOS,Packer,Shawn_Stoddard,1:362/101
|
||||||
001B,BinkleyTerm,MS-DOS,Mailer,Vince_Perriello,1:343/491
|
001A,D'Bridge,MS-DOS,Packer/mailer,Chris_Irwin,1:18/68
|
||||||
001C,Yankee,MS-DOS,Packer,Randy_Edwards,????
|
001B,BinkleyTerm,MS-DOS,Mailer,Vince_Perriello,1:343/491
|
||||||
001D,uuGate,MS-DOS,Packer,Geoff_Watts,3:690/710
|
001C,Yankee,MS-DOS,Packer,Randy_Edwards,????
|
||||||
001E,Daisy,Apple_][,Packer/mailer,Raymond_&_Ken_Lo,3:700/1
|
001D,uuGate,MS-DOS,Packer,Geoff_Watts,3:690/710
|
||||||
001F,Polar_Bear,????,Packer/mailer,Kenneth_McLeod,1:101/190
|
001E,Daisy,Apple_][,Packer/mailer,Raymond_&_Ken_Lo,3:700/1
|
||||||
0020,The-Box,MS-DOS/Atari_ST,Packer/mailer,Jac_Kersing/Arjen_Lentz,2:283/333
|
001F,Polar_Bear,????,Packer/mailer,Kenneth_McLeod,1:101/190
|
||||||
0021,STARgate/2,OS/2,Packer/mailer,Shawn_Stoddard,1:362/101
|
0020,The-Box,MS-DOS/Atari_ST,Packer/mailer,Jac_Kersing/Arjen_Lentz,2:283/333
|
||||||
0022,TMail,MS-DOS,Packer,Larry_Lewis,3:713/600.1701
|
0021,STARgate/2,OS/2,Packer/mailer,Shawn_Stoddard,1:362/101
|
||||||
0023,TCOMMail,MS-DOS,Packer/mailer,Mike_Ratledge,1:372/888
|
0022,TMail,MS-DOS,Packer,Larry_Lewis,3:713/600.1701
|
||||||
0024,GIGO,MS-DOS,Packer,Jason_Fesler,1:203/7707,,940228
|
0023,TCOMMail,MS-DOS,Packer/mailer,Mike_Ratledge,1:372/888
|
||||||
0025,RBBSMail,MS-DOS,Packer,Jan_Terpstra,2:512/10
|
0024,GIGO,MS-DOS,Packer,Jason_Fesler,1:203/7707,,940228
|
||||||
0026,Apple-Netmail,Apple_][,Packer/mailer,Bill_Fenner,1:129/87
|
0025,RBBSMail,MS-DOS,Packer,Jan_Terpstra,2:512/10
|
||||||
0027,Chameleon,Amiga,Mailer,Juergen_Hermann,2:241/2.12
|
0026,Apple-Netmail,Apple_][,Packer/mailer,Bill_Fenner,1:129/87
|
||||||
0028,Majik_Board,MS-DOS,Packer/mailer,Dale_Barnes,1:3601/14.20
|
0027,Chameleon,Amiga,Mailer,Juergen_Hermann,2:241/2.12
|
||||||
0029,QM,MS-DOS,Packer,George_Peace,1:270/101
|
0028,Majik_Board,MS-DOS,Packer/mailer,Dale_Barnes,1:3601/14.20
|
||||||
002A,Point_And_Click,Amiga,Packer,Rob_Tillotson,1:201/40.302
|
0029,QM,MS-DOS,Packer,George_Peace,1:270/101
|
||||||
002B,Aurora_Three_Bundler,MS-DOS,Packer,Oliver_McDonald,????
|
002A,Point_And_Click,Amiga,Packer,Rob_Tillotson,1:201/40.302
|
||||||
002C,FourDog,MS-DOS,Packer,Shay_Walters,1:376/12
|
002B,Aurora_Three_Bundler,MS-DOS,Packer,Oliver_McDonald,????
|
||||||
002D,MSG-PACK,MS-DOS,Packer,Tom_Hendricks,1:261/662
|
002C,FourDog,MS-DOS,Packer,Shay_Walters,1:376/12
|
||||||
002E,AMAX,MS-DOS,Packer,Alan_Applegate,1:104/36
|
002D,MSG-PACK,MS-DOS,Packer,Tom_Hendricks,1:261/662
|
||||||
002F,Domain_Communication_System,????,????,Hal_Duprie,1:101/106
|
002E,AMAX,MS-DOS,Packer,Alan_Applegate,1:104/36
|
||||||
0030,LesRobot,????,Packer,Lennart_Svensonn,2:501/2
|
002F,Domain_Communication_System,????,????,Hal_Duprie,1:101/106
|
||||||
0031,Rose,MS-DOS,Packer/mailer,Glen_Jackson,1:100/617
|
0030,LesRobot,????,Packer,Lennart_Svensonn,2:501/2
|
||||||
0032,Paragon,Amiga,Packer/mailer,Jon_Radoff,1:322/545
|
0031,Rose,MS-DOS,Packer/mailer,Glen_Jackson,1:100/617
|
||||||
0033,BinkleyTerm/oMMM/ST,Atari_ST,Packer/mailer,Bill_Scull,1:363/112,,19951209
|
0032,Paragon,Amiga,Packer/mailer,Jon_Radoff,1:322/545
|
||||||
0034,StarNet,Atari_ST,Mailer,Eric_Drewry,1:322/566
|
0033,BinkleyTerm/oMMM/ST,Atari_ST,Packer/mailer,Bill_Scull,1:363/112,,19951209
|
||||||
0035,ZzyZx,MS-DOS,Packer,Jason_Steck,1:124/424
|
0034,StarNet,Atari_ST,Mailer,Eric_Drewry,1:322/566
|
||||||
0036,QEcho,MS-DOS,Packer,The_QuickBBS_Group,1:363/1701
|
0035,ZzyZx,MS-DOS,Packer,Jason_Steck,1:124/424
|
||||||
0037,BOOM,MS-DOS,Packer,Andrew_Farmer,1:243/1
|
0036,QEcho,MS-DOS,Packer,The_QuickBBS_Group,1:363/1701
|
||||||
0038,PBBS,Amiga,Packer/mailer,Todd_Kover,1:261/1028
|
0037,BOOM,MS-DOS,Packer,Andrew_Farmer,1:243/1
|
||||||
0039,TrapDoor,Amiga,Mailer,Maximilian_Hantsch,2:310/6
|
0038,PBBS,Amiga,Packer/mailer,Todd_Kover,1:261/1028
|
||||||
003A,Welmat,Amiga,Mailer,Russell_McOrmand,1:163/109
|
0039,TrapDoor,Amiga,Mailer,Maximilian_Hantsch,2:310/6
|
||||||
003B,NetGate,Unix-386,Packer,David_Nugent,3:632/348
|
003A,Welmat,Amiga,Mailer,Russell_McOrmand,1:163/109
|
||||||
003C,Odie,MS-DOS,Mailer,Matt_Farrenkopf,1:105/376
|
003B,NetGate,Unix-386,Packer,David_Nugent,3:632/348
|
||||||
003D,Quick_Gimme,CPM-80/MS-DOS,Packer/mailer,Laeeth_Isaacs,2:254/18
|
003C,Odie,MS-DOS,Mailer,Matt_Farrenkopf,1:105/376
|
||||||
003E,dbLink,MS-DOS,Packer/mailer,Chris_Irwin,1:18/68
|
003D,Quick_Gimme,CPM-80/MS-DOS,Packer/mailer,Laeeth_Isaacs,2:254/18
|
||||||
003F,TosScan,MS-DOS,Packer,Joaquim_Homrighausen,2:270/17
|
003E,dbLink,MS-DOS,Packer/mailer,Chris_Irwin,1:18/68
|
||||||
0040,Beagle,MS-DOS,Mailer,Alexander_Holy,2:310/90
|
003F,TosScan,MS-DOS,Packer,Joaquim_Homrighausen,2:270/17
|
||||||
0041,Igor,MS-DOS,Mailer,Harry_Lee,1:124/4230
|
0040,Beagle,MS-DOS,Mailer,Alexander_Holy,2:310/90
|
||||||
0042,TIMS,MS-DOS,Packer/mailer,Bit_Bucket_Software,1:104/501
|
0041,Igor,MS-DOS,Mailer,Harry_Lee,1:124/4230
|
||||||
0043,Phoenix,MS-DOS,Packer/mailer,International_Telecommunications,1:296/5,,19930624
|
0042,TIMS,MS-DOS,Packer/mailer,Bit_Bucket_Software,1:104/501
|
||||||
0044,FrontDoor_APX,MS-DOS,Packer/mailer,Joaquim_Homrighausen,2:270/17
|
0043,Phoenix,MS-DOS,Packer/mailer,International_Telecommunications,1:296/5,,19930624
|
||||||
0045,XRS,MS-DOS,Packer,Mike_Ratledge,1:372/888
|
0044,FrontDoor_APX,MS-DOS,Packer/mailer,Joaquim_Homrighausen,2:270/17
|
||||||
0046,Juliet_Mail_System,Amiga,Packer,Gregory_Kritsch,1:163/109.30
|
0045,XRS,MS-DOS,Packer,Mike_Ratledge,1:372/888
|
||||||
0047,Jabberwocky,Macintosh,Packer,Eric_Larson,1:2605/620
|
0046,Juliet_Mail_System,Amiga,Packer,Gregory_Kritsch,1:163/109.30
|
||||||
0048,XST,MS-DOS,Packer,Wayne_Michaels,1:380/100
|
0047,Jabberwocky,Macintosh,Packer,Eric_Larson,1:2605/620
|
||||||
0049,MailStorm,Amiga,Packer,Russel_Miranda,1:268/106
|
0048,XST,MS-DOS,Packer,Wayne_Michaels,1:380/100
|
||||||
004A,BIX-Mail,????,Mailer,Bob_Hartman,1:104/501
|
0049,MailStorm,Amiga,Packer,Russel_Miranda,1:268/106
|
||||||
004B,IMAIL,MS-DOS,Packer,IMAIL_INC.,2:246/47
|
004A,BIX-Mail,????,Mailer,Bob_Hartman,1:104/501
|
||||||
004C,FTNGate,MS-DOS,Packer,Jason_Steck,1:104/424
|
004B,IMAIL,MS-DOS,Packer,IMAIL_INC.,2:246/47
|
||||||
004D,RealMail,MS-DOS,Packer,Taine_Gilliam,1:372/42
|
004C,FTNGate,MS-DOS,Packer,Jason_Steck,1:104/424
|
||||||
004E,Lora-CBIS,MS-DOS,Mailer,Marco_Maccaferri,2:332/402
|
004D,RealMail,MS-DOS,Packer,Taine_Gilliam,1:372/42
|
||||||
004F,TDCS,PDP-11,Packer/mailer,Terry_Ebdon,2:254/6
|
004E,Lora-CBIS,MS-DOS,Mailer,Marco_Maccaferri,2:332/402
|
||||||
0050,InterMail,MS-DOS,Packer/mailer,Peter_Stewart,1:369/35
|
004F,TDCS,PDP-11,Packer/mailer,Terry_Ebdon,2:254/6
|
||||||
0051,RFD,MS-DOS,Packer,Doug_Belkofer,1:234/10
|
0050,InterMail,MS-DOS,Packer/mailer,Peter_Stewart,1:369/35
|
||||||
0052,Yuppie!,MS-DOS,Packer,Leo_Moll,2:242/2
|
0051,RFD,MS-DOS,Packer,Doug_Belkofer,1:234/10
|
||||||
0053,EMMA,MS-DOS,Packer,Johan_Zwiekhorst,2:292/100
|
0052,Yuppie!,MS-DOS,Packer,Leo_Moll,2:242/2
|
||||||
0054,QBoxMail,QDOS,Packer/mailer,Jan_Bredenbeek,2:283/500
|
0053,EMMA,MS-DOS,Packer,Johan_Zwiekhorst,2:292/100
|
||||||
0055,Number_4,MS-DOS,Packer/mailer,Ola_Garstad,2:502/15
|
0054,QBoxMail,QDOS,Packer/mailer,Jan_Bredenbeek,2:283/500
|
||||||
0056,Number_5,MS-DOS,Packer/mailer,Ola_Garstad,2:502/15
|
0055,Number_4,MS-DOS,Packer/mailer,Ola_Garstad,2:502/15
|
||||||
0057,GSBBS,MS-DOS,Packer,Michelangelo_Jones,1:260/244
|
0056,Number_5,MS-DOS,Packer/mailer,Ola_Garstad,2:502/15
|
||||||
0058,Merlin,MS-DOS,Packer/mailer,Mark_Lewis,2:258/25
|
0057,GSBBS,MS-DOS,Packer,Michelangelo_Jones,1:260/244
|
||||||
0059,TPCS,MS-DOS,Packer,Mikael_Kjellstrom,2:201/211
|
0058,Merlin,MS-DOS,Packer/mailer,Mark_Lewis,2:258/25
|
||||||
005A,Raid,MS-DOS,Packer,George_Peace,1:270/101
|
0059,TPCS,MS-DOS,Packer,Mikael_Kjellstrom,2:201/211
|
||||||
005B,Outpost,MS-DOS,Packer/mailer,Mike_Dailor,????
|
005A,Raid,MS-DOS,Packer,George_Peace,1:270/101
|
||||||
005C,Nizze,MS-DOS,Packer,Tomas_Nielsen,2:205/202
|
005B,Outpost,MS-DOS,Packer/mailer,Mike_Dailor,????
|
||||||
005D,Armadillo,Macintosh,Packer,Erik_Sea,1:221/109
|
005C,Nizze,MS-DOS,Packer,Tomas_Nielsen,2:205/202
|
||||||
005E,rfmail,Unix,Packer/mailer,Per_Lindqvist,2:201/332
|
005D,Armadillo,Macintosh,Packer,Erik_Sea,1:221/109
|
||||||
005F,Msgtoss,MS-DOS,Packer,Mike_Zakharoff,1:343/36
|
005E,rfmail,Unix,Packer/mailer,Per_Lindqvist,2:201/332
|
||||||
0060,InfoTex,MS-DOS,Packer/mailer,Jan_Spooren,2:292/852
|
005F,Msgtoss,MS-DOS,Packer,Mike_Zakharoff,1:343/36
|
||||||
0061,GEcho,MS-DOS,Packer,Gerard_van_der_Land,2:283/555,951209
|
0060,InfoTex,MS-DOS,Packer/mailer,Jan_Spooren,2:292/852
|
||||||
0062,CDEhost,MS-DOS,Packer,Dennis_D'Annunzio,1:379/28
|
0061,GEcho,MS-DOS,Packer,Gerard_van_der_Land,2:283/555,951209
|
||||||
0063,Pktize,MS-DOS,Packer,Joaquim_Homrighausen,2:270/17
|
0062,CDEhost,MS-DOS,Packer,Dennis_D'Annunzio,1:379/28
|
||||||
0064,PC-RAIN,MS-DOS,Packer/mailer,Ray_Hyder,1:272/40
|
0063,Pktize,MS-DOS,Packer,Joaquim_Homrighausen,2:270/17
|
||||||
0065,Truffle,MS-DOS/OS2,Mailer,Mike_Rissa,2:504/59
|
0064,PC-RAIN,MS-DOS,Packer/mailer,Ray_Hyder,1:272/40
|
||||||
0066,Foozle,Amiga,Packer,Peer_Hasselmeyer,2:247/4
|
0065,Truffle,MS-DOS/OS2,Mailer,Mike_Rissa,2:504/59
|
||||||
0067,White_Pointer,Macintosh,Packer/mailer,Alastair_Rakine,3:680/820
|
0066,Foozle,Amiga,Packer,Peer_Hasselmeyer,2:247/4
|
||||||
0068,GateWorks,MS-DOS,Packer,Jamie_Penner,1:153/1025
|
0067,White_Pointer,Macintosh,Packer/mailer,Alastair_Rakine,3:680/820
|
||||||
0069,Portal_of_Power,MS-DOS,Mailer,Soren_Ager,2:230/12
|
0068,GateWorks,MS-DOS,Packer,Jamie_Penner,1:153/1025
|
||||||
006A,MacWoof,Macintosh,Packer/mailer,Craig_Vaughan,1:109/342
|
0069,Portal_of_Power,MS-DOS,Mailer,Soren_Ager,2:230/12
|
||||||
006B,Mosaic,MS-DOS,Packer,Christopher_King,1:103/315
|
006A,MacWoof,Macintosh,Packer/mailer,Craig_Vaughan,1:109/342
|
||||||
006C,TPBEcho,MS-DOS,Packer,Gerd_Qualmann,2:242/1
|
006B,Mosaic,MS-DOS,Packer,Christopher_King,1:103/315
|
||||||
006D,HandyMail,MS-DOS,Packer/mailer,jim_nutt,1:114/30
|
006C,TPBEcho,MS-DOS,Packer,Gerd_Qualmann,2:242/1
|
||||||
006E,EchoSmith,MS-DOS,Packer,Noel_Crow,1:170/409
|
006D,HandyMail,MS-DOS,Packer/mailer,jim_nutt,1:114/30
|
||||||
006F,FileHost,MS-DOS,Packer,Mark_Cole,2:252/186
|
006E,EchoSmith,MS-DOS,Packer,Noel_Crow,1:170/409
|
||||||
0070,SFTS,MS-DOS,Packer,Bruce_Anderson,1:3402/6
|
006F,FileHost,MS-DOS,Packer,Mark_Cole,2:252/186
|
||||||
0071,Benjamin,MS-DOS,Packer/mailer,Stefan_Graf,2:245/4.5436
|
0070,SFTS,MS-DOS,Packer,Bruce_Anderson,1:3402/6
|
||||||
0072,RiBBS,OS9_(COCO),Packer/mailer,Ron_Bihler,1:104/54
|
0071,Benjamin,MS-DOS,Packer/mailer,Stefan_Graf,2:245/4.5436
|
||||||
0073,MP,MS-DOS,Packer,Ivan_Leong,6:600/28
|
0072,RiBBS,OS9_(COCO),Packer/mailer,Ron_Bihler,1:104/54
|
||||||
0074,Ping,MS-DOS,Packer,David_Nugent,3:632/348
|
0073,MP,MS-DOS,Packer,Ivan_Leong,6:600/28
|
||||||
0075,Door2Europe,MS-DOS,Packer/mailer,Michaela_Schoebel,2:247/14
|
0074,Ping,MS-DOS,Packer,David_Nugent,3:632/348
|
||||||
0076,SWIFT,MS-DOS,Packer/mailer,Hanno_van_der_Maas,2:500/2
|
0075,Door2Europe,MS-DOS,Packer/mailer,Michaela_Schoebel,2:247/14
|
||||||
0077,WMAIL,MS-DOS,Packer,Silvan_Calarco,2:334/100.2
|
0076,SWIFT,MS-DOS,Packer/mailer,Hanno_van_der_Maas,2:500/2
|
||||||
0078,RATS,MS-DOS,Packer,Jason_DeCaro,1:260/205
|
0077,WMAIL,MS-DOS,Packer,Silvan_Calarco,2:334/100.2
|
||||||
0079,Harry_the_Dirty_Dog,OS2,Mailer/packer,George_Edwards,3:632/340.7
|
0078,RATS,MS-DOS,Packer,Jason_DeCaro,1:260/205
|
||||||
007A,Maximus-CBCS,MS-DOS/OS2,Packer,Scott_Dudley,1:249/106
|
0079,Harry_the_Dirty_Dog,OS2,Mailer/packer,George_Edwards,3:632/340.7
|
||||||
007B,SwifEcho,MS-DOS,Packer,Dana_Bell,1:3801/8
|
007A,Maximus-CBCS,MS-DOS/OS2,Packer,Scott_Dudley,1:249/106
|
||||||
007C,GCChost,Amiga,Packer,Davide_Massarenti,2:332/505.3
|
007B,SwifEcho,MS-DOS,Packer,Dana_Bell,1:3801/8
|
||||||
007D,RPX-Mail,MS-DOS,Packer,Joerg_Wirtgen,2:241/4034
|
007C,GCChost,Amiga,Packer,Davide_Massarenti,2:332/505.3
|
||||||
007E,Tosser,MS-DOS,Packer,Albert_Ng,6:700/185
|
007D,RPX-Mail,MS-DOS,Packer,Joerg_Wirtgen,2:241/4034
|
||||||
007F,TCL,MS-DOS,Packer,Ulf_Hedlund,2:201/602
|
007E,Tosser,MS-DOS,Packer,Albert_Ng,6:700/185
|
||||||
0080,MsgTrack,MS-DOS,Packer,Andrew_Farmer,1:243/1
|
007F,TCL,MS-DOS,Packer,Ulf_Hedlund,2:201/602
|
||||||
0081,FMail,MS-DOS/DOS_DPMI/OS2/WIN32,Packer,Folkert_Wijnstra,2:283/619
|
0080,MsgTrack,MS-DOS,Packer,Andrew_Farmer,1:243/1
|
||||||
0082,Scantoss,MS-DOS,Packer,Michael_Matter,2:243/44.3443
|
0081,FMail,MS-DOS/DOS_DPMI/OS2/WIN32,Packer,Folkert_Wijnstra,2:283/619
|
||||||
0083,Point_Manager,Amiga,Packer,Pino_Aliberti,2:335/602.2,,19931012
|
0082,Scantoss,MS-DOS,Packer,Michael_Matter,2:243/44.3443
|
||||||
0084,IMBINK,MS-DOS,Packer,Mike_Hartmann,2:246/48
|
0083,Point_Manager,Amiga,Packer,Pino_Aliberti,2:335/602.2,,19931012
|
||||||
0085,Simplex,MS-DOS/OS2,Packer,Chris_Laforet,1:152/401
|
0084,IMBINK,MS-DOS,Packer,Mike_Hartmann,2:246/48
|
||||||
0086,UMTP,MS-DOS,Packer,Byron_Copeland,1:272/26
|
0085,Simplex,MS-DOS/OS2,Packer,Chris_Laforet,1:152/401
|
||||||
0087,Indaba,MS-DOS,Packer,Pieter_Muller,5:7102/11
|
0086,UMTP,MS-DOS,Packer,Byron_Copeland,1:272/26
|
||||||
0088,Echomail_Engine,MS-DOS,Packer,Joe_Jared,1:103/200
|
0087,Indaba,MS-DOS,Packer,Pieter_Muller,5:7102/11
|
||||||
0089,DragonMail,OS2,Packer,Patrick_O'Riva,1:143/37
|
0088,Echomail_Engine,MS-DOS,Packer,Joe_Jared,1:103/200
|
||||||
008A,Prox,MS-DOS,Packer,Gerhard_Hoogterp,2:283/1.2
|
0089,DragonMail,OS2,Packer,Patrick_O'Riva,1:143/37
|
||||||
008B,Tick,MS-DOS/OS2,Packer,Barry_Geller,1:266/12
|
008A,Prox,MS-DOS,Packer,Gerhard_Hoogterp,2:283/1.2
|
||||||
008C,RA-Echo,MS-DOS,Packer,Roger_Kirchhoff,2:245/4
|
008B,Tick,MS-DOS/OS2,Packer,Barry_Geller,1:266/12
|
||||||
008D,TrapToss,Amiga,Packer,Maximilian_Hantsch,2:310/6
|
008C,RA-Echo,MS-DOS,Packer,Roger_Kirchhoff,2:245/4
|
||||||
008E,Babel,MS-DOS/OS2,Packer,Jorgen_Abrahamsen,2:230/100.9
|
008D,TrapToss,Amiga,Packer,Maximilian_Hantsch,2:310/6
|
||||||
008F,UMS,Amiga,Packer,Martin_Horneffer,2:242/7.9
|
008E,Babel,MS-DOS/OS2,Packer,Jorgen_Abrahamsen,2:230/100.9
|
||||||
0090,RWMail,MS-DOS,Packer,Remko_Westrik,2:285/309.5
|
008F,UMS,Amiga,Packer,Martin_Horneffer,2:242/7.9
|
||||||
0091,WildMail,MS-DOS,Packer,Derek_Koopowitz,1:161/502
|
0090,RWMail,MS-DOS,Packer,Remko_Westrik,2:285/309.5
|
||||||
0092,AlMAIL,MS-DOS,Packer,Alan_Leung,1:348/207
|
0091,WildMail,MS-DOS,Packer,Derek_Koopowitz,1:161/502
|
||||||
0093,XCS,MS-DOS,Packer,Rudi_Kusters,2:512/34.4
|
0092,AlMAIL,MS-DOS,Packer,Alan_Leung,1:348/207
|
||||||
0094,Fone-Link,MS-DOS,Packer/mailer,Chris_Sloyan,1:269/602
|
0093,XCS,MS-DOS,Packer,Rudi_Kusters,2:512/34.4
|
||||||
0095,Dogfight,MS-DOS,Packer,Chris_Tyson,2:256/36
|
0094,Fone-Link,MS-DOS,Packer/mailer,Chris_Sloyan,1:269/602
|
||||||
0096,Ascan,MS-DOS,Packer,Arjen_van_Loon,2:281/1.397
|
0095,Dogfight,MS-DOS,Packer,Chris_Tyson,2:256/36
|
||||||
0097,FastMail,MS-DOS,Packer,Jan_Berends,2:282/5
|
0096,Ascan,MS-DOS,Packer,Arjen_van_Loon,2:281/1.397
|
||||||
0098,DoorMan,MS-DOS,Mailer,Christopher_Dean,1:105/70
|
0097,FastMail,MS-DOS,Packer,Jan_Berends,2:282/5
|
||||||
0099,PhaedoZap,Atari_ST,Packer,Jeff_Mitchell,1:229/422
|
0098,DoorMan,MS-DOS,Mailer,Christopher_Dean,1:105/70
|
||||||
009A,SCREAM,MS-DOS,Packer/mailer,Jem_Miller,1:147/33
|
0099,PhaedoZap,Atari_ST,Packer,Jeff_Mitchell,1:229/422
|
||||||
009B,MoonMail,MS-DOS,Packer/mailer,Hasse_Wigdahl,2:206/101
|
009A,SCREAM,MS-DOS,Packer/mailer,Jem_Miller,1:147/33
|
||||||
009C,Backdoor,Sinclair_QL,Packer,Erik_Slagter,2:283/500.3
|
009B,MoonMail,MS-DOS,Packer/mailer,Hasse_Wigdahl,2:206/101
|
||||||
009D,MailLink,Archimedes,Packer/mailer,Jan-Jaap_v._d._Geer,2:500/133.1138
|
009C,Backdoor,Sinclair_QL,Packer,Erik_Slagter,2:283/500.3
|
||||||
009E,Mail_Manager,MS-DOS,Packer,Andreas_Brodowski,2:241/4006
|
009D,MailLink,Archimedes,Packer/mailer,Jan-Jaap_v._d._Geer,2:500/133.1138
|
||||||
009F,Black_Star,Xenix_386,Packer/mailer,Jac_Kersing,2:283/333
|
009E,Mail_Manager,MS-DOS,Packer,Andreas_Brodowski,2:241/4006
|
||||||
00A0,Bermuda,Atari_ST/MS-DOS,Packer,Jac_Kersing,2:283/333
|
009F,Black_Star,Xenix_386,Packer/mailer,Jac_Kersing,2:283/333
|
||||||
00A1,PT,MS-DOS,Packer/mailer,Jerry_Andrew,1:109/426
|
00A0,Bermuda,Atari_ST/MS-DOS,Packer,Jac_Kersing,2:283/333
|
||||||
00A2,UltiMail,MS-DOS,Mailer,Brett_Floren,1:363/1000
|
00A1,PT,MS-DOS,Packer/mailer,Jerry_Andrew,1:109/426
|
||||||
00A3,GMD,MS-DOS,Packer,John_Souvestre,1:396/1
|
00A2,UltiMail,MS-DOS,Mailer,Brett_Floren,1:363/1000
|
||||||
00A4,FreeMail,MS-DOS,Packer,Chad_Nelson,1:109/536
|
00A3,GMD,MS-DOS,Packer,John_Souvestre,1:396/1
|
||||||
00A5,Meliora,MS-DOS,Packer,Erik_van_Riper,1:107/230
|
00A4,FreeMail,MS-DOS,Packer,Chad_Nelson,1:109/536
|
||||||
00A6,Foodo,CPM-80,Packer/mailer,Ron_Murray,3:690/640.7
|
00A5,Meliora,MS-DOS,Packer,Erik_van_Riper,1:107/230
|
||||||
00A7,MSBBS,CPM-80,Packer,Marc_Newman,1:106/601
|
00A6,Foodo,CPM-80,Packer/mailer,Ron_Murray,3:690/640.7
|
||||||
00A8,Boston_BBS,MS-DOS,Packer/mailer,Tom_Bradford,1:101/625
|
00A7,MSBBS,CPM-80,Packer,Marc_Newman,1:106/601
|
||||||
00A9,XenoMail,MS-DOS,Packer/mailer,Noah_Wood,1:284/14
|
00A8,Boston_BBS,MS-DOS,Packer/mailer,Tom_Bradford,1:101/625
|
||||||
00AA,XenoLink,Amiga,Packer/mailer,Jonathan_Forbes,1:250/642
|
00A9,XenoMail,MS-DOS,Packer/mailer,Noah_Wood,1:284/14
|
||||||
00AB,ObjectMatrix,MS-DOS,Packer,Roberto_Ceccarelli,2:332/305.1
|
00AA,XenoLink,Amiga,Packer/mailer,Jonathan_Forbes,1:250/642
|
||||||
00AC,Milquetoast,Win3/MS-DOS,Mailer,Vince_Perriello,1:343/491
|
00AB,ObjectMatrix,MS-DOS,Packer,Roberto_Ceccarelli,2:332/305.1
|
||||||
00AD,PipBase,MS-DOS,Packer,Roberto_Piola,2:334/306
|
00AC,Milquetoast,Win3/MS-DOS,Mailer,Vince_Perriello,1:343/491
|
||||||
00AE,EzyMail,MS-DOS,Packer,Peter_Davies,3:636/204
|
00AD,PipBase,MS-DOS,Packer,Roberto_Piola,2:334/306
|
||||||
00AF,FastEcho,MS-DOS,Packer,Tobias_Burchhardt,2:245/39
|
00AE,EzyMail,MS-DOS,Packer,Peter_Davies,3:636/204
|
||||||
00B0,IOS,Atari_ST/TT,Packer,Rinaldo_Visscher,2:280/3.1
|
00AF,FastEcho,MS-DOS,Packer,Tobias_Burchhardt,2:245/39
|
||||||
00B1,Communique,MS-DOS,Packer,Ian_Harris,3:620/251
|
00B0,IOS,Atari_ST/TT,Packer,Rinaldo_Visscher,2:280/3.1
|
||||||
00B2,PointMail,MS-DOS,Packer,Michele_Clinco,2:331/302.11
|
00B1,Communique,MS-DOS,Packer,Ian_Harris,3:620/251
|
||||||
00B3,Harvey's_Robot,MS-DOS,Packer,Harvey_Parisien,1:249/114
|
00B2,PointMail,MS-DOS,Packer,Michele_Clinco,2:331/302.11
|
||||||
00B4,2daPoint,MS-DOS,Packer,Ron_Pritchett,1:376/74
|
00B3,Harvey's_Robot,MS-DOS,Packer,Harvey_Parisien,1:249/114
|
||||||
00B5,CommLink,MS-DOS,Mailer,Steve_Shapiro,1:382/35
|
00B4,2daPoint,MS-DOS,Packer,Ron_Pritchett,1:376/74
|
||||||
00B6,fronttoss,MS-DOS,Packer,Dirk_Astrath,2:241/5603
|
00B5,CommLink,MS-DOS,Mailer,Steve_Shapiro,1:382/35
|
||||||
00B7,SysopPoint,MS-DOS,Packer,Rudolf_Heeb,2:243/44
|
00B6,fronttoss,MS-DOS,Packer,Dirk_Astrath,2:241/5603
|
||||||
00B8,PTMAIL,MS-DOS,Packer,Arturo_Krogulski,2:341/27.7
|
00B7,SysopPoint,MS-DOS,Packer,Rudolf_Heeb,2:243/44
|
||||||
00B9,MHS,MS-DOS/OS2/WINNT,Packer/mailer,Matthias_Hertzog,2:301/402,,19940310
|
00B8,PTMAIL,MS-DOS,Packer,Arturo_Krogulski,2:341/27.7
|
||||||
00BA,DLGMail,Amiga,Packer,Steve_Lewis,1:114/52
|
00B9,MHS,MS-DOS/OS2/WINNT,Packer/mailer,Matthias_Hertzog,2:301/402,,19940310
|
||||||
00BB,GatePrep,MS-DOS,Packer,Andrew_Allen,1:382/92
|
00BA,DLGMail,Amiga,Packer,Steve_Lewis,1:114/52
|
||||||
00BC,Spoint,MS-DOS,Packer,Conrad_Thompson,1:130/29.106
|
00BB,GatePrep,MS-DOS,Packer,Andrew_Allen,1:382/92
|
||||||
00BD,TurboMail,MS-DOS,Packer,B._J._Weschke,1:2606/403
|
00BC,Spoint,MS-DOS,Packer,Conrad_Thompson,1:130/29.106
|
||||||
00BE,FXMAIL,MS-DOS,Packer,Kenneth_Roach,1:208/401
|
00BD,TurboMail,MS-DOS,Packer,B._J._Weschke,1:2606/403
|
||||||
00BF,NextBBS,MS-DOS,Packer/mailer,Tomas_Hood,1:352/777
|
00BE,FXMAIL,MS-DOS,Packer,Kenneth_Roach,1:208/401
|
||||||
00C0,EchoToss,MS-DOS,Packer,Mikel_Beck,1:107/218
|
00BF,NextBBS,MS-DOS,Packer/mailer,Tomas_Hood,1:352/777
|
||||||
00C1,SilverBox,Amiga,Packer,David_Lebel,1:240/516
|
00C0,EchoToss,MS-DOS,Packer,Mikel_Beck,1:107/218
|
||||||
00C2,MBMail,MS-DOS,Packer,Ruud_Uphoff,2:500/116.1928
|
00C1,SilverBox,Amiga,Packer,David_Lebel,1:240/516
|
||||||
00C3,SkyFreq,Amiga,Packer,Luca_Spada,2:331/106
|
00C2,MBMail,MS-DOS,Packer,Ruud_Uphoff,2:500/116.1928
|
||||||
00C4,ProMailer,Amiga,Mailer,Ivan_Pintori,2:335/311.21
|
00C3,SkyFreq,Amiga,Packer,Luca_Spada,2:331/106
|
||||||
00C5,Mega_Mail,MS-DOS,Packer/mailer,Mirko_Mucko,2:242/94
|
00C4,ProMailer,Amiga,Mailer,Ivan_Pintori,2:335/311.21
|
||||||
00C6,YaBom,MS-DOS,Packer,Berin_Lautenbach,3:620/248
|
00C5,Mega_Mail,MS-DOS,Packer/mailer,Mirko_Mucko,2:242/94
|
||||||
00C7,TachEcho,MS-DOS,Packer,Tom_Zacios,1:107/376
|
00C6,YaBom,MS-DOS,Packer,Berin_Lautenbach,3:620/248
|
||||||
00C8,XAP,MS-DOS,Packer,Jeroen_Smulders,2:512/1.8
|
00C7,TachEcho,MS-DOS,Packer,Tom_Zacios,1:107/376
|
||||||
00C9,EZMAIL,MS-DOS,Packer,Torben_Paving,2:234/41
|
00C8,XAP,MS-DOS,Packer,Jeroen_Smulders,2:512/1.8
|
||||||
00CA,Arc-Binkley,Archimedes,Mailer,Geoff_Riley,2:250/208
|
00C9,EZMAIL,MS-DOS,Packer,Torben_Paving,2:234/41
|
||||||
00CB,Roser,MS-DOS,Packer,Chan_Kafai,6:700/158
|
00CA,Arc-Binkley,Archimedes,Mailer,Geoff_Riley,2:250/208
|
||||||
00CC,UU2,MS-DOS,Packer,Dmitri_Zavalishin,2:5020/32
|
00CB,Roser,MS-DOS,Packer,Chan_Kafai,6:700/158
|
||||||
00CD,NMS,MS-DOS,Packer/mailer,Michiel_de.Bruijn,2:285/505.2
|
00CC,UU2,MS-DOS,Packer,Dmitri_Zavalishin,2:5020/32
|
||||||
00CE,BBCSCAN,Archimedes,Packer/mailer,E._G._Snel,2:512/222.17
|
00CD,NMS,MS-DOS,Packer/mailer,Michiel_de.Bruijn,2:285/505.2
|
||||||
00CF,XBBS,MS-DOS,Packer,Mark_Kimes,1:380/16
|
00CE,BBCSCAN,Archimedes,Packer/mailer,E._G._Snel,2:512/222.17
|
||||||
00D0,LoTek_Vzrul,,Packer/mailer,Kevin_Gates,gates@sasknet.sk.ca,19951229,20000122
|
00CF,XBBS,MS-DOS,Packer,Mark_Kimes,1:380/16
|
||||||
00D1,Private_Point_Project,MS-DOS,Packer,Oliver_von_Bueren,2:301/701
|
00D0,LoTek_Vzrul,,Packer/mailer,Kevin_Gates,gates@sasknet.sk.ca,19951229,20000122
|
||||||
00D2,NoSnail,MS-DOS,Packer,Eddie_Rowe,1:19/124
|
00D1,Private_Point_Project,MS-DOS,Packer,Oliver_von_Bueren,2:301/701
|
||||||
00D3,SmlNet,MS-DOS,Packer,Steve_T._Gove,1:106/6
|
00D2,NoSnail,MS-DOS,Packer,Eddie_Rowe,1:19/124
|
||||||
00D4,STIR,MS-DOS,Packer,Paul_Martin,2:250/107.3
|
00D3,SmlNet,MS-DOS,Packer,Steve_T._Gove,1:106/6
|
||||||
00D5,RiscBBS,Archimedes,Packer,Carl_Declerck,2:292/500.10
|
00D4,STIR,MS-DOS,Packer,Paul_Martin,2:250/107.3
|
||||||
00D6,Hercules,Amiga,Packer/mailer,Andrew_Gray,1:231/590
|
00D5,RiscBBS,Archimedes,Packer,Carl_Declerck,2:292/500.10
|
||||||
00D7,AMPRGATE,MS-DOS,Packer/mailer,Mike_Bilow,1:323/120.1
|
00D6,Hercules,Amiga,Packer/mailer,Andrew_Gray,1:231/590
|
||||||
00D8,BinkEMSI,MS-DOS,Mailer,Tobias_Burchhardt,2:245/39
|
00D7,AMPRGATE,MS-DOS,Packer/mailer,Mike_Bilow,1:323/120.1
|
||||||
00D9,EditMsg,MS-DOS,Packer,G._K._Pace,1:374/26
|
00D8,BinkEMSI,MS-DOS,Mailer,Tobias_Burchhardt,2:245/39
|
||||||
00DA,Roof,Amiga,Packer,Robert_Williamson,1:167/104
|
00D9,EditMsg,MS-DOS,Packer,G._K._Pace,1:374/26
|
||||||
00DB,QwkPkt,MS-DOS,Packer,Ross_West,1:250/412
|
00DA,Roof,Amiga,Packer,Robert_Williamson,1:167/104
|
||||||
00DC,MARISCAN,MS-DOS,Packer,Mario_Elkati,2:341/14.9
|
00DB,QwkPkt,MS-DOS,Packer,Ross_West,1:250/412
|
||||||
00DD,NewsFlash,MS-DOS,Packer,Chris_Lueders,2:241/5306
|
00DC,MARISCAN,MS-DOS,Packer,Mario_Elkati,2:341/14.9
|
||||||
00DE,Paradise,MS-DOS,Packer/mailer,Kenneth_Wall,1:300/5
|
00DD,NewsFlash,MS-DOS,Packer,Chris_Lueders,2:241/5306
|
||||||
00DF,DogMatic-ACB,N/A,Packer/mailer,Martin_Allard,2:245/48
|
00DE,Paradise,MS-DOS,Packer/mailer,Kenneth_Wall,1:300/5
|
||||||
00E0,T-Mail,MS-DOS,Packer/mailer,Andy_Elkin,2:5030/15
|
00DF,DogMatic-ACB,N/A,Packer/mailer,Martin_Allard,2:245/48
|
||||||
00E1,JetMail,Atari_ST/STE/TT,Packer,Daniel_Roesen,2:243/93.8
|
00E0,T-Mail,MS-DOS,Packer/mailer,Andy_Elkin,2:5030/15
|
||||||
00E2,MainDoor,MS-DOS,Packer/mailer,Francisco_Sedano,2:341/20
|
00E1,JetMail,Atari_ST/STE/TT,Packer,Daniel_Roesen,2:243/93.8
|
||||||
00E3,Starnet_Products,MS-DOS/OS2,Mailer/Packer,Starnet_Software_Development,1:102/925,,19951209
|
00E2,MainDoor,MS-DOS,Packer/mailer,Francisco_Sedano,2:341/20
|
||||||
00E4,BMB,Amiga,Packer,Dentato_Remo,2:335/311.33
|
00E3,Starnet_Products,MS-DOS/OS2,Mailer/Packer,Starnet_Software_Development,1:102/925,,19951209
|
||||||
00E5,BNP,MS-DOS,Packer,Nathan_Moschkin,1:109/427
|
00E4,BMB,Amiga,Packer,Dentato_Remo,2:335/311.33
|
||||||
00E6,MailMaster,MS-DOS,Packer/mailer,Gary_Murphy,1:130/85
|
00E5,BNP,MS-DOS,Packer,Nathan_Moschkin,1:109/427
|
||||||
00E7,Mail_Manager_+Plus+,MS-DOS,Packer,Chip_Morrow,1:226/1240
|
00E6,MailMaster,MS-DOS,Packer/mailer,Gary_Murphy,1:130/85
|
||||||
00E8,BloufGate,Atari_ST/Unix,Packer,Vincent_Pomey,2:320/100.2
|
00E7,Mail_Manager_+Plus+,MS-DOS,Packer,Chip_Morrow,1:226/1240
|
||||||
00E9,CrossPoint,MS-DOS,Packer/mailer,Peter_Mandrella,2:2454/97.80,19920713,19960601
|
00E8,BloufGate,Atari_ST/Unix,Packer,Vincent_Pomey,2:320/100.2
|
||||||
00EA,DeltaEcho,MS-DOS,Packer,Mikael_Staldal,2:201/337
|
00E9,CrossPoint,MS-DOS,Packer/mailer,Peter_Mandrella,2:2454/97.80,19920713,19960601
|
||||||
00EB,ALLFIX,MS-DOS,Packer,Harald_Harms,2:512/145
|
00EA,DeltaEcho,MS-DOS,Packer,Mikael_Staldal,2:201/337
|
||||||
00EC,NetWay,Archimedes,Mailer,Steve_Haslam,2:250/116.3
|
00EB,ALLFIX,MS-DOS,Packer,Harald_Harms,2:512/145
|
||||||
00ED,MARSmail,Atari_ST,Packer,Folkert_val_Heusden,2:285/750.2,,19940122
|
00EC,NetWay,Archimedes,Mailer,Steve_Haslam,2:250/116.3
|
||||||
00EE,ITRACK,MS-DOS/OS2,Packer,Frank_Prade,2:2480/55,,19990119
|
00ED,MARSmail,Atari_ST,Packer,Folkert_val_Heusden,2:285/750.2,,19940122
|
||||||
00EF,GateUtil,MS-DOS,Packer,Michael_Skurka,1:397/2.1
|
00EE,ITRACK,MS-DOS/OS2,Packer,Frank_Prade,2:2480/55,,19990119
|
||||||
00F0,Bert,MS-DOS,Packer/mailer,Arnim_Wiezer,2:241/2104.9
|
00EF,GateUtil,MS-DOS,Packer,Michael_Skurka,1:397/2.1
|
||||||
00F1,Techno,MS-DOS,Packer,Patrik_Holmsten,2:203/133
|
00F0,Bert,MS-DOS,Packer/mailer,Arnim_Wiezer,2:241/2104.9
|
||||||
00F2,AutoMail,MS-DOS,Packer,Mats_Wallin,2:201/239
|
00F1,Techno,MS-DOS,Packer,Patrik_Holmsten,2:203/133
|
||||||
00F3,April,Amiga,Packer,Nick_de_Jong,2:282/309.3
|
00F2,AutoMail,MS-DOS,Packer,Mats_Wallin,2:201/239
|
||||||
00F4,Amanda,MS-DOS,Packer,David_Douthitt,1:121/99.14
|
00F3,April,Amiga,Packer,Nick_de_Jong,2:282/309.3
|
||||||
00F5,NmFwd,MS-DOS,Packer,Alberto_Pasquale,2:332/504
|
00F4,Amanda,MS-DOS,Packer,David_Douthitt,1:121/99.14
|
||||||
00F6,FileScan,MS-DOS,Packer,Matthias_Duesterhoeft,2:241/4512.2
|
00F5,NmFwd,MS-DOS,Packer,Alberto_Pasquale,2:332/504
|
||||||
00F7,FredMail,MS-DOS,Packer,Michael_Butler,3:712/515
|
00F6,FileScan,MS-DOS,Packer,Matthias_Duesterhoeft,2:241/4512.2
|
||||||
00F8,TP_Kom,MS-DOS,Packer/mailer,Per_Sten,2:201/124
|
00F7,FredMail,MS-DOS,Packer,Michael_Butler,3:712/515
|
||||||
00F9,FidoZerb,MS-DOS,Packer,Ulrich_Schlechte,2:241/3410.12
|
00F8,TP_Kom,MS-DOS,Packer/mailer,Per_Sten,2:201/124
|
||||||
00FA,!!MessageBase,MS-DOS,Packer/mailer,Holger_Lembke,2:240/500.20
|
00F9,FidoZerb,MS-DOS,Packer,Ulrich_Schlechte,2:241/3410.12
|
||||||
00FB,EMFido,Amiga,Packer,Gary_Glendown,2:249/3.999
|
00FA,!!MessageBase,MS-DOS,Packer/mailer,Holger_Lembke,2:240/500.20
|
||||||
00FC,GS-Toss,MS-DOS,Packer,Marco_Bungalski,2:241/2021
|
00FB,EMFido,Amiga,Packer,Gary_Glendown,2:249/3.999
|
||||||
00FD,QWKDoor,Atari_ST,Packer,Christian_Limpach,2:270/20.1
|
00FC,GS-Toss,MS-DOS,Packer,Marco_Bungalski,2:241/2021
|
||||||
00FE,No_product_id_allocated,Any,Packer,No_Author,3:3/20
|
00FD,QWKDoor,Atari_ST,Packer,Christian_Limpach,2:270/20.1
|
||||||
00FF,16-bit_product_id,Any,Packer/Mailer,No_Author,3:3/20
|
00FE,No_product_id_allocated,Any,Packer,No_Author,3:3/20
|
||||||
0100,Reserved,None,None,No_Author,3:3/20,19951209
|
00FF,16-bit_product_id,Any,Packer/Mailer,No_Author,3:3/20
|
||||||
0101,The_Brake!,Mailer,John_Gladkih,2:5051/16,19951209
|
0100,Reserved,None,None,No_Author,3:3/20,19951209
|
||||||
0102,Zeus_BBS,Amiga,Mailer,Alex_May,2:441/58.0,19951209
|
0101,The_Brake!,Mailer,John_Gladkih,2:5051/16,19951209
|
||||||
0103,XenoPhobe-Mailer,Msdos/Windows/OS2/Linux,Mailer,Peter_Kling,1:374/969.0,19951209
|
0102,Zeus_BBS,Amiga,Mailer,Alex_May,2:441/58.0,19951209
|
||||||
0104,None,None,None,None,0:0/0,
|
0103,XenoPhobe-Mailer,Msdos/Windows/OS2/Linux,Mailer,Peter_Kling,1:374/969.0,19951209
|
||||||
0105,Terminate,Msdos/Os2/Windows,Mailer/Packer,SerWiz_Comm_&_Bo_Bendtsen,2:254/261,19951209
|
0104,None,None,None,None,0:0/0,
|
||||||
0106,TeleMail,Msdos,Mailer/Packer,Juergen_Weigelt,2:2453/900,19951209
|
0105,Terminate,Msdos/Os2/Windows,Mailer/Packer,SerWiz_Comm_&_Bo_Bendtsen,2:254/261,19951209
|
||||||
0107,CMBBS,Msdos/Os2,Mailer/Packer,Christof_Engel,2:2490/5110,19951209
|
0106,TeleMail,Msdos,Mailer/Packer,Juergen_Weigelt,2:2453/900,19951209
|
||||||
0108,Shuttle,Windows,Mailer/Packer,MCH_Development_&_Marvin_Hart,1:106/500,19951209
|
0107,CMBBS,Msdos/Os2,Mailer/Packer,Christof_Engel,2:2490/5110,19951209
|
||||||
0109,Quater,Amiga,Mailer,Felice_Murolo,2:335/206,19951209
|
0108,Shuttle,Windows,Mailer/Packer,MCH_Development_&_Marvin_Hart,1:106/500,19951209
|
||||||
010A,Windo,Windows,Mailer,Alan_Chavis,1:147/55,19951209
|
0109,Quater,Amiga,Mailer,Felice_Murolo,2:335/206,19951209
|
||||||
010B,Xenia,Msdos/Os2,Mailer,Arjen_Lentz,2:283/512,19960601
|
010A,Windo,Windows,Mailer,Alan_Chavis,1:147/55,19951209
|
||||||
010C,GMS,AmigaOS,Mailer,Mirko_Viviani,2:331/213,19960601
|
010B,Xenia,Msdos/Os2,Mailer,Arjen_Lentz,2:283/512,19960601
|
||||||
010D,HNET,Msdos,???,Pedro_Jaramillo,1:102/160,19960601
|
010C,GMS,AmigaOS,Mailer,Mirko_Viviani,2:331/213,19960601
|
||||||
010E,Shotgun_Professional,Msdos,???,Brent_Shellenberg,1:140/146,19960621
|
010D,HNET,Msdos,???,Pedro_Jaramillo,1:102/160,19960601
|
||||||
010F,SLIPgate,Msdos,???,Kieran_Morrissey,3:634/376,19960723
|
010E,Shotgun_Professional,Msdos,???,Brent_Shellenberg,1:140/146,19960621
|
||||||
0110,BBBS,MSDOS/OS2/NT/Amiga/Unix,Mailer/Packer,Kim_Heino,2:22/222,19980216
|
010F,SLIPgate,Msdos,???,Kieran_Morrissey,3:634/376,19960723
|
||||||
0111,NewsGate,Windows/NT,Packer/Gateway,Leilo_denna_Pietra,2:335/244,19980216
|
0110,BBBS,MSDOS/OS2/NT/Amiga/Unix,Mailer/Packer,Kim_Heino,2:22/222,19980216
|
||||||
01FF,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
|
||||||
02FF,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
|
||||||
03FF,Ravel,Macintosh,Mailer/Packer,Cyril_Moorzin,2:5030/700,19980310
|
02FF,NewsGate,Windows/NT,Packer/Gateway,Leilo_denna_Pietra,2:335/244,19980216
|
||||||
04FF,Beemail,Windows,Mailer/Packer,Andrius_Cepaitis,2:470/1,19980310
|
03FF,Ravel,Macintosh,Mailer/Packer,Cyril_Moorzin,2:5030/700,19980310
|
||||||
05FF,QuickToss,DOS,Packer,Sandra_Godinez,1:387/601.3,19980310
|
04FF,Beemail,Windows,Mailer/Packer,Andrius_Cepaitis,2:470/1,19980310
|
||||||
06FF,SpaceMail,???,Mailer,Andreas_Habicht,2:244/6121,19980710
|
05FF,QuickToss,DOS,Packer,Sandra_Godinez,1:387/601.3,19980310
|
||||||
07FF,Argus,Windows/NT,Mailer,Max_Masyutin,2:469/84,19990216
|
06FF,SpaceMail,???,Mailer,Andreas_Habicht,2:244/6121,19980710
|
||||||
08FF,Hurricane,Windows/NT/Solaris,Packer,Paul_Walker,2:254/175.44,19990216
|
07FF,Argus,Windows/NT,Mailer,Max_Masyutin,2:469/84,19990216
|
||||||
09FF,Hub_Mailer,OS2,Mailer,Viatcheslav_Odintsov,2:5020/181,19990216
|
08FF,Hurricane,Windows/NT/Solaris,Packer,Paul_Walker,2:254/175.44,19990216
|
||||||
0AFF,FDInt,MSDOS,Packer,Colin_Turner,2:443/13,19990216
|
09FF,Hub_Mailer,OS2,Mailer,Viatcheslav_Odintsov,2:5020/181,19990216
|
||||||
0BFF,GPMail,OS2,Mailer,Igor_Vanin,2:5030/448,19990216
|
0AFF,FDInt,MSDOS,Packer,Colin_Turner,2:443/13,19990216
|
||||||
0CFF,FTrack,NT/OS2,Tracker,Fyodor_Ustinov,2:5020/79,19990313
|
0BFF,GPMail,OS2,Mailer,Igor_Vanin,2:5030/448,19990216
|
||||||
0DFF,Nice_Tosser,DOS/OS2/Win32,Tosser,Robert_Agababyan,2:5020/234.1,19990518
|
0CFF,FTrack,NT/OS2,Tracker,Fyodor_Ustinov,2:5020/79,19990313
|
||||||
0EFF,LuckyGate,DOS/OS2/Linux,Packer,Pavel_Gulchouck,2:463/68,19990709
|
0DFF,Nice_Tosser,DOS/OS2/Win32,Tosser,Robert_Agababyan,2:5020/234.1,19990518
|
||||||
0FFF,McMail,DOS,Mailer,Simon_Slater,2:443/777,20000102
|
0EFF,LuckyGate,DOS/OS2/Linux,Packer,Pavel_Gulchouck,2:463/68,19990709
|
||||||
</PRE>
|
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>
|
|
||||||
|
<A HREF="./"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
|
||||||
</BODY>
|
|
||||||
</HTML>
|
</BODY>
|
||||||
|
</HTML>
|
||||||
|
|
||||||
|
|||||||
@ -1,4 +1,5 @@
|
|||||||
<HTML>
|
<HTML>
|
||||||
|
<!-- $Id$ -->
|
||||||
<HEAD>
|
<HEAD>
|
||||||
<META http-equiv="Content-Type" content="text/html; charset=ISO 8859-1">
|
<META http-equiv="Content-Type" content="text/html; charset=ISO 8859-1">
|
||||||
<META http-equiv="Content-Style-Type" content="text/css">
|
<META http-equiv="Content-Style-Type" content="text/css">
|
||||||
@ -94,7 +95,7 @@ Michiel Broek.
|
|||||||
|
|
||||||
<HR>
|
<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>
|
</BLOCKQUOTE>
|
||||||
</BODY>
|
</BODY>
|
||||||
</HTML>
|
</HTML>
|
||||||
|
|||||||
Reference in New Issue
Block a user