info/mirror-textfiles.com
1
0
Fork 0
mirror of https://github.com/opsxcq/mirror-textfiles.com.git synced 2025-08-30 11:10:37 +02:00
Code Issues Releases Wiki Activity
Files
gh-pages
mirror-textfiles.com/bbs/FIDONET/FIDONEWS/fido1613.nws

1606 lines
67 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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
-----------------------------------------------------------------
Reference in New Issue View Git Blame Copy Permalink