1606 lines
67 KiB
Plaintext
1606 lines
67 KiB
Plaintext
F I D O N E W S Volume 16, Number 13 29 March 1999
|
|
+----------------------------+---------------------------------------+
|
|
| The newsletter of the | ISSN 1198-4589 Published by: |
|
|
| FidoNet community | "FidoNews" |
|
|
| _ | +27-41-581-5913 [5:5/23] |
|
|
| / \ | |
|
|
| /|oo \ | |
|
|
| (_| /_) | |
|
|
| _`@/_ \ _ | |
|
|
| | | \ \\ | Editor: |
|
|
| | (*) | \ )) | Henk Wolsink 5:7104/2 |
|
|
| |__U__| / \// | |
|
|
| _//|| _\ / | |
|
|
| (_/(_|(____/ | |
|
|
| (jm) | Newspapers should have no friends. |
|
|
| | -- JOSEPH PULITZER |
|
|
+----------------------------+---------------------------------------+
|
|
| Submission address: FidoNews Editor 5:5/23 |
|
|
+--------------------------------------------------------------------+
|
|
| MORE addresses: |
|
|
| |
|
|
| submissions=> editor@fidonews.org |
|
|
| hwolsink@catpe.alt.za |
|
|
+--------------------------------------------------------------------+
|
|
| For information, copyrights, article submissions, |
|
|
| obtaining copies of FidoNews or the internet gateway FAQ |
|
|
| please refer to the end of this file. |
|
|
+--------------------------------------------------------------------+
|
|
|
|
|
|
Table of Contents
|
|
1. EDITORIAL ................................................ 1
|
|
2. ARTICLES ................................................. 2
|
|
Internet newsgroup<>echomail ............................. 2
|
|
Packet type 2 ............................................ 3
|
|
3. COLUMNS .................................................. 21
|
|
What's Not Happening: Tag-Teams ......................... 21
|
|
4. NOTICES .................................................. 23
|
|
5. FIDONET BY INTERNET ...................................... 24
|
|
6. FIDONEWS INFORMATION ..................................... 28
|
|
FIDONEWS 16-13 Page 1 29 Mar 1999
|
|
|
|
|
|
=================================================================
|
|
EDITORIAL
|
|
=================================================================
|
|
|
|
Greetings,
|
|
|
|
Our summer is comming to an end, with temperatures back to normal. ;-)
|
|
What is normal you may ask? Temperatures acceptable to us humans that
|
|
is.
|
|
|
|
Happy reading,
|
|
|
|
-----------------------------------------------------------------
|
|
|
|
FIDONEWS 16-13 Page 2 29 Mar 1999
|
|
|
|
|
|
=================================================================
|
|
ARTICLES
|
|
=================================================================
|
|
|
|
|
|
Internet newsgroup<>echomail gating service now available
|
|
By Joe Jared (1:103/301@fidonet) joejared@webworldinc.com
|
|
|
|
Special thanks to Remarq.com, (formerly supernews.com) for making
|
|
control messages available to me for creation of newsgroups. If what
|
|
I'm told is correct on this topic, newsgroups once added, are global
|
|
in scope.
|
|
|
|
TO ANY MODERATORS INTERESTED:
|
|
|
|
Your echo can be gated to the internet
|
|
on request. To initiate gating of your echo, simply send netmail or
|
|
an email to one of my addresses as listed above and respond to the
|
|
confirmation message. Once the echo has successfully be made global,
|
|
the moderator may assume the gating duties assuming software is
|
|
available to do so. The software I am currently using is compatable
|
|
with most news servers and works with Windows 95/98/NT and is
|
|
freeware. The key solutions however in performing this gateway are
|
|
available from newsgate@webworldinc.com, a listserv open to all.
|
|
|
|
The structure as the echo would appear on the internet would be
|
|
fidonet.*, where the * is the name of your echo. In some cases, it
|
|
may appear as fidonet.name.*, replacing the underscores '_' with dots
|
|
if deemed appropriate to the heirarchy. For example:
|
|
|
|
SIP_ACA would be mapped to fidonet.sip.aca, because it is a part of a
|
|
group of echoes preceded with the keyword SIP.
|
|
|
|
Your message as the moderator of an echo would need to include
|
|
heirarchy if it's not readily visible as well as a request to have it
|
|
added to internet distribution. I will then respond to the elisted
|
|
moderator address for all cases except where the moderator is a known
|
|
highjacker, in which case the recognized moderator will take
|
|
precedence. No gated echo need be elisted but it would make things
|
|
easier for me if you as moderator elisted the echo.
|
|
|
|
If you are in contact with moderators of other newsgroups and would
|
|
like your echomail conference merged with their newsgroup, a request
|
|
from both moderators are required, and can be broken on request by
|
|
either party.
|
|
|
|
As a moderator the ONLY requests honored will be to add "known"
|
|
spammers to the kill list, and to add and remove it from internet
|
|
distribution. The object of this gateway is to improve the volume of
|
|
traffic while minimizing some of the hazards (Spam, Viruses, trojans,
|
|
twits etc). A gated echo will disappear from distribution if it is
|
|
deemed to be a problematic echo (I.E. too much used cowfood involved
|
|
in distributing it). This service is free and as such should have
|
|
reasonable expectations. Initially this system will be limited in
|
|
terms of echoes that can be gated (I'm using soon to be replaced and
|
|
outdated tosser that only supports 2048 echoes), but I doubt this will
|
|
FIDONEWS 16-13 Page 3 29 Mar 1999
|
|
|
|
|
|
be a problem for a few months.
|
|
|
|
As a final note, once mail leaves or enters fidonet, it is no longer
|
|
bound by policy4, nor can it be expected to, as it is no longer just
|
|
fidonet mail. The gateway assumes no liablity for traffic whether it
|
|
be legal or otherwise and will take prompt action once notified of an
|
|
repeated offense, but it cannot be expected that all internet gated
|
|
echoes will be free of clutter. One a positive note however, your
|
|
echomail area will receive the exposure that it desperately needs to
|
|
thrive and grow.
|
|
|
|
|
|
-----------------------------------------------------------------
|
|
|
|
|
|
Packet type 2, draft 990328
|
|
by Goran Eriksson, 2:201/505, get@get.pp.se
|
|
|
|
|
|
It seems to be the general opinion among FTSC members that packet type
|
|
2+ (and possibly others like packet type 2.2 and the packet type
|
|
proposed by FSC-48) should receive FTS status.
|
|
|
|
To prepare for this I have written a document describing packet type 2
|
|
as this is the basis for all of these other packet types.
|
|
|
|
I do not expect this document to be included verbatim into a new FTS.
|
|
Neither for packet type 2, nor for the other packet types.
|
|
|
|
However, I hope that the FTSC will find my document useful enough to
|
|
build the new FTS documents upon it.
|
|
|
|
Therfore, I will post my latest draft in the following messages and
|
|
invite you to comment on it in the NET_DEV echomail conference.
|
|
|
|
English is a foreign language to me. Purely linguistic remarks are
|
|
welcome, but please send them to me by netmail or e-mail.
|
|
|
|
|
|
1. General
|
|
|
|
A packet file of type 2 has the following general layout
|
|
|
|
---------------------
|
|
| Packet header |
|
|
---------------------
|
|
| Packed message |
|
|
---------------------
|
|
: :
|
|
---------------------
|
|
| Packed message |
|
|
---------------------
|
|
| Packet terminator |
|
|
---------------------
|
|
|
|
The number of packed messages may be 0 or more.
|
|
FIDONEWS 16-13 Page 4 29 Mar 1999
|
|
|
|
|
|
2. Packet header
|
|
|
|
2.1. General
|
|
|
|
The packet header of a packet file of type 2 has the following
|
|
general layout
|
|
|
|
Relative byte offset Size in bytes
|
|
-----------------------
|
|
0 00H | Origin Node | 2
|
|
-----------------------
|
|
2 02H | Destination Node | 2
|
|
-----------------------
|
|
4 04H | Year | 2
|
|
-----------------------
|
|
6 06H | Month | 2
|
|
-----------------------
|
|
8 08H | Day | 2
|
|
-----------------------
|
|
10 0AH | Hour | 2
|
|
-----------------------
|
|
12 0CH | Minute | 2
|
|
-----------------------
|
|
14 0EH | Second | 2
|
|
-----------------------
|
|
16 10H | Baud Rate | 2
|
|
-----------------------
|
|
18 12H | Packet Type | 1
|
|
-----------------------
|
|
20 14H | Origin Net | 2
|
|
-----------------------
|
|
22 16H | Destination Net | 2
|
|
-----------------------
|
|
24 18H | Product Code | 1
|
|
-----------------------
|
|
25 19H | Serial Number | 1
|
|
-----------------------
|
|
26 1AH | Password | 8
|
|
-----------------------
|
|
34 22H | Origin zone | 2
|
|
-----------------------
|
|
36 24H | Destination zone | 2
|
|
-----------------------
|
|
38 26H | Reserved | 20
|
|
-----------------------
|
|
|
|
The total size of the packet header is 58 bytes.
|
|
|
|
|
|
2.2. Origin Node
|
|
This field contains information about the node number of the system
|
|
having created the packet. The field contains a 16-bit binary unsigned
|
|
integer in the range 0-65535.
|
|
|
|
See notes 1 and 2.
|
|
|
|
FIDONEWS 16-13 Page 5 29 Mar 1999
|
|
|
|
|
|
2.3. Destination Node
|
|
This field contains information about the node number of the system
|
|
for which the packet was created. The field contains a 16-bit binary
|
|
unsigned integer in the range 0-65535.
|
|
|
|
See notes 1 and 2.
|
|
|
|
2.4. Year
|
|
This field contains information about the year when the packet was
|
|
created. The field contains a 16-bit binary unsigned integer in the
|
|
range 0-66535.
|
|
|
|
See notes 2 and 3.
|
|
|
|
2.5. Month
|
|
This field contains information about the month when the packet was
|
|
created. The field contains an 8-bit binary unsigned integer in the
|
|
range 0-11. The following representation is used:
|
|
|
|
Month represented as
|
|
January 0
|
|
February 1
|
|
March 2
|
|
April 3
|
|
May 4
|
|
June 5
|
|
July 6
|
|
August 7
|
|
September 8
|
|
October 9
|
|
November 10
|
|
December 11
|
|
|
|
See note 3.
|
|
|
|
2.6. Day
|
|
This field contains information about the day when the packet was
|
|
created. The field contains an 8-bit binary unsigned integer in the
|
|
range 1-31.
|
|
|
|
See note 3.
|
|
|
|
2.7. Hour
|
|
This field contains information about the hour when the packet was
|
|
created. The field contains an 8-bit binary unsigned integer in the
|
|
range 0-23.
|
|
|
|
See note 3.
|
|
|
|
2.8. Minute
|
|
This field contains information about the minute when the packet was
|
|
created. The field contains an 8-bit binary unsigned integer in the
|
|
range 0-59.
|
|
|
|
See note 3.
|
|
|
|
FIDONEWS 16-13 Page 6 29 Mar 1999
|
|
|
|
|
|
2.9. Second
|
|
This field contains information about the second when the packet was
|
|
created. The field contains an 8-bit binary unsigned integer in the
|
|
range 0-59.
|
|
|
|
See note 3.
|
|
|
|
2.10. Baud Rate
|
|
This field is filled with the 16-bit binary unsigned integer 0 by the
|
|
system creating the packet. Any system receiving the packet may ignore
|
|
the value of this field. For historical reasons this field is called
|
|
Baud Rate.
|
|
|
|
See note 2.
|
|
|
|
2.11. Packet Type
|
|
This field is filled with the 16-bit binary unsigned integer 2 by the
|
|
system creating the packet. Any system receiving the packet should
|
|
check the contents of this field. If it does not contain the 16-bit
|
|
binary unsigned integer 2 it is recommanded that the receiving system
|
|
regards it unsafe to unpack this packet according to the format
|
|
specification for packet type 2. Any further actions by the receiving
|
|
system in this case are left to the implementation.
|
|
|
|
See note 2.
|
|
|
|
2.12. Origin Net
|
|
This field contains information about the net number of the system
|
|
having created the packet. The field contains a 16-bit binary unsigned
|
|
integer in the range 1-65535.
|
|
|
|
See notes 1 and 2.
|
|
|
|
2.13. Destination Net
|
|
This field contains information about the net number of the system for
|
|
which the packet was created. The field contains a 16-bit binary
|
|
unsigned integer in the range 1-65535.
|
|
|
|
See notes 1 and 2.
|
|
|
|
2.14. Product Code
|
|
This field contains information about the product code assigned to the
|
|
programme creating the packet. The field contains an 8-bit binary
|
|
unsigned integer in the range 0-255.
|
|
|
|
Product codes are assigned to programmes by the FTSC. See FTA-1005.
|
|
That document also contains information about what product codes to
|
|
use by programmes which have not yet been assigned a product code by
|
|
the FTSC.
|
|
|
|
2.15. Serial Number
|
|
This field may contain information about the serial number of the
|
|
programme creating the packet. The field contains a 8-bit binary
|
|
unsigned integer in the range 0-255. If a programme does not want to
|
|
assign any serial number to this field it should fill this field with
|
|
the 8-bit binary unsigned integer 0.
|
|
FIDONEWS 16-13 Page 7 29 Mar 1999
|
|
|
|
|
|
2.16. Password
|
|
This field contains information about a packet level password. The
|
|
field contains an array of 0-8 ASCII characters, each in the range
|
|
'0'..'9', 'A'..'Z'. The programme creating the packet should fill all
|
|
unused bytes in this field with the 8-bit binary unsigned value 0. Any
|
|
programme receiving a packet should ignore any bytes in this field
|
|
after the first occurence of an byte with the value 0. The comparison
|
|
of passwords in a received packet file is done case insensitively.
|
|
|
|
Any programme receiving a packet with a password differing from the
|
|
password set up between the system having created the packet and the
|
|
system receiving it (including the absence of a password when one has
|
|
been agreed upon) should consider the information contained in the
|
|
packet about the system that has created as unreliable. Any further
|
|
actions by the receiving system in this case are left to each
|
|
implementation.
|
|
|
|
See note 5.
|
|
|
|
2.17. Origin Zone
|
|
This field may contain information about the zone number of the system
|
|
having created the packet. The field contains a 16-bit binary unsigned
|
|
integer in the range 1-65535. If a programme does not wish to enter a
|
|
zone number into this field it should fill it with the 16-bit binary
|
|
unsigned value 0.
|
|
|
|
See notes 1, 2 and 4.
|
|
|
|
2.18. Destination Zone
|
|
This field may contain information about the zone number of the system
|
|
for which the packet was created. The field contains a 16-bit binary
|
|
unsigned integer in the range 1-65535. If a programme does not wish to
|
|
enter a zone number into this field it should fill it with the 16-bit
|
|
binary unsigned value 0.
|
|
|
|
See notes 1, 2 and 4.
|
|
|
|
2.19. Reserved
|
|
This field is filled by the programme creating the packet with an
|
|
array of bytes with the 8-bit binary unsigned value 0. Any programme
|
|
receiving a packet should ignore the contents of this field.
|
|
|
|
|
|
3. Packed message format
|
|
|
|
3.1. General
|
|
The packed message in a packet file of type 2 has the following
|
|
general layout
|
|
|
|
Relative byte offset
|
|
-----------------------
|
|
0 00H | Packet Type |
|
|
-----------------------
|
|
2 02H | Origin Node |
|
|
-----------------------
|
|
4 04H | Destination Node |
|
|
FIDONEWS 16-13 Page 8 29 Mar 1999
|
|
|
|
|
|
-----------------------
|
|
6 06H | Origin Net |
|
|
-----------------------
|
|
8 08H | Destination Net |
|
|
-----------------------
|
|
10 0AH | Attribute |
|
|
-----------------------
|
|
12 0CH | Cost |
|
|
-----------------------
|
|
14 0EH | Date and Time |
|
|
-----------------------
|
|
34 22H | To-name |
|
|
-----------------------
|
|
| From-name |
|
|
-----------------------
|
|
| Subject |
|
|
-----------------------
|
|
| Message body |
|
|
-----------------------
|
|
|
|
The total size of the packed message is variable.
|
|
|
|
3.2. Packet Type
|
|
This field is filled with the 16-bit binary unsigned integer 2 by the
|
|
system creating the packet. Any system receiving the packet should
|
|
check the contents of this field. If it does not contain the 16-bit
|
|
binary unsigned integer 2 it is recommanded that the receiving system
|
|
regards it unsafe to unpack this packet according to the format
|
|
specification for packet type 2. Any further actions by the receiving
|
|
system in this case are left to the implementation.
|
|
|
|
See note 2.
|
|
|
|
3.3. Origin Node
|
|
This field contains information about the node number of the system
|
|
having created the message. The field contains a 16-bit binary
|
|
unsigned integer in the range 0-65535.
|
|
|
|
See notes 1 and 2.
|
|
|
|
3.4. Destination Node
|
|
This field contains information about the node number of the system
|
|
for which the message was created. The field contains a 16-bit binary
|
|
unsigned integer in the range 0-65535.
|
|
|
|
See notes 1 and 2.
|
|
|
|
3.5. Origin Net
|
|
This field contains information about the net number of the system
|
|
having created the message. The field contains a 16-bit binary
|
|
unsigned integer in the range 1-65535.
|
|
|
|
See notes 1 and 2.
|
|
|
|
3.6. Destination Net
|
|
This field contains information about the net number of the system for
|
|
FIDONEWS 16-13 Page 9 29 Mar 1999
|
|
|
|
|
|
which the message was created. The field contains a 16-bit binary
|
|
unsigned integer in the range 1-65535.
|
|
|
|
See notes 1 and 2.
|
|
|
|
3.7. Attribute
|
|
This field contains information about the attributes assigned to the
|
|
message in question. This field is treated as a 16-bit bit mapped flag
|
|
field with the following assignments:
|
|
|
|
Bit Meaning
|
|
--- -------
|
|
0 Private
|
|
1 Crash
|
|
4 File Attached
|
|
10 Reserved
|
|
11 File Request
|
|
12 Return Receipt Request
|
|
13 Is Return Receipt
|
|
14 Audit Request
|
|
15 File Update Request
|
|
|
|
See note 2.
|
|
|
|
3.7.1. Private
|
|
When this attribute is set the message is considered private and
|
|
intended for the addressee only. See a separate document for the use
|
|
of the Private attribute in echomail messages.
|
|
|
|
3.7.2. Crash
|
|
When this attribute is set the message is considered high-priority. A
|
|
system that encounters a message with the Crash attribute set normally
|
|
makes an effort to speed the delivery of the message in question if it
|
|
is not intended for the own system. However, the actions actually to
|
|
be taken upon receipt of a message with the Crash attribute set is
|
|
left to each implementation.
|
|
|
|
3.7.3. File Attached
|
|
When this attribute is set it is supposed that one or more files are
|
|
attached to the message. The files are transferred separately from the
|
|
packet file in which the message with the File Attached attribute is
|
|
contained. See also 3.12.1.
|
|
|
|
A message with the File Attached attribute set may contain a message
|
|
body.
|
|
|
|
Normally a message with the File Attached attribute set must be sent
|
|
directly to the destination system since ftn systems usually are not
|
|
set up for the routing of non-mail files.
|
|
|
|
3.7.4. Reserved
|
|
This attribute bit is reserved for future use. It should not be
|
|
checked by a programme receiving a type 2 packet.
|
|
|
|
3.7.5. File Request
|
|
When this attribute is set it is supposed that one or more files are
|
|
FIDONEWS 16-13 Page 10 29 Mar 1999
|
|
|
|
|
|
requested from the desination system of to the message. See also
|
|
3.12.1.
|
|
|
|
A message with the File Request attribute set may contain a message
|
|
body.
|
|
|
|
Normally a message with the File Request attribute set must be sent
|
|
directly to the destination system since ftn systems usually are not
|
|
set up for the routing of non-mail files.
|
|
|
|
3.7.6. Return Receipt Request
|
|
When this attribute is set it is assumed that the sender of the
|
|
message requests a return receipt. A Return Receipt in this connection
|
|
means a receipt from the final destination system that the message has
|
|
arrived there. It is left to each implementation what steps to take
|
|
when a message with the Return Receipt Request attribute bit is
|
|
received.
|
|
|
|
3.7.7. Is Return Receipt
|
|
When this attribute is set it is assumed that the message in question
|
|
is a return receipt. It is left to each implementation what steps to
|
|
take when a message with the Is Return Receipt attribute bit is
|
|
received.
|
|
|
|
3.7.8. Is Audit Request
|
|
When this attribute is set it is assumed that the sender of the
|
|
message requests audit receipts. An Atuidt Receipt in this connection
|
|
means a receipt from each of the systems transporting the message in
|
|
question on its way to the final destination that the message has
|
|
passed there. It is left to each implementation what steps to take
|
|
when a message with the Is Audit Request attribute bit is received.
|
|
|
|
3.7.9. File Update Request
|
|
When this attribute is set it is supposed that a file update is
|
|
requested from the desination system of to the message. See also
|
|
3.12.1.
|
|
|
|
A message with the File Update Request attribute set may contain a
|
|
message body.
|
|
|
|
Normally a message with the File Update Request attribute set must be
|
|
sent directly to the destination system since ftn systems usually are
|
|
not set up for the routing of non-mail files.
|
|
|
|
3.7.10. Attribute bits 2-3, 5-9
|
|
Any programme creating a packet may set bits 2-3 and 5-9 in the
|
|
message attribute field to 0. They should not be checked by a
|
|
programme receiving a type 2 packet.
|
|
|
|
These attribute bits are normally only used for information
|
|
interchange between different programmes on the system where the
|
|
message in question is created.
|
|
|
|
3.8. Cost
|
|
This field is filled with the 16-bit binary unsigned integer 0 by the
|
|
system creating the packet. Any system receiving the packet may ignore
|
|
FIDONEWS 16-13 Page 11 29 Mar 1999
|
|
|
|
|
|
the value of this field. For historical reasons this field is called
|
|
Cost.
|
|
|
|
See note 2.
|
|
|
|
3.9. Date and Time
|
|
This field is filled with a <NUL>-terminated ASCII character string
|
|
representing the date and the time when the message in question was
|
|
created.
|
|
|
|
The string has the following format
|
|
|
|
DD " " Month " " YY " " " " HH ":" MM ":" SS <NUL>
|
|
|
|
where
|
|
|
|
DD = "01" | "02" | "03" | ... | "31"
|
|
Month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" |
|
|
"Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"
|
|
YY = "01" | "02" | .. | "85" | "86" | ... | "99" | "00"
|
|
HH = "00" | .. | "23"
|
|
MM = "00" | .. | "59"
|
|
SS = "00" | .. | "59"
|
|
|
|
The representation of the year contains the two last digits of the
|
|
year in question. E.g. the year 1999 is represented as "99" and the
|
|
year 2000 as "00".
|
|
|
|
Considering the time when packet type 2 was first put into use, values
|
|
"80".."99" is assumed to represent 1980..1999 and values "00".."79" is
|
|
assumed to represent 2000..2079.
|
|
|
|
The length of the string is 20 characters including the <NUL>
|
|
termination.
|
|
|
|
See note 3.
|
|
|
|
3.10. To-name
|
|
This variable length field is filled with the <NUL>-terminated
|
|
character string representing the name of the addressee of the message
|
|
in question. In the case the programme creating the packet does not
|
|
want to put any actual name there, the field should be filled with a
|
|
single <NUL> character. The maximum length of the string is 36
|
|
characters including the <NUL> termination. E.g. the name Jim Brown is
|
|
represented as "Jim Brown"<NUL>.
|
|
|
|
The character set used in this field is the same as given in the
|
|
message body (see a separate document). If no character set is given
|
|
there, the ASCII character set is used.
|
|
|
|
Character codes 1..31 may not be used within this field.
|
|
|
|
3.11. From-name
|
|
This variable length field is filled with the <NUL>-terminated
|
|
character string representing the name of the sender of the message in
|
|
question. In the case the programme creating the packet does not want
|
|
FIDONEWS 16-13 Page 12 29 Mar 1999
|
|
|
|
|
|
to put any actual name there, the field should be filled with a single
|
|
<NUL> character. The maximum length of the string is 36 characters
|
|
including the <NUL> termination. E.g. the name Jim Brown is
|
|
represented as "Jim Brown"<NUL>.
|
|
|
|
The character set used in this field is the same as given in the
|
|
message body (see a separate document). If no character set is given
|
|
there, the ASCII character set is used.
|
|
|
|
Character codes 1..31 may not be used within this field.
|
|
|
|
3.12. Subject
|
|
This variable length field is filled with the <NUL>-terminated
|
|
character string representing the subject of the message in question.
|
|
In the case the programme creating the packet does not want to put any
|
|
actual subject there, the field should be filled with a single <NUL>
|
|
character. The maximum length of the string is 72 characters including
|
|
the <NUL> termination. E.g. the subject "FTS-0001" is represented as
|
|
"FTS-0001"<NUL>.
|
|
|
|
The character set used in this field is the same as given in the
|
|
message body (see a separate document). If no character set is given
|
|
there, the ASCII character set is used.
|
|
|
|
Character codes 1..31 may not be used within this field.
|
|
|
|
3.12.1. File specifications
|
|
When the attribute field has bit 4, 11 and/or 15 set, the message
|
|
subject field normally is replaced by a list of file specifications
|
|
containing the file names the system where the message was created
|
|
(directory, path and time information etc are discarded).
|
|
|
|
These file specifications are transmitted to the receiving system
|
|
according to separate documents.
|
|
|
|
It should be noted that if the message is accompanied by an attached
|
|
file which is to be routed via other systems before reaching the
|
|
ultimate destination system, it may be essential for the intermediate
|
|
systems that the message is indeed transmitted even if it is empty. By
|
|
doing so, the intermediate systems will have a way of finding out the
|
|
intended destination of the attached file.
|
|
|
|
It should also be noted that especially in the case of routed file
|
|
attaches it is essential that file names are chosen so that they can
|
|
be directly and easily handled under the same names by the respective
|
|
host operating systems at the intermediate systems.
|
|
|
|
3.13. Message body
|
|
This variable length field is filled with the <NUL>-terminated
|
|
character string representing the message text of the message in
|
|
question. In the case the programme creating the packet does not want
|
|
to put any actual text there, the field should be filled with a single
|
|
<NUL> character. The maximum length of the string is unlimited. E.g.
|
|
the text "FTS-0001" is represented as "FTS-0001"<NUL>.
|
|
|
|
See note 7.
|
|
FIDONEWS 16-13 Page 13 29 Mar 1999
|
|
|
|
|
|
The character set used in this field is the same as given in the
|
|
message body (see a separate document). If no character set is given
|
|
there, the ASCII character set is used.
|
|
|
|
Character codes 2..9,11..12,14..31 may not be used within this field.
|
|
|
|
Character code 141 may be used within this field irrespective of the
|
|
character set used.
|
|
|
|
Character code 1 may be used only for the purpose given below.
|
|
|
|
Special considerations about certain character codes apply:
|
|
|
|
3.14. Character code 1, <SOH>
|
|
To include extra addressing and control information, the message body
|
|
may contain so called kludges.
|
|
|
|
Each kludge is contained within a separate paragraph of text as
|
|
defined in 3.16. A paragraph containing a kludge may not contain any
|
|
other message text.
|
|
|
|
Each paragraph containing a kludge starts with <SOH> character. The
|
|
<SOH> character must not appear in any other position of a paragraph.
|
|
|
|
The general format of a paragraph containing a kludge is
|
|
|
|
<SOH><Kludge tag>": "<string><CR>
|
|
|
|
where <string> is some sort of value related to the kludge in
|
|
question.
|
|
|
|
If no such value is required for a certain kludge, the general format
|
|
of a paragraph containing such a kludge is
|
|
|
|
<SOH><Kludge tag>":"<CR>
|
|
|
|
Developers may introduce new kludges on an experimental basis as they
|
|
see fit. Kludge tags which are documented in FTS documents must
|
|
however not be used in any other way than according to those FTS
|
|
documents. Kludge tags which are documented in FSP or FSC documents
|
|
should not be used in any other way than according to those documents.
|
|
|
|
Consequently each programme receiving a type 2 packet file should
|
|
retain any unknown kludge verbatim and at an unchanged a position
|
|
within the message body as possible. This is particularly essential
|
|
for messages which are to be routed to another system.
|
|
|
|
The ASCII character set is used in paragraphs containing kludges.
|
|
|
|
This document describes three kludges: FMPT, TOPT and INTL.
|
|
|
|
3.14.1. FMPT
|
|
The FMPT kludge is used to give information about the point number of
|
|
the sender of a message if that point number is not 0. If the point
|
|
number of the sender of a message is 0 that message should not contain
|
|
any FMPT kludge.
|
|
FIDONEWS 16-13 Page 14 29 Mar 1999
|
|
|
|
|
|
The format of a paragraph containing a FMPT kludge is
|
|
|
|
<SOH>"FMPT <point number>"<CR>
|
|
|
|
where <point number> is the ASCII representation of the point number
|
|
of the sender. The point number is an unsigned integer in the range
|
|
1-65535. See note 1.
|
|
|
|
E.g. a message from point number 1 of a certain node contains the
|
|
following FMPT kludge
|
|
|
|
<SOH>"FMPT 1"<CR>
|
|
|
|
Note that the format of a paragraph containing a FMPT kludge deviates
|
|
from the general format given above in that it does not contain any
|
|
colon after the kludge tag.
|
|
|
|
3.14.2. TOPT
|
|
The TOPT kludge is used to give information about the point number of
|
|
the addressee of a message if that point number is not 0. If the point
|
|
number of the addressee of a message is 0 that message should not
|
|
contain any TOPT kludge.
|
|
|
|
The format of a paragraph containing a TOPT kludge is
|
|
|
|
<SOH>"TOPT "<point number><CR>
|
|
|
|
where <point number> is the ASCII representation of the point number
|
|
of the sender. The point number is an unsigned integer in the range
|
|
0-65535. See note 1.
|
|
|
|
E.g. a message to point number 1 of a certain node contains the
|
|
following TOPT kludge
|
|
|
|
<SOH>"TOPT 1"<CR>
|
|
|
|
Note that the format of a paragraph containing a FMPT kludge deviates
|
|
from the general format given above in that it does not contain any
|
|
colon after the kludge tag.
|
|
|
|
3.14.3. INTL
|
|
The INTL kludge is used to give information about the zone numbers of
|
|
the sender and the addressee of a message.
|
|
|
|
The format of a paragraph containing a INTL kludge is
|
|
|
|
<SOH>"INTL "<destination address>" "<origin address><CR>
|
|
|
|
where <destination address> is the ASCII representation of the
|
|
destination address and <origin address> is the ASCII representation
|
|
of the origin address of the message in question. These addresses is
|
|
given on the form <zone>:<net>/<node> where <zone> is the ASCII
|
|
representation of the zone number, <net> is the ASCII representation
|
|
of the net number and <node> is the ASCII representation of the
|
|
node number. Any point number information is given in FMPT and TOPT
|
|
kludges.
|
|
FIDONEWS 16-13 Page 15 29 Mar 1999
|
|
|
|
|
|
E.g. a message from address 1:123/4.5 to 2:345/6.7 node contains the
|
|
following INTL kludge
|
|
|
|
<SOH>"INTL 2:345/6 1:123/4"<CR>
|
|
|
|
Note that the format of a paragraph containing a INTL kludge deviates
|
|
from the general format given above in that it does not contain any
|
|
colon after the kludge tag.
|
|
|
|
INTL kludges are also often used even when both the originating and
|
|
the destination systems are in the same zone. This gives both the
|
|
originating system and the destination system as well as any
|
|
intermediate routing systems unambiguous zone information even in a
|
|
situation where one system may be active in a number of different
|
|
zones.
|
|
|
|
However, it is known that some programmes may route messages
|
|
incorrectly if the INTL kludge is present in messages where both the
|
|
originating and the destination systems are in the same zone.
|
|
|
|
3.15. Character code 10, <LF>
|
|
Programmes creating packet files may put <LF> characters into the
|
|
message body. These characters should be disregarded by any programmes
|
|
displaying the message to a user. Instead text should be formatted
|
|
according to local conditions such as user preferences and/or
|
|
physical/logical constraints of display equipment.
|
|
|
|
Use of <LF> characters in the message body is discouraged. However
|
|
<LF> characters should not be removed from the message body of
|
|
in-transit messages.
|
|
|
|
3.16. Character code 13, <CR>
|
|
The <CR> character is used for the purpose of terminating paragraphs
|
|
of text. Any programme displaying the message to a user should format
|
|
the text accordingly.
|
|
|
|
3.17. Character code 141, soft-<CR>
|
|
Programmes creating packet files may put soft-<CR> characters into the
|
|
message body. These soft-<CR> characters are usually used to prescribe
|
|
local formatting on the system where the message in question was
|
|
created. These characters should be disregarded by any programmes
|
|
displaying the message to a user.
|
|
|
|
Use of soft-<CR> characters in the message body is discouraged.
|
|
However soft-<CR> characters should not be removed from the message
|
|
body of in-transit messages.
|
|
|
|
In certain character sets, character code 141 may be used for a vital
|
|
part of the character set. If it can be assumed that the message is
|
|
written in such a character set, character code 141 may be used and
|
|
displayed.
|
|
|
|
|
|
4. Packet file names
|
|
The name of a packet file when transmitted to another system is of the
|
|
form
|
|
FIDONEWS 16-13 Page 16 29 Mar 1999
|
|
|
|
|
|
HHHHHHHH.PKT
|
|
|
|
where HHHHHHHH is a string of 8 hexadecimal digits in the ASCII
|
|
character set and .PKT is the literal ".PKT" also in the ASCII
|
|
character set.
|
|
|
|
The value for HHHHHHHH is chosen so as to minimize the risk of any
|
|
system receiving several packet files with the same name before all
|
|
the previously received files of that name have been processed.
|
|
|
|
|
|
5. Arcmail
|
|
To minimize the storage requirements for packet files and the time and
|
|
cost for their transmission from system to system, zero or more packet
|
|
files may be aggregated into compressed archives (Arcmail bundles)
|
|
using lossless compression programmes. This scheme is normally called
|
|
Arcmail after the programme once produced by System Enhancement
|
|
Associates.
|
|
|
|
Such compression programmes are not specified by this standard but are
|
|
generally available for a number of platforms.
|
|
|
|
However, the availability of suitable decompression programmes on a
|
|
certain system cannot be guaranteed. Therefore Arcmail should only be
|
|
used after prior agreement between the operators of the two systems
|
|
involved.
|
|
|
|
When Arcmail bundles are to be used their file names when transmitted
|
|
to another system is of the form
|
|
|
|
HHHHHHHH.DDN
|
|
|
|
where HHHHHHHH is a string of 8 hexadecimal digits in the ASCII
|
|
character set and .DD is one of the following literals
|
|
|
|
".MO", ".TU", ".WE", ".TH", ".FR", ".SA", ".SU"
|
|
|
|
in the ASCII character set and N is a the ASCII representation of
|
|
decimal digit 0-9.
|
|
|
|
See note 6.
|
|
|
|
|
|
7. Address interpretation
|
|
Packet type 2 has been in use during a long period of time during
|
|
which the number and the complexity of ftn networks have increased
|
|
greatly.
|
|
|
|
The addressing requirements during this period have increased. Some of
|
|
these additional requirements have been met in packet type 2 by adding
|
|
kludges as defined above.
|
|
|
|
The following guidelines can be given for the interpretation of the
|
|
ftn addresses of type 2 packet files:
|
|
|
|
1. The origin and destination zone numbers are given explicitly in the
|
|
FIDONEWS 16-13 Page 17 29 Mar 1999
|
|
|
|
|
|
packet header if they are different from 0 and the packet is created
|
|
by a programme that is known to put that information there. One such
|
|
programme is QMail.
|
|
2. The origin net and node numbers are given explicitly in the packet
|
|
header.
|
|
3. The destination net and node numbers are given explicitly in
|
|
the packet header.
|
|
4. The origin and destination point numbers cannot be found in a type
|
|
2 packet. (For the case of Fakenets see section 8.)
|
|
|
|
The following guidelines can be given for the interpretation of the
|
|
ftn addresses of messages in type 2 packet files:
|
|
1. The origin and destination zone numbers are given explicitly in an
|
|
INTL kludge in the message body if there is such a kludge. (For the
|
|
case of Zone Gating see section 8.)
|
|
2. If there is no INTL kludge in the message body or there is an INTL
|
|
kludge that is not conformant with this specification the missing zone
|
|
numbers may be assumed to be equal to the originating zone number in
|
|
the packet header if that information is available. (For the case of
|
|
Zone Gating see section 8.)
|
|
3. If any zone number cannot be determined in steps 1 and 2 it may be
|
|
assumed to be equal to the zone number of the main address of the own
|
|
system. (For the case of Zone Gating see section 8.)
|
|
4. The origin net and node numbers are given explicitly in the
|
|
message header.
|
|
5. The destination net and node numbers are given explicitly in the
|
|
message header. (For the case of Zone Gating see section 8.)
|
|
6. The originating point number is given in the FMPT kludge in the
|
|
message body if there is such a kludge.
|
|
7. If there is no FMPT kludge in the message body or there is a FMPT
|
|
kludge that is not conformant with this specification the originating
|
|
point number may be assumed to be 0.
|
|
8. The destination point number is given in the TOPT kludge in the
|
|
message body if there is such a kludge. (For the case of Zone Gating
|
|
see section 8.)
|
|
9. If there is no TOPT kludge in the message body or there is a TOPT
|
|
kludge that is not conformant with this specification the destination
|
|
point number may be assumed to be 0. (For the case of Zone Gating see
|
|
section 8.)
|
|
|
|
|
|
8. Fakenets
|
|
Some existing programmes have limited support for point addressing.
|
|
|
|
In order to still allow for points when such programmes are in use,
|
|
sometimes a system called Fakenets or Fakenet Addressing is used.
|
|
|
|
The operator of a ftn node using Fakenets defines a special net
|
|
number, not included in the general nodelist, for the points under
|
|
that node.
|
|
|
|
That ftn node itself assumes the role of host for that net, i.e.
|
|
assumes the address <fakenet>/0. The point systems are then assigned
|
|
node numbers within that Fakenet. These node numbers are usually equal
|
|
to the point numbers which they have been assigned. There may or there
|
|
may not be a zone number assigned to the Fakenet. If a zone number is
|
|
FIDONEWS 16-13 Page 18 29 Mar 1999
|
|
|
|
|
|
assigned it usually is the zone number in which the ftn node itself is
|
|
active.
|
|
|
|
A ftn node operating a Fakenet should use programmes which do the
|
|
readdressing of messages so that systems outside of the Fakenet need
|
|
not be aware of the address allocations within the Fakenet.
|
|
|
|
E.g. assume that node 1:234/5 operates a fakenet with net number
|
|
23450. Programmes at 1:234/5 are then expected to readdress any
|
|
message to 1:234/5.1 to whatever node number that point system has
|
|
within the fakenet (usually 1:23450/1). Likewise, programmes at
|
|
1:234/5 are expected to readdress any messages from 1:23450/1 to a
|
|
destination outside the fakenet so that they appear to originate from
|
|
1:234/5.1 (providing that is the 4-dimensional point address which
|
|
Fakenet node 1:23450/1 has).
|
|
|
|
|
|
9. Zone Gating
|
|
When two zones cover different geographical areas such as two
|
|
different continents the technical difficulties and costs of
|
|
establishing direct communications between two systems, one in each of
|
|
these zones, may be considered a problem.
|
|
|
|
For that purpose there may by administrative decisions be appointed
|
|
one or more zone gates for message traffic from one zone to the other.
|
|
The zone gates are systems whose operators have taken on the task of
|
|
collecting and transmitting message traffic from the own zone to the
|
|
foreign zone.
|
|
|
|
To allow for such zone gating the following addressing guidelines
|
|
apply.
|
|
|
|
The origin address and the final destination address is given with the
|
|
help of INTL, FMPT och TOPT kludges in the message body.
|
|
|
|
The message header contains the node and net numbers of the
|
|
originating system and the node and network numbers of the zone gate.
|
|
|
|
|
|
Notes
|
|
|
|
Note 1
|
|
It may be noted that certain existing programmes may represent point,
|
|
node, net and zone numbers as signed integers on the user interface
|
|
level. E.g. node number 65535 may be represented as -1.
|
|
|
|
Note 2
|
|
Big-endian byte order (also known as Intel byte order) is used for 16-
|
|
bit binary integers.
|
|
|
|
Each field containing a 16-bit binary integer is composed of two bytes
|
|
O0 and O1:
|
|
|
|
+----+----+
|
|
! O0 ! O1 !
|
|
-----+----+
|
|
FIDONEWS 16-13 Page 19 29 Mar 1999
|
|
|
|
|
|
where O0 contains bits 0-7 and O1 bit 8-15 of the 16-bit binary
|
|
integer.
|
|
|
|
Bit 0 is the least significant bit and bit 15 is the most significant
|
|
bit of the 16-bit binary integer.
|
|
|
|
Note 3
|
|
It may be noted that this document does not contain any information
|
|
about how to decide the time zone used in the fields for date and time
|
|
in a packet. It is however expected that most programmes use the local
|
|
system time in these fields.
|
|
|
|
Note 4
|
|
It may be noted that certain existing programmes put additional
|
|
restrictions on the range of valid zone numbers. E.g. the zone numbers
|
|
may be restricted to 1-255 or 1-4095.
|
|
|
|
Note 5
|
|
There are a number or programmes in current use which allow also
|
|
non-ASCII characters to be entered into the packet level password.
|
|
E.g. character codes 128-255. There is no way within the framework of
|
|
this common ftn practice to tell what character set is used in this
|
|
case. Therefore it is also not possible for a programme to implement a
|
|
general case translation algorithm for such characters.
|
|
|
|
Note 6
|
|
Certain existing programmes are known to produce Arcmail bundles with
|
|
file names when transmitted where N may be an ASCII character in the
|
|
range '0'..'9', 'A'..'F'.
|
|
|
|
Certain other existing programmes are known to produce Arcmail bundles
|
|
with file names when transmitted where N may be an ASCII character in
|
|
the range '0'..'9', 'A'..'Z'.
|
|
|
|
The capability of processing Arcmail bundles with such extended file
|
|
names is not required by this specification and they should therefore
|
|
only be used after prior agreement between the operators of the two
|
|
systems involved.
|
|
|
|
|
|
Note 7
|
|
This specification specifies the size of the message body as
|
|
unlimited.
|
|
|
|
For obvious reasons, each system has some maximum size for a message
|
|
body and for a packet file. Furthermore the file transfer protocols
|
|
specified for ftn sessions separately may also impose maximum sizes on
|
|
files to be transferred from one ftn system to another.
|
|
|
|
Finally some existing programmes/platforms may have their own limits
|
|
as to the maximum size of a message and to the maximum size of a
|
|
packet file. E.g. some computer architectures use segmented memory and
|
|
then the developer of a certain existing programme may have chosen to
|
|
see to it that each data structure fits within one such segment, e.g.
|
|
64 kilobytes. Other existing programmes may have internal limits to
|
|
the size of the message body, e.g. 10 or 32 kilobytes.
|
|
FIDONEWS 16-13 Page 20 29 Mar 1999
|
|
|
|
|
|
Procedures for splitting and recombining large messages are specified
|
|
in other FTSC documents.
|
|
|
|
|
|
-----------------------------------------------------------------
|
|
|
|
FIDONEWS 16-13 Page 21 29 Mar 1999
|
|
|
|
|
|
=================================================================
|
|
COLUMNS
|
|
=================================================================
|
|
|
|
|
|
What's Not Happening: Tag-Teams
|
|
|
|
.-- -- -- -- -- -- WHAT'S NOT HAPPENING -- -- -- -- -- --.
|
|
| There isn't always something happening on Fidonet, but |
|
|
| there's always something which isn't happening. This |
|
|
| column is dedicated to the lost causes which make Fido |
|
|
| what it isn't today. Published semi-occasionally... |
|
|
`-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --'
|
|
|
|
Tag-Teams
|
|
Douglas Myers, 1:270/720
|
|
doug@mdtnbbs.com
|
|
|
|
Occupying center ring in Fido's Circus of Lost Causes is Bob
|
|
Morasvik's elaborate game of Tag. The objective is to find a game
|
|
which is already being played, and then take over the game by
|
|
declaring himself "it." The rank and file of Fidonet have countered
|
|
this initiative by largely ignoring it. This demonstration of
|
|
applied apathy seems to be prevailing despite loud "it-fits"
|
|
cross-posted to multiple echoes by J. Kershaw, Defensive Coordinator
|
|
for the Morasvik team.
|
|
|
|
The game of Tag derives its name from the practice, mostly in Zone
|
|
1, of listing an echotag with the Elist Robot operated by Thom
|
|
Lacosta as a prelude to distributing echomail throughout the zone.
|
|
This elist is used by distribution systems (and anyone else
|
|
interested) to identify the moderator of an echo and to help reduce
|
|
the instance of duplicate echotags.
|
|
|
|
Tag, the game, takes advantage of the fact that not all echotags are
|
|
listed. Many echo areas are distributed by private arrangement with
|
|
the nodes involved and don't need to be listed, and many more are
|
|
listed, but not necessarily with Thom LaCosta's system. Thom's
|
|
elist service is usually targeted by Tag players, though, because
|
|
the North American Backbone uses this service.
|
|
|
|
The game of Tag is played by searching for existing echoes which are
|
|
either unlisted or listed elsewhere, and then listing the echotag
|
|
with Thom's service, but naming oneself as moderator. The most
|
|
common source of unlisted existing echoes is echoes which were
|
|
previously listed, but where the moderator has failed to keep the
|
|
listing current. Many moderators have found their echoes
|
|
effectively "taken over" in this manner.
|
|
|
|
In the past, Bob Morasvik has proven himself an adept player at this
|
|
form of echo hijacking by such maneuvers as listing all of the
|
|
Region 13 conferences, leaving the Region 13 coordinators the
|
|
alternatives of either establishing new conferences or recognizing
|
|
him as moderator of the existing conferences.
|
|
|
|
In his latest attempt to retain top seed in the world of Tag
|
|
FIDONEWS 16-13 Page 22 29 Mar 1999
|
|
|
|
|
|
players, Bob elisted ZCC-Public, an echo originating in Zone 2 but
|
|
never elisted in Zone 1. After successfully listing the echo with
|
|
Thom's robot, Bob attempted to control Zone 1 distribution of the
|
|
echo on the basis that he was the elisted moderator. He's
|
|
officially cut the echo from Z1B distribution, but John Souvestre
|
|
(principle Z1B hub) simply distributes the Zone 2 echo. Bob's
|
|
request to have his version of ZCC-Public carried on NAB
|
|
distribution was denied on the basis that the tag is already in use
|
|
by many of the hubs comprising the NAB. The net result is that Bob
|
|
has been largely ignored.
|
|
|
|
I'm not sure how this affects his standing as a Tag player, but Bob
|
|
Morasvik is no longer "It," and heads the list of What's Not
|
|
Happening on Fido.
|
|
|
|
-----------------------------------------------------------------
|
|
|
|
FIDONEWS 16-13 Page 23 29 Mar 1999
|
|
|
|
|
|
=================================================================
|
|
NOTICES
|
|
=================================================================
|
|
|
|
Future History
|
|
|
|
12 May 1999
|
|
12th Anniversary of Fido Operations in Zone 4;
|
|
10th Anniversary of the creation of FidoNet Zone 4.
|
|
|
|
14 - 16 May 1999
|
|
V. BBachCon in Bleichenbach, Germany.
|
|
For further information see: www.bbachcon.de
|
|
|
|
24 Jul 1999
|
|
XIII Pan American Games [through 8 Aug 99].
|
|
|
|
9 Jun 1999
|
|
Tenth Anniversary of the adoption of FidoNet Policy 4.07.
|
|
|
|
10 Sep 1999
|
|
10th anniversary of Zone 5 operations.
|
|
|
|
26 Oct 1999
|
|
Thirty years from release Abbey Road album by the Beatles.
|
|
|
|
31 Dec 1999
|
|
Hogmanay, Scotland. The New Year that can't be missed.
|
|
|
|
1 Jan 2000
|
|
The 20th Century, C.E., is still taking place thru 31 Dec.
|
|
|
|
1 Jun 2000
|
|
EXPO 2000 World Exposition in Hannover (Germany) opens.
|
|
|
|
15 Sep 2000
|
|
Sydney (Australia) Summer Olympiad opens.
|
|
|
|
21 Sep 2000
|
|
10 years of FidoNet in +7 (xUSSR)
|
|
|
|
1 Jan 2001
|
|
This is the actual start of the new millennium, C.E.
|
|
|
|
-- If YOU have something which you would like to see in this
|
|
Future History, please send a note to the FidoNews Editor.
|
|
|
|
-----------------------------------------------------------------
|
|
|
|
FIDONEWS 16-13 Page 24 29 Mar 1999
|
|
|
|
|
|
=================================================================
|
|
FIDONET BY INTERNET
|
|
=================================================================
|
|
|
|
This is a list of all FidoNet-related sites reported to the
|
|
FidoNews Editor as of this issue; see the notice at the end.
|
|
|
|
FidoNet:
|
|
|
|
Homepage http://www.fidonet.org
|
|
FidoNews http://www.fidonews.org [HTML]
|
|
http://209.77.228.66/fidonews.html [ASCII]
|
|
WWW sources http://travel.to/fidonet/
|
|
FTSC page http://www.ftsc.org/
|
|
Echomail [pending]
|
|
General http://owls.com/~jerrys/fidonet.html
|
|
http://www.nrgsys.com/orb/foti
|
|
List servers:
|
|
http://www.onelist.com/subscribe.cgi/fidonet-discussion
|
|
|
|
============
|
|
|
|
Zone 1: http://www.z1.fidonet.org
|
|
|
|
Region 10: http://www.psnw.com/~net205/region10.html
|
|
|
|
Region 11: http://oeonline.com/~garyg/region11/
|
|
|
|
Region 13: http://www.net264.org/r13.htm
|
|
|
|
Net 264: http://www.net264.org/
|
|
|
|
Region 14:
|
|
|
|
Net 282: http://www.rxn.com/~net282/
|
|
|
|
Region 17: http://www.nwstar.com/~region17/
|
|
|
|
Region 18: http://techshop.pdn.net/fido/
|
|
|
|
Region 19: http://members.home.net/hbh3/r19
|
|
|
|
Zone 1 Elist http://www.baltimoremd.com/elist/
|
|
|
|
Not sure where the following should be placed:
|
|
|
|
http://www.angelfire.com/biz/snwvlly/fido.html
|
|
|
|
============
|
|
|
|
Zone 2: http://www.z2.fidonet.org
|
|
|
|
ZEC2:
|
|
Zone 2 Elist: http://www.fbone.ch/echolist/
|
|
|
|
Region 20: http://www.fidonet.pp.se (in Swedish)
|
|
FIDONEWS 16-13 Page 25 29 Mar 1999
|
|
|
|
|
|
Region 23: http://www.fido.dk (in Danish)
|
|
|
|
Region 24: http://www.swb.de/personal/flop/gatebau.html (German)
|
|
Fido-IP: http://home.nrh.de/~lbehet/fido (English/German)
|
|
|
|
Region 25: http://www.bsnet.co.uk/net2502/net/
|
|
|
|
Region 26: http://www.nemesis.ie
|
|
REC 26: http://www.nrgsys.com/orb
|
|
|
|
Region 27: http://telematique.org/ft/r27.htm
|
|
|
|
Region 29: http://www.rtfm.be/fidonet/ (French)
|
|
|
|
Region 30: http://www.fidonet.ch (German)
|
|
|
|
Region 33: http://www.fidoitalia.net (Italian)
|
|
|
|
Region 34: http://www.pobox.com/cnb/r34.htm (Spanish)
|
|
REC34: http://pobox.com/~chr
|
|
|
|
Region 36: http://www.geocities.com/SiliconValley/7207/
|
|
|
|
Region 38: http://public.st.carnet.hr/~blagi/bbs/adriam.html
|
|
|
|
Region 41: http://www.fidonet.gr (Greek/English)
|
|
|
|
Region 42: http://www.fido.cz
|
|
|
|
Region 48: http://www.fidonet.org.pl
|
|
|
|
Region 50: http://www.fido7.com/ (Russian)
|
|
Net 5010: http://fido.tu-chel.ac.ru/ (Russian)
|
|
Net 5015: http://www.fido.nnov.ru/ (Russian)
|
|
Net 5030: http://kenga.ru/fido/ (Russian & English)
|
|
Net 5073: http://people.weekend.ru/soa/ (Russian)
|
|
|
|
============
|
|
|
|
Zone 3: http://www.z3.fidonet.org
|
|
|
|
============
|
|
|
|
Zone 4:
|
|
|
|
Region 90: http://visitweb.com/fidonet
|
|
Net 903: http://www.playagrande.com/refugio
|
|
Net 904: http://members.tripod.com/~net904 (Spanish)
|
|
|
|
============
|
|
|
|
Zone 5: http://www.eastcape.co.za/fidonet/index.htm
|
|
|
|
============
|
|
|
|
Zone 6: http://www.z6.fidonet.org
|
|
FIDONEWS 16-13 Page 26 29 Mar 1999
|
|
|
|
|
|
Region 65: http://www.cfido.com/fidonet/cfidochina.html (Chinese)
|
|
|
|
============
|
|
|
|
Pages listed above are as submitted to the FidoNews Editor,
|
|
and generally reflect Zone and Regional Web Page sites. If
|
|
no Regional site is submitted, the first Network page from
|
|
that Region is used in its place. Generally, Regional pages
|
|
should list access points to all Networks within the Region.
|
|
|
|
TCP/IP accessible node access information should be submitted
|
|
to the FidoNews Editor for inclusion in their Region or Zone.
|
|
|
|
-----------oOo-------------
|
|
|
|
Fidonet Via Internet Hubs
|
|
|
|
Node# | Operator | Facilities (*) | Speed | Basic Rate
|
|
-----------+-------------------+----------------+-------+------------
|
|
1:12/12 | Ken Wilson | FTP | T1 | $24mo.
|
|
1:13/25 | Jim Balcom | FTP | 56k | $20mo.
|
|
1:106/1 | Matt Bedynek | FTP,VMoT,UUE | 64k | $5/$15mo.
|
|
1:106/6018 | Lawrence Garvin | FTP,VMoT | 64k | $5/mo.
|
|
1:107/451 | Andy Knifel | FTP, VMoT, UUE | 33.6 | n/c
|
|
1:140/12 | Bob Seaborn | FTP | T1 | $5/$20
|
|
1:270/101 | George Peace | FTP | T1 | $30mo.
|
|
1:271/140 | Tom Barstow | UUE | T1 | n/c
|
|
1:275/1 | Joshua Ecklund | UUE | 28.8 | $10/yr.
|
|
1:280/169 | Brian Greenstreet | FTP | 33.6 | $2mo.
|
|
1:2401/305 | Peter Rocca | FTP,UUE | T1 | unkn
|
|
1:2424/10 | Alec Grynspan | FTP,UUE | T1 | n/c
|
|
1:2604/104 | Jim Mclaughlin | FTP,VMoT,UUE | 33.6 | $1mo.
|
|
1:2624/306 | D. Calafrancesco | VMoT | 33.6 | $15yr.
|
|
1:345/0 | Todd Cochrane | FTP | T1 | n/c
|
|
1:346/250 | Aran Spence | FTP,UUE | T1 | $10mo.
|
|
1:396/45 | Marc Lewis | UUE | 33.6 | $26/yr.
|
|
1:3651/9 | Jerry Gause | FTP,VMoT | 33.6 | $3/$6
|
|
1:396/1 | John Souvestre | FTP,VMoT | T1 | $15mo.
|
|
2:335/535 | Mario Mure | VMoT,UUE | 64k | n/c
|
|
2:254/175 | Alex Kemp | UUE | 56k | n/c
|
|
2:284/800 | Jeroen VanDeLeur | FTP,UUE | 64k | n/c
|
|
2:335/610 | Gino Lucrezi | UUE | 33.6 | n/c
|
|
2:469/84 | Max Masyutin | VMoT | 256k | n/c
|
|
2:2411/413 | Dennis Dittrich | UUE | 64k | n/c
|
|
2:2474/275 | Christian Emig | UUE | 64k | unkn
|
|
3:633/260 | Malcolm Miles | FTP | 33.6 | n/c
|
|
4:905/100 | Fabian Gervan | VMoT, UUE | ??? | n/c
|
|
5:7104/2 | Henk Wolsink | FTP | 28.8 | n/c
|
|
--
|
|
* FTP = Internet File Transfer Protocol
|
|
* VMoT = Virtual Mailer over Telnet (various)
|
|
* UUE = uuencode<->email type transfers
|
|
[I'm only cataloging transfer methods, eg, ftp, email, telnet.
|
|
Specific programs using these protocols are no longer being listed.
|
|
Contact the system operators for details of which programs they have
|
|
available.]
|
|
FIDONEWS 16-13 Page 27 29 Mar 1999
|
|
|
|
|
|
Compiled by C. Ingersoll, 1:2623/71, (609)814-1978, fbn@dandy.net
|
|
Posted on the 1st of every month in FN_SYSOP, R13SYSOP and Fidonews.
|
|
|
|
-----------------------------------------------------------------
|
|
|
|
FIDONEWS 16-13 Page 28 29 Mar 1999
|
|
|
|
|
|
=================================================================
|
|
FIDONEWS INFORMATION
|
|
=================================================================
|
|
|
|
|
|
------- FIDONEWS MASTHEAD AND CONTACT INFORMATION -------
|
|
|
|
Editor: Henk Wolsink
|
|
|
|
Editors Emeriti: Tom Jennings, Thom Henderson, Dale Lovell,
|
|
Vince Perriello, Tim Pozar, Sylvia Maxwell,
|
|
Donald Tees, Christopher Baker, Zorch Frezberg
|
|
|
|
"FidoNews Editor"
|
|
FidoNet 5:5/23
|
|
BBS +27-41-581-5913, 2400/9600/V34
|
|
|
|
more addresses:
|
|
Henk Wolsink -- 5:7104/2, hwolsink@catpe.alt.za
|
|
|
|
(Postal Service mailing address)
|
|
FidoNews Editor
|
|
P.O. Box 12325
|
|
Port Elizabeth,
|
|
6006
|
|
South Africa
|
|
|
|
------------------------------------------------------
|
|
|
|
FidoNews is published weekly by and for the members of the FIDONET
|
|
INTERNATIONAL AMATEUR ELECTRONIC MAIL system. It is a compilation
|
|
of individual articles contributed by their authors or their
|
|
authorized agents. The contribution of articles to this compilation
|
|
does not diminish the rights of the authors. OPINIONS EXPRESSED in
|
|
these articles ARE THOSE OF THE AUTHORS and not necessarily those of
|
|
FidoNews and/or the Editor.
|
|
|
|
Authors retain copyright on individual works; otherwise FidoNews is
|
|
Copyright (C) 1999 Henk Wolsink. All rights reserved. Duplication
|
|
and/or distribution permitted for noncommercial purposes only. For
|
|
use in other circumstances, please contact the original authors, or
|
|
the Editor.
|
|
|
|
=*=*=*=*=*=*=*=*=
|
|
|
|
OBTAINING COPIES: The most recent issue of FidoNews in electronic
|
|
form may be obtained from the FidoNews Editor via manual download or
|
|
file-request, or from various sites in FidoNet and the Internet.
|
|
PRINTED COPIES may be obtained by sending SASE to the above postal
|
|
address. File-request FIDONEWS for the current Issue. File-request
|
|
FNEWS for the current month in one archive. Or file-request specific
|
|
back Issue filenames in distribution format [FNEWSGnn.ZIP] for a
|
|
particular Issue. Monthly Volumes are available as FNWSmmmy.ZIP
|
|
where mmm = three letter month [JAN - DEC] and y = last digit of the
|
|
current year [9], i.e., FNWSJAN9.ZIP for all the Issues from Jan 99.
|
|
|
|
FIDONEWS 16-13 Page 29 29 Mar 1999
|
|
|
|
|
|
Annual volumes are available as FNEWSn.ZIP where n = the Volume number
|
|
1 - 16 for 1984 - 1999, respectively. Annual Volume archives range in
|
|
size from 48K to 1.4M.
|
|
|
|
|
|
INTERNET USERS: FidoNews is available via:
|
|
|
|
http://www.fidonews.org
|
|
** http://www.fidonet.org/fidonews.htm
|
|
** ftp://ftp.fidonet.org/pub/fidonet/fidonews/
|
|
ftp://ftp.irvbbs.com/fidonews/
|
|
ftp://ftp.nwstar.com/Fidonet/Fidonews
|
|
|
|
And in non-English formats via:
|
|
|
|
** http://www.hvc.ee/pats/fidonews (Estonian)
|
|
http://www.fidonet.pp.se/sfnews (Swedish)
|
|
|
|
** LINK HAS NOT BEEN UPDATED
|
|
|
|
*=*=*
|
|
|
|
You may obtain an email subscription to FidoNews by sending email to:
|
|
|
|
jbarchuk@worldnet.att.net
|
|
|
|
with a Subject line of: subscribe fnews-edist
|
|
|
|
and no message in the message body. To remove your name from the
|
|
email distribution use a Subject line of: unsubscribe fnews-edist
|
|
with no message to the same address above.
|
|
|
|
*
|
|
|
|
You may retrieve current and previous Issues of FidoNews via FTPMail
|
|
by sending email to:
|
|
|
|
ftpmail@fidonews.org
|
|
|
|
with a Subject line of: help
|
|
|
|
and FTPMail will immediately send a reply containing details and
|
|
instructions. When you actually make a file request, FTPMail will
|
|
respond in three stages. You find a link for this process on
|
|
www.fidonews.org.
|
|
|
|
*=*=*
|
|
|
|
You can read the current FidoNews Issue in HTML format at:
|
|
|
|
http://www.fidonews.org
|
|
|
|
and http://www.fidonet.dynip.com/public/fidonews/default.htm
|
|
|
|
and in the FIDONEWS echo.
|
|
|
|
FIDONEWS 16-13 Page 30 29 Mar 1999
|
|
|
|
|
|
STAR SOURCE for ALL Past Issues via FTP and file-request -
|
|
Available for FReq from 1:396/1 or by anonymous FTP from:
|
|
|
|
ftp://ftp.sstar.com/fidonet/fnews/
|
|
|
|
Each yearly archive also contains a listing of the Table-of-Contents
|
|
for that year's issues. The total set is currently about 13 Megs.
|
|
|
|
=*=*=*=
|
|
|
|
The current week's FidoNews are now also available almost immediately
|
|
after publication on the FidoNews Editor homepage on the World Wide
|
|
Web at:
|
|
|
|
http://209.77.228.66/fidonews.html
|
|
|
|
There are also links there to jim barchuk's HTML FidoNews source and
|
|
to John Souvestre's FTP site for the archives. There is also an
|
|
email link for sending in an article as message text. Drop on over.
|
|
|
|
=*=*=*=*=*=*=*=*=
|
|
|
|
SUBMISSIONS: You are encouraged to submit articles for publication in
|
|
FidoNews. Article submission requirements are contained in the file
|
|
ARTSPEC.DOC, available from the FidoNews Editor, or file-requestable
|
|
from 5:5/23 [5:7104/2] as file "ARTSPEC.DOC". ALL Zone Coordinators
|
|
should have copies of ARTSPEC.DOC. Please read it.
|
|
|
|
"Fido", "FidoNet" and the dog-with-diskette are U.S. registered
|
|
trademarks of Tom Jennings, P.O. Box 410923, San Francisco, CA 94141,
|
|
and are used with permission.
|
|
|
|
"Disagreement is actually necessary,
|
|
or we'd all have to get in fights
|
|
or something to amuse ourselves
|
|
and create the requisite chaos."
|
|
-Tom Jennings
|
|
|
|
-----------------------------------------------------------------
|
|
|
|
|