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

Updated FTSC docs

Browse Source
This commit is contained in:
Michiel Broek 2003-07-13 14:34:20 +00:00
parent cde220ead7
commit 1ba8de5d89
9 changed files with 6 additions and 1582 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
html/Makefile
View File

@ -10,16 +10,16 @@ H_BASE = basic.html dist.html manual.css \
known_bugs.html mgetty.html routing.html nodelist.html
H_FTSC = ftsc/fsc-0039.html ftsc/fsc-0056.html ftsc/fsc-0087.html \
ftsc/fsp-1003.html ftsc/fsp-1009.html ftsc/fts-0007.html \
ftsc/fts-0007.html \
ftsc/fsc-0046.html ftsc/fsc-0057.html ftsc/fsc-0091.html \
ftsc/fsp-1004.html ftsc/fta-1005.html ftsc/fts-0008.html \
ftsc/fta-1005.html ftsc/fts-0008.html \
ftsc/fsc-0048.html ftsc/fsc-0059.html ftsc/fsc-0092.html \
ftsc/fsp-1005.html ftsc/fts-0001.html ftsc/fts-0009.html \
ftsc/fsc-0049.html ftsc/fsc-0062.html ftsc/fsc-0093.html \
ftsc/fsp-1006.html ftsc/fts-0004.html ftsc/index.htm \
ftsc/fts-0004.html ftsc/index.htm \
ftsc/fsc-0050.html ftsc/fsc-0070.html ftsc/fts-4008.html \
ftsc/fsp-1007.html ftsc/fts-5000.html ftsc/fsc-0053.html \
ftsc/fsc-0072.html ftsc/fsp-1002.html ftsc/fsp-1008.html \
ftsc/fts-5000.html ftsc/fsc-0053.html \
ftsc/fsc-0072.html ftsc/fsp-1002.html \
ftsc/fts-0006.html ftsc/fsc-0035.html ftsc/fts-4009.html \
ftsc/fsp-1011.html ftsc/ftscprod.html ftsc/fsc-0088.html \
ftsc/fts-4001.html ftsc/fts-5001.html

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

@ -1,117 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Suggested use of Nodelist Fields.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1003
Revision: 1
Title: Suggested use of Nodelist Fields
Author: Lee Kindness
Revision Date: 15 May 1997
Expiry Date: 15 May 1999
----------------------------------------------------------------------
Contents:
1. Field 3, Node Name
2. Field 4, Location
3. Field 5, Sysop Name
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
Introduction
------------
This document makes recommendations on the use of various fields in
the distribution nodelist (St. Louis nodelist format", fts-0005).
Naturally it is the choice of the *C's if they want to use them.
Remember the fts-0005 requirements should still be adhered to.
1. Field 3, Node Name
---------------------
The node name field should be no more than 20 characters long. For
comparison in nodelist.122'1997 the minimum entry was 1, maximum 51!
and the average was 14.
For zone entries this field should contain a description of the
zones area, (eg North America, Europe). For region entries it should
contain the country/state, for host entries the local area name and
for hub entries a description of the area the hub serves.
2. Field 4, Location
--------------------
This field contains the location of the node. It should usually be
expressed as the primary local location (town, suburb, city, etc.)
plus an identifier of the regional geopolitical administrative
district (state, province, department, county, etc.). Wherever
possible, standard postal abbreviations for the major regional
district should be used (IL, BC, NSW, UK, etc.).
For zone and region entries this field should also have the julian
day of segment creation appended to it (eg "Somearea_(122)") to aid
checks on the validity of the nodelist.
3. Field 5, Sysop Name
----------------------
This field contains the name of the system operator. Entries such as
"postmaster" and "uucp" should not be used. Aliases should not be
permitted in this field (as they give Fidonet a 'less respectable'
image).
A. Author contact data
----------------------
Lee Kindness
Fidonet: n/a
E-mail: wangi@earthling.net
WWW: http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
B. History
----------
Rev.1, 971101: First release as FSP, based on the Fidonews 14/20
article. Transformed into FSP document by Odinn
Sorensen.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

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

@ -1,258 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Standard FidoNet Addressing.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1004
Revision: 1
Title: Standard Fidonet Addressing
Author: Lee Kindness
Revision Date: 15 May 1997
Expiry Date: 15 May 1999
----------------------------------------------------------------------
Contents:
1. Standard Fidonet Addressing
2. Internet Gateway Addressing
3. Routing Address Syntax
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
Introduction
------------
This document describes the standard form of addressing in Fidonet
today along with the common method of addressing via internet
gateways. In addition it proposes an extended addressing syntax,
useful for routing purposes. This is a draft for comments and
suggestions.
1. Standard Fidonet Addressing
------------------------------
Fidonet addressing uses the following format:
ZZ:NN/FF.PP@DO
where the fields refer to...
ZZ - Zone Number: The zone the node is part of.
Min: 1 Max: 32767
If 'ZZ:' is missing then assume 1 as the zone.
NN - Net Number: The network the node is a member of.
Min: 1 Max: 32767
Must be present.
FF - Node Number: The actual node number.
Min: -1 Max: 32767
Must be present.
PP - Point Number: If the system is a point rather than a node then
this is their point number off the node.
Min: 0 Max: 32767
If '.PP' is missing then assume 0 (ie not a
point) as the point number.
DO - Domain: The name of the 'Fidonet Technology Network'.
Maximum length of 8 characters. The domain
should not include periods, thus 'fidonet.org'
is invalid (should be fidonet).
If '@DO' is missing then fidonet can be assumed.
The following are all valid examples:
1:234/5.6@fidonet (a '5D' address) =&gt; 1:234/5.6@fidonet
2:34/6.78 (a '4D' address) =&gt; 2:34/6.78@fidonet
4:610/34 (a '3D' address) =&gt; 4:610/34.0@fidonet
123/45 (a '2D' address) =&gt; 1:123/45.0@fidonet
955:95/2@othernet (another FTN) =&gt; 955:95/2.0@othernet
2:259/-1 (node application) =&gt; 2:259/-1.0@fidonet
The limits on each various part of the address are a result of
fts-0005 (zone, net, node, point), fsc-0045 (domain) and Policy 4
(-1 node address for node application).
2. Internet Gateway Addressing
------------------------------
An internet user can send email/netmail to a fidonet user via one of
the fidonet-&gt;internet gateway systems (it's out-with the scope of
this document to describe the semantics of posting). The internet
user would send an email to a Fidonet user by using an email address
of the following syntax:
user.name@pPP.fFF.nNN.zZZ.gateway.domain
where the fields refer to...
user.name - Name: Name of the user the email is being sent
to, spaces replaced by periods.
PP - Point Number: As Fidonet address (FA)
If '.pPP' is missing 0 is assumed.
FF - Node Number: As FA
Must be present.
NN - Net Number: As FA
Must be present.
ZZ - Zone Number: As FA
Must be present.
gate.way - Gateway: Internet domain of the gateway, for
example 'fidonet.org'.
Must be present.
The following are all valid examples (assuming 'fidonet.org' is an
internet gateway):
joe.bloggs@p6.f5.n234.z1.fidonet.org =&gt; 1:234/5.6@fidonet
harry.cat@p78.f6.n34.z2.fidonet.org =&gt; 2:34/6.78@fidonet
i.be.jolly@f34.n610.z4.fidonet.org =&gt; 4:610/34.0@fidonet
and if 'foo.bar.org.uk' is a gateway for 'othernet':
louise.hat@f2.n95.z955.foo.bar.org.uk =&gt; 955:95/2.0@othernet
3. Routing Address Syntax
-------------------------
The two previous address types (Fidonet and Internet-&gt;Fidonet
gateway) are common practice, this however is a suggested standard
of addressing for routing tables. The routing address has the
following syntax:
DD:ZZ:RR:NN:HH:FF:PP
where the fields refer to:
DD - Domain: As FA
Must be present, even if blank (ie a leading
':') to ensure we always have 6 ':'s in an
address to aid pattern matching.
ZZ - Zone Number: As FA
Must be present.
RR - Region Number: The region (from fts-0005 nodelist) that the
following network is in.
Min: 1 Max: 32767
Must be present.
NN - Net Number: As FA
Must be present.
HH - Hub: The hub (from fts-0005 nodelist) that the node
is under, or 0 (host hub).
Min: 1 Max: 32767
Must be present.
FF - Node Number: As FA
Must be present.
PP - Point Number: As FA
Must be present.
':' has been chosen as the separator as it is not a POSIX regular
expression character or globing character (where as '.' is) and thus
always easy use of wildcards on the address. The following points
should be noted:
1. All addresses have 6 ':'s
2. The domain is at the front, the address gets more specific to
the right
3. Nodes have 0 as their point number
4. A zone net has identical zone, region and net fields
5. A region net has identical region and net fields
Example fidonet addresses converted to routing addresses:
fidonet:2:25:259:0:7:0 =&gt; 2:259/7.0@fidonet, region 25, hub 0
fidonet:1:1:1:0:23:0 =&gt; 1:1/23.0@fidonet, zone 1 net
:955:9551:95:300:45:0 =&gt; 955:95/45.0, region 9551, hub 300
fidonet:2:25:25:0:0:0 =&gt; 2:25/0.0@fidonet, R25C
cnet:12:34:341:100:1:7 =&gt; 12:341/1.7@cnet, region 34, hub 100
:2:25:259:300:300:0 =&gt; 2:259/300.0, region 25, hub 300
Example POSIX regular expression patterns on routing addresses:
[a-z]*:[0-9]+:[0-9]+:[0-9]+:[0-9]+:[0-9]+:[0-9]+ (any address)
[a-z]*(:[0-9]+)+ (any address)
fidonet:2:25:[0-9]+:[0-9]+:[0-9]+:[0-9]+ (region 25 node)
fidonet:2:25(:[0-9]+)+ (region 25 node)
fidonet:1:12:125(:[0-9]+)+ (all net 1:125 nodes)
fidonet:1:12:125:200(:[0-9]+)+ (all hub 1:125/200 downlinks)
fidonet:1:12:125:200:2:[0-9]+ (all 1:125/2 points)
fidonet:1:12:125:[0-9]+:(25|34|56):0
(nodes 1:125/25.0, 1:125/34.0 and 1:125/56.0)
Example 'DOS style' patterns on routing addresses:
*:*:*:*:*:*:* (any address)
fidonet:2:25:*:*:*:* (region 25 node)
fidonet:1:12:125:*:*:* (all net 1:125 nodes)
fidonet:1:12:125:200:*:* (all hub 1:125/200 downlinks)
fidonet:1:12:125:200:2:* (all 1:125/2 points)
fidonet:1:12:125:*:3*:0 (any net 1:125 nodes starting with 3)
fidonet:1:12:125:*:3?:0 (net 1:125 nodes 30 thru 39)
The standard doesn't define which standard of pattern matching to
use, only the format of the addresses. These routing addresses would
be used in routing tables and configurations.
A. Author contact data
----------------------
Lee Kindness
Fidonet: n/a
E-mail: wangi@earthling.net
WWW: http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
B. History
----------
Rev.1, 971101: First release as FSP, based on the Fidonews 14/20
article. Transformed into FSP document by Odinn
Sorensen.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

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

@ -1,451 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Zone 2 nodelist flags.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1005
Revision: 6
Title: Zone 2 nodelist flags
Author: Frank Ellermann, 2:240/5815.1
Revision Date: 27 November 1997
Expiry Date: 27 November 1999
---------------------------------------------------------------------
Contents:
1. Introduction
2. FTS-0005 flags
3. User flags
4. Approved zone 2 user flags
5. Flag implications
6. Invalid combinations
7. Baud rate field
8. Thanks to...
---------------------------------------------------------------------
1. Introduction
---------------
This document informs about known differences of FidoNet zone 2
nodelist flags from FTS-0005.003. The ultimate sources for these
informations are the current Z2 nodelist epilogue and the setup
for flag corrections at Z2C, but it may be difficult to get these
sources for readers in other zones.
| All changes since version 5 are marked by a bar at the left edge.
It is (again) possible to list V32b and V42b in zone 2, upper case
V32B or V42B is not more enforced. Currently new flags needed for
IP-connectivity are under test in zone 2 (only internally), e.g.
-&gt; VM VModem, default port 3141, dummy country code 000-
-&gt; IFC IFCico, default port 60179, dummy country code 000-
-&gt; BND BinkP, default port 24544, dummy country code 000-
-&gt; IP general IP connectivity, dummy country code 000-
-&gt; TELN Telnet dummy country code 000-
2. FTS-0005 flags
-----------------
The following flags are used as specified in FTS-0005.003:
CM Continuous Mail, node accepts mail 24 hours a day
MO Mailer Only (no BBS)
LO Listed Only, node accepts calls only from listed
node numbers in the current FidoNet nodelist
-&gt; V21 ITU-T V21 300 bps full duplex (obsolete)
V22 ITU-T V22 1200 bps full duplex (obsolescent)
| In zone 2 the value 1200 in the baud rate field implies V22. Only
| two nodes not supporting at least V22bis, ISDN, or IP still exist
| in the zone 2 segment. Flag V22 is almost obsolete, and V21 is
| already removed in Z2. Both flags should be dropped from the next
| FTS-0005 version.
V29 ITU-T V29 9600 bps half duplex (obsolescent)
-&gt; V33 ITU-T V33 14400 bps half duplex (obsolete)
V33 cannot be used in connecting FidoNet nodes over public dial-up
lines and is most probably a historical error in FTS-0005. A very
similar argument is applicable on V29, all nodes flying this flag
support at least V32. Today only one node in Z2 still flies V29,
and V33 is already removed in Z2. Both flags should be dropped in
the next FTS-0005 version.
V32 ITU-T V32 9600 bps full duplex
V32b ITU-T V32bis 14400 bps full duplex (implies V32)
| V34 ITU-T V34 28800 bps full duplex (33600 bps option)
FTS-0005 specifies V32b and V42b (capital V and small b), current
nodelist practice in FidoNet shows all combinations of small and
capital letters for flags. This was no problem before FSC-0062
introduced case-sensitive flags. The best solution is to stick to
the current practice and treat all old flags as case-insensitive.
H96 Hayes V9600
HST USR Courier HST up to 9600 (implies MNP)
H14 USR Courier HST up to 14400 (implies HST)
-&gt; H16 USR Courier HST up to 16800 (implies H14 and V42b)
MAX Microcom AX/96xx series (almost obsolete)
PEP Packet Ensemble Protocol
CSP Compucom Speedmodem
-&gt; ZYX Zyxel series 16800 bps (implies V32b and V42b)
-&gt; V32T V.32 Terbo 19200 bps (implies V32b)
VFC V.Fast Class 28800 bps (should imply V32b and V42b)
If a flag directly or indirectly implies other flags, then these
other flags are not shown in a nodelist entry, because this would
be redundant. Unfortunately the rules for redundancies in zone 2
and FTS-0005 are different. Zone 2 continued to avoid redundancy
with most "new" flags, but FTS-0005.003 specified no redundancies
for "new" flags like ZYX, H16, V32T, or VFC. "New" flags in this
context are flags approved by FidoNet International Coordinators
since 1989, when FTS-0005.TXT, the predecesssor of FTS-0005.003,
was published.
For details see the chapter "implications" below, for now only
note, that in zone 2 H16 implies V42b, ZYX implies V32b and V42b,
and V32T implies V32b.
Zone 1 and zone 2 have introduced a user flag Z19 approved by the
corresponding Zone Coordinator. User flags are discussed later,
for now only note, that in zone 2 ZYX is specified as Zyxel 16k8,
while FTS-0005.003 not knowing Z19 specifies ZYX as generic flag
for all Zyxel protocol speeds.
Today only one node in FidoNet still really flies MAX, this flag
is obsolete and should be dropped from FTS-0005. The flags CSP
(7 nodes worldwide) and H96 should be marked as obsolescent.
| MNP Microcom Networking Protocol 2-4 error correction
| V42 ITU-T LAP-M error correction w/ fallback to MNP 2-4
| V42b ITU-T V.42bis BTLZ data compression over V.42 LAP-M
The next version of FTS-0005 should adopt the better V42b and
MNP definitions of the zone 3 nodelist epilogue. FTS-0005.003
specifies an implication of V42 by V42b, but the exact meaning of
the flag MNP is unclear. Most probably this flag was meant to
| indicate support of MNP 2-4, and in this sense V42 implies MNP.
| Note the difference between the flag V42b (implying V42) and the
| standard V.42bis (not necessarily based on LAP-M as data link
| layer protocol), without this difference the flag V42b would be
| ambiguous for combined modem and ISDN node entries.
MN No compression supported in insecure inbound
XA Bark and WaZOO file/update requests
XB Bark file/update requests, WaZOO file requests
XC Bark file requests, WaZOO file/update requests
XP Bark file/update requests
XR Bark and WaZOO file requests
XW WaZOO file requests
XX WaZOO file/update requests
These flags are equivalent in FTS-0005 and in the zone 2 segment.
Gx..x Gateway to domain 'x..x'
Valid values for this flag are assigned by the Fido International
Coordinator, FTS-0005.003 explicitly mentions GUUCP. In zone 2
only GUUCP gateways are flagged.
#01 Zone 5 mail hour (01:00 - 02:00 UTC) w/ Bell 212A
#02 Zone 2 mail hour (02:30 - 03:30 UTC) w/ Bell 212A
-&gt; #08 Zone 4 mail hour (08:00 - 09:00 UTC) w/ Bell 212A
#09 Zone 1 mail hour (09:00 - 10:00 UTC) w/ Bell 212A
#18 Zone 3 mail hour (18:00 - 19:00 UTC) w/ Bell 212A
#20 Zone 6 mail hour (20:00 - 21:00 UTC) w/ Bell 212A
The variants !01, !02, !08, !09, !18, and !20 indicate missing
Bell 212A support. In zone 2 #02 or !02 would be obviously
redundant.
Today less than four 1200 modems (V22 or Bell 212A) are listed.
A future version of FTS-0005 should drop !mn variants together
with V21 and V22 flags.
Further most non-CM systems flagging #mn or !mn today probably
want to show additional online times instead of additional mail
hours. As soon as FSC-0062 flags have been approved by the IC
or adopted as FTS by the FTSC, the following version of FTS-0005
should mark #mn as obsolescent and recommend the more flexible
FSC-0062 flags (see below).
3. User flags
-------------
An example for one of several problems in zone 2 with user flags:
...,U,Z19,V110H,V120L,V120H,X75,ENC,NEC
These flags indicate a modern Zyxel ISDN-modem and two additional
user flags ENC and NEC. This possible user flags string contains
34 characters, but at most 32 characters are allowed in FTS-0005.
...,U,Z19,V110L,V110H,X75,ISDNA,ISDNB,ISDNC
During the period for the replacement of old by new ISDN flags
(several months !) many nodes listed both old and new flags for
maximal compatibility, and no problems with nodelist compilers
or mailers caused by too long user flags strings were reported.
Therefore the length limit in FTS-0005 is probably unnecessary
and at least inconsequent: Other nodelist fields like the system
name are unlimited, so why only restrict the user flags string ?
To help developpers an upper limit of e.g. 255 characters for a
nodelist line and 63 characters for fields 3 to 6 would be more
useful.
The next problem with user flag strings as specified in FTS-0005
is their introduction by the letter U with no comma following:
Nodelist compilers could parse ...,UISDN,USR in user flags ISDN
and USR. But USR cannot be approved as "real" flag, because the
combination ...,USR,UISDN would then be parsed in SR and UISDN.
Other side effects of the FTS-0005 specification are additional
difficulties in finding flags. Almost all flags are separated
by a comma, only the first user flag can be an exception to this
simple rule. If the order of user flags has no meaning, then...
...,UV120L,V120H
...,UV120H,V120L
... are equivalent. A "simple" solution of this problem could be
to treat UV120L as synonym for V120L, and UV120H as synonym for
V120H. Similar problems show up, if user flags are counted, etc.
Obviously a nodelist compiler looking for user flags has always
to consider the case "user flag separated by comma". In zone 2
this idea was simply extended to the first user flag:
All flags are separated by commas. Flags not yet approved by the
International Coordinator or the FTSC (i.e. user flags only used
experimentally or locally) are separated by a new pseudo flag U.
-&gt; U pseudo flag to the left of at least one user flag
All flags following this pseudo flag U are user flags, all flags
before this pseudo flag are "real" flags specified in FTS-0005 or
approved by the International Coordinator.
Because this definition should be compatible with any reasonable
software implementation based on FTS-0005.003, and simplifies the
handling of user flags significantly, a future FTS-0005 version
will hopefully adopt it.
4. Approved zone 2 user flags
-----------------------------
In zone 2 user flags have to be approved by the Zone Coordinator.
Currently the following zone 2 user flags exist:
-&gt; V110L ITU-T V.110 19k2 async 'Low' (former ISDNA)
-&gt; V110H ITU-T V.110 38k4 async 'High' (former ISDNB)
-&gt; V120L ITU-T V.120 56k6 async, N1 = 259, W = 7, modulo 8
-&gt; V120H ITU-T V.120 64k async, N1 = 259, W = 7, modulo 8
-&gt; X75 ITU-T X.75 SLP (single link procedure),
64kbit/s B channel; layer 2 max. framesize N1 = 2048,
window size W = 2, frame numbering modulo 8;
layer 3 transparent (no packet layer)
-&gt; ISDN Other configuration, used only if none of above fits
These ISDN flags follow the specification in FSC-0091.
-&gt; Tyz Online time flags as specified in FSC-0062
The flag Tyz is used by non-CM nodes online not only during ZMH,
y is a letter indicating the start and z a letter indicating the
end of the online period as defined below (times in UTC):
A 0:00, a 0:30, B 1:00, b 1:30, C 2:00, c 2:30,
D 3:00, d 3:30, E 4:00, e 4:30, F 5:00, f 5:30,
G 6:00, g 6:30, H 7:00, h 7:30, I 8:00, i 8:30,
J 9:00, j 9:30, K 10:00, k 10:30, L 11:00, l 11:30,
M 12:00, m 12:30, N 13:00, n 13:30, O 14:00, o 14:30,
P 15:00, p 15:30, Q 16:00, q 16:30, R 17:00, r 17:30,
S 18:00, s 18:30, T 19:00, t 19:30, U 20:00, u 20:30,
V 21:00, v 21:30, W 20:00, w 20:30, X 23:00, x 23:30.
For example TuB shows an online period from 20:30 until 1:00 UTC.
-&gt; Z19 Zyxel series 19200 bps (implies ZYX)
-&gt; X2C x2 client w/ 56000 bps (should imply V34 and V42b)
-&gt; X2S x2 server w/ 64000 bps (should imply V34 and V42b)
-&gt; K12 Systems offering all educational K12-conferences
-&gt; ENC The node accepts inbound encrypted mail
-&gt; NC Network Coordinator (only if the NC is not the host)
-&gt; NEC Net Echomail Coordinator (at most one per net)
-&gt; REC Region Echomail Coordinator (at most one per region)
Redundant AKAs used to indicate echomail coordination in zone 2
are no longer permitted. One *EC flag is valid for all AKAs of
a given sysop.
5. Flag implications
--------------------
Flag implications directly or indirectly specified in FTS-0005:
HST =&gt; MNP
H14 =&gt; MNP HST
H16 =&gt; MNP HST H14
V42b =&gt; V42 (MNP ?)
V32b =&gt; V32
Flag implications specified in the zone 2 nodelist epilogue:
HST =&gt; MNP
H14 =&gt; HST MNP
-&gt; H16 =&gt; V42 MNP V42b H14 HST
-&gt; V42b =&gt; V42 MNP
-&gt; ZYX =&gt; V42 MNP V42b V32 V32b
-&gt; Z19 =&gt; V42 MNP V42b V32 V32b ZYX
V32b =&gt; V32
-&gt; V32T =&gt; V32 V32b
-&gt; V110L =&gt; ISDN
-&gt; V110H =&gt; ISDN
-&gt; V120L =&gt; ISDN
-&gt; V120H =&gt; ISDN
-&gt; X75 =&gt; ISDN
The latter ISDN flag redundancies are a consequence of FSC-0091.
Maybe some of the following implications could be added in zone 2:
VFC =&gt; V32 V32b MNP V42 V42b
X2C =&gt; V34 MNP V42 V42b
X2S =&gt; V34 MNP V42 V42b
Flag implications (i.e. not listing redundant flags) have several
advantages: Some old nodelist tools are unable to handle too long
lines. Old flags like HST, MNP, V42, or V32 vanish automatically,
if they are implied by H16, V42b, V32b, or better. Redundancies
defined globally for the whole nodelist help to avoid flag errors.
6. Invalid combinations
-----------------------
All file request flags exclude each other (at most 1 is possible):
XA, XB, XC, XP, XR, XW, and XX. For flag checkers only supporting
implications a good approximation based on FTS-0005 definitions is
| XA =&gt; XW XR XP XB XC XX,
| XB =&gt; XW XR XP,
| XC =&gt; XW XR XX,
| XR =&gt; XW,
| XX =&gt; XW.
Further X2C cannot be combined with X2S, and FSC-62 Tyz-flags are
not possible with CM. Also Tyz with y = z is of course incorrect.
Some modem protocols are "proprietary" in a sense, that all today
known modems can fly at most one of the corresponding modem flags:
MAX, CSP, H96, PEP, HST, H14, H16, ZYX, and Z19.
A few "old" modem protocol flags are known to be invalid if used
together with "new" protocol flags, i.e. each "old" flag excludes
all "new" flags and vice versa:
"Old" in this sense are MAX, CSP, H96, HST, H14, V32, and PEP.
"New" in this sense are X2S, X2C, V34, VFC, V32T, and H16.
For Z2 add ZYX as "old" and Z19 as "new". A simple REXX script to
test some known inconsistencies is available as NLSCHECK.REX at
the site of the author. While erroneously listing redundant flags
causes no harm, other errors like combining V34 with HST or Z19
with H16 indicate serious problems, which can result in connection
failures or other damage.
7. Baud rate field
------------------
The baud rate field 7 in the nodelist as specified in FTS-0005 is
nearly useless today: Except from a few remaining 1200 and 2400
nodes almost all nodelist entries show either 9600 for all modem
protocols better than V22bis or 300 for ISDN (or IP) only nodes.
No more V21 or Bell 103 modems are listed for more than 2 years.
The baud rate values 19200 and 38400 specified in FTS-0005.003
have not been used in the FidoNet nodelist. So all a reasonable
nodelist compiler can do today, is treat 300 as indicator for
ISDN or IP only, and treat unknown or missing values in field 7
like 9600.
A new meaning for field 7 as speed field could be really useful.
An example is ZYX, if we would have 16800, 19200, 28800, and 33600
as speed values, then their combination with ZYX is all we need
technically, Z19 would be unnecessary. Another example is HST,
flags H14 and H16 are unnecessary, if HST is combined with 9600,
14400, 16800, 28800, or better. Variants of PEP could be shown in
the speed field without new flags. "Enhanced V32.terbo" could be
shown by 21600.
Most important: V34 may have the famous bug not allowing connects
from new "V34+", unless the caller disabled symbol rate 3429. If
"V34+" is indicated by speed 33600 or better, then an appropriate
setup for all kinds of V34 connects is possible.
A future version of FTS-0005 hopefully allows the following speed
values in field 7:
300 reserved for ISDN or IP only (for historical reasons)
1200 obsolete (either V.22 in Z2 / Z3, or Bell 212A in Z1)
2400 implies V22bis, qualifies as least common denominator
9600 default, used with PEP, V32, HST, H96, (CSP), (MAX)
12000 rare variant of V32
14400 used with V32b or HST (obsoleting H14)
16800 used with ZYX or HST (obsoleting H16)
19200 used with V32T or ZYX (obsoleting Z19)
21600 rare variant of V32T (no "H21" needed)
28800 used with VFC or V34
33600 used with V34 (no V34+ or V34b needed)
| 56000 used with X2C, X2S, or V.PCM
Allowing more than 12 speed values or allowing speed values above
64000 could break existing software (MakeNL, V7). Therefore the
next step in FidoNet could be, to add 12000, 14400, 16800, 19200,
21600, 28800, 33600, and 56000, where 19200 is already specified
in FTS-5 since 1989.
8. Thanks to...
---------------
Ben Baker St. Louis nodelist format
Rick Moore FTS-0005.TXT
David Nugent FTS-0005.003 and NLTOOLS
Jonny Bergdahl ERRFLAGS 2.6
Ward Dossche Zone 2 nodelist epilogue
David J. Thomas FSC-0062.003 (FRL-0062)
Jan Ceuleers FSC-0075.001 (FRL-0075)
Arjen Lentz FSC-0091.001 (FRL-0091)
Leonard Erickson CHECKNL 2.14 and many discussions in NET_DEV
Jim Barchuk LNDL 2.7
Marius Ellen FASTV7 2.04
| Jan Vermeulen, Ian Smith, Gisbert Rudolph, Carlos Fernandez Sanz,
| Tom Schlangen, Craig Ford, Pedro Lima, and many others...
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

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

@ -1,160 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Kludge for specifying addition e-mail reply addresses.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1006
Revision: 1
Title: Kludge for specifying addition e-mail reply addresses
Author: Ramon van der Winkel, 1:320/42.46
ramon@wsd.wline.se
Revision Date: 12 December 1997
Expiry Date: 12 December 1999
----------------------------------------------------------------------
Contents:
1. Scope
2. Background
3. Format
4. Implementation notes
5. Example
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
Abstract
--------
An Internet message can have several reply addresses. After gating
to FidoNet, the recipient is only presented with one of the reply
addresses. The others are lost. This is a suggestion for an
additional kludge to FSC-0035 to change that.
1. Scope
--------
This standard is specified for FTN netmail messages sent by a
FidoNet-to-Internet gateway to a recipient. Message editors will
have to support this to allow the user to select the reply address
to use.
2. Background
-------------
An Internet message has three headers to indicate where to send a
reply. These are, in order of priority, Reply-To:, Sender: and
From:. When a message is distributed by a mailing list, then one of
the headers could contain the e-mail address of the poster and one
of the other headers the address of the mailing list.
When the message is gated to FidoNet, the gateway currently selects
of the reply addresses and creates the message so that a reply will
return at the gateway and sent to this one address. The other
addresses are lost.
The FSC-0035 kludges REPLYTO and REPLYADDR allow for one return
address only. This is a proposal for an additional kludge inserted
by the gateway to specify an addtional reply address. The message
editor used by the recipient will present a list of all reply
addresses and allows the user to select the appropriate address.
This way, the user can send a message back to the mailing list (for
distribution), or to the e-mail address of the poster only.
3. Format
---------
Following the REPLYTO and REPLYADDR kludges, one or more kludges
with the name REPLYALSO can be inserted, each listing one possible
reply address.
@REPLYALSO &lt;e-mail address&gt;
Where &lt;e-mail address&gt; is in the form of
ramon@wsd.wline.se
or
wsd.wline.se!ramon
Each line MUST contain one address only.
4. Implementation notes
-----------------------
Gateways supporting the REPLYALSO kludge MUST put the the reply
address with the highest priority in the REPLYADDR kludge. The order
of priority is Reply-To:, Sender: and From: header. The other
addresses may be listed in any priority.
5. Example
----------
From: odinn@goldware.dk, 1:320/42
To: Ramon van der Winkel, 1:320/42.46
Subj: Another test
---------------------------------------
@INTL 1:320/42 1:320/42
@TOPT 46
@MSGID: wgmid$&lt;123455@goldware.dk&gt; 45AB23CD
@REPLYTO UUCP 1:320/42
@REPLYADDR odinn@goldware.dk
@REPLYALSO newftsc-l@brazerko.com
This message was distributed by the mailing list "New FTSC"
at brazerko.com.
...
A. Author contact data
----------------------
Ramon van der Winkel
Fidonet: 1:320/42.46
E-mail: ramon@wsd.wline.se
WWW: http://www2.sbbs.se/hp/ramon
B. History
----------
Rev.1, 971212: First release.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

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

@ -1,163 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Multiple recipient address specification to gateway.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1007
Revision: 1
Title: Multiple recipient address specification to gateway
Author: Ramon van der Winkel, 1:320/42.46
ramon@wsd.wline.se
Revision Date: 12 December 1997
Expiry Date: 12 December 1999
----------------------------------------------------------------------
Contents:
1. Scope
2. Background
3. Format
4. Implementation notes for gateways
5. Example
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
Abstract
--------
Private messages within FidoNet only have one recipient address.
Multiple copies of the same message have to be sent to a FidoNet-
to-Internet gateway in order to address multiple recipients. This is
a proposal to indicate the addresses of multiple recipients in the
body of the message sent to the gateway.
1. Scope
--------
This standard is specified for FTN netmail messages sent to a
FidoNet-to-Internet gateway. Users are able to add this information
manually, although message editors could support this and make it
transparent to the user.
2. Background
-------------
Three types of recipient addresses can be specified on the Internet
and are reflected in this suggestion: To, Cc and Bcc. "To" are the
primary recipient(s) of the message. "Cc" is short for Carbon Copy
and lists the recipients that are intended to receive the message as
"informational". The last option "Bcc" is short for Blind Carbon
Copy. Recipients lists as Bcc recipients will not show up in the
headers of the Internet message, but get a copy anyway.
3. Format
---------
Immediately following the kludge lines, one or more of the following
lines can be inserted in the message. If a To: line is present, then
these lines follow the To: line.
GW-To: &lt;e-mail address&gt;[,&lt;e-mail address&gt;[...]]
GW-Cc: &lt;e-mail address&gt;[,&lt;e-mail address&gt;[...]]
GW-Bcc: &lt;e-mail address&gt;[,&lt;e-mail address&gt;[...]]
Where &lt;e-mail address&gt; is in the form of
ramon@wsd.wline.se
or
wsd.wline.se!ramon
Multiple addresses can be specified on the same line, separated by a
comma with optionally spaces around the comma. There is no limit
regarding the length of the line. The line must be terminated by a
single carriage return.
The GW-To: line replaces the To: lines.
The reason for GW-Cc is that "Cc:" by itself is expanded by some
editors and used to generate multiple copies of a message.
4. Implementation notes for gateways
------------------------------------
Gateways supporting this format add the e-mail addresses mentioned
in any of these three headers to the envelope file and create on
outbound (probably UUCP or SMTP) body text message. Rules for the
maximum length of envelope files (if any) apply.
The headers section of the RFC822 message will list the e-mail
addresses under the To: and Cc: headers. A Bcc: header must not be
added!
5. Example
----------
From: Ramon van der Winkel, 1:320/42.46
To: UUCP, 1:320/42
Subj: New header test
---------------------------------------
@INTL 1:320/42 1:320/42
@FMPT 46
GW-To: groupElist@newftsc.org
GW-Cc: odinn@goldware.dk
GW-Bcc: groupAadmin@newftsc.org
Hi!
This is a test
Ramon
A. Author contact data
----------------------
Ramon van der Winkel
Fidonet: 1:320/42.46
E-mail: ramon@wsd.wline.se
WWW: http://www2.sbbs.se/hp/ramon
B. History
----------
Rev.1, 971212: First release.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

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

@ -1,276 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>New control lines for forwarding messages.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1008
Revision: 2
Title: New control lines for forwarded messages
Author: Michael Hohner, 2:2490/2520.17
Revision Date: 29 December 1997
Expiry Date: 29 December 1999
----------------------------------------------------------------------
Contents:
1. Specifications
2. Usage
3. Compatiblity
4. Known implementations
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
This revision is an update to FRL-0092.001. The basic specifications
are unchanged.
Abstract
--------
Most fidonet message editors offer a "forward" function. Using this
function a user A ("forwarder") can sort of "redirect" a message
from user B ("author") to another user C ("final recipient"), maybe
because the forwarder is not the correct recipient, or because the
final recipient is a better person to answer the message. The name
and address of the author are usually included in the forward in
free-text format. The message text is included in non-quoted format.
A problem arises when the final recipient wants to reply to the
author of the forwarded message. The forward contains the forwarder
as the sender. So the final recipient must insert the name and
address of the author manually, using the information contained in
the message text. The message editor of the final recipient can't do
this automatically because of the free-text format. The editor will
also use incorrect quote initials, which is at least irritating.
This document introduces 7 new control lines which contain the
header information of the original message. With these control lines
the message editor can use the original header information
automatically.
1. Specifications
-----------------
There are 7 new control lines: FWDFROM, FWDTO, FWDORIG, FWDDEST,
FWDSUBJ, FWDAREA, FWDMSGID. As all control lines they start with an
ASCII 01 character (SOH) followed by the control line name followed
by whitespace followed by the control line's content followed by
ASCII 13 (CR).
Please note that all these control lines do not have a colon (like
the control lines in FTS-0001). This would be just waste of space.
FWDFROM
-------
This control line contains the name of the original sender as found
in the FROM field of the original message. Leading and trailing
whitespace should be removed. This control line should be omitted
altogether if the FROM field is empty.
FWDTO
-----
This control line contains the name of the original recipient as
found in the TO field of the original message. Leading and trailing
whitespace should be removed. This control line should be omitted
altogether if the TO field is empty.
FWDORIG
-------
This control line contains the address of the original sender as
found in the ORIG field of the original message. The usual 5D ASCII
notation (zone:net/node.point@domain) should be used. This control
line should be omitted altogether if the address is not known.
FWDDEST
-------
This control line contains the address of the original recipient as
found in the DEST field of the original message. The usual 5D ASCII
notation (zone:net/node.point@domain) should be used. This control
line should be omitted altogether if the address is not known or
unsure (as it is the case with forwarded echomail messages).
FWDSUBJ
-------
This control line contains the subject line of the original message.
This control line should be omitted altogether if the SUBJ field is
empty.
This control line should by made optional for security reasons. Echo
manager passwords are too easily revealed with it.
FWDAREA
-------
This control line contains the name of the echomail area where the
original message was forwarded from. It should be omitted altogether
if the original message was not forwarded from an echomail area.
FWDMSGID
--------
This control line contains the MSGID control line of the original
message. It should be omitted altogether if a MSGID control line is
not present in the original message.
2. Usage
--------
When the "forward" function of the message editor is invoked, the
editor program should generate the proposed control lines from the
header of the original message. If the original message already was
a forwarded one (indicated by the presence of at least a FWDORIG
control line), the editor should keep all FWD* control lines and
should not add any FWD* control lines. This preserves the FWD*
control lines of the first forwarder, containing the header data of
the author of the original message.
The editor should not generate FWD* control lines, if the message
isn't to be forwarded. A mail forwarding robot may also generate
these control lines, if it not just readdresses the message.
When the "reply" function of the editor is invoked the program
should use the control lines' contents instead of the header
information. The control lines should not be included in the reply.
Since it may not be immediately clear whether the user wants to
reply to the forwarder or to the original sender, the editor should
offer a means to ignore the proposed control lines and start a
"normal" reply instead, e.g. by two distinct functions, by user
preference or a dialog.
Pseudo code:
forwarding_message:
if is_forwarded_message then
don't change FWD* control lines
else
add FWD* control lines
quoting_message:
if is_forwarded_message then
if reply_to_forwarder then
use header data (normal quoting)
else
use FWD* control lines
remove FWD* control lines from reply
else
use header data (normal quoting)
other_functions:
remove/ignore FWD* control lines
Example:
Message from Joe User to my boss node:
From: Joe User 1:234/567
To: Harry Herrmannsdoerfer 2:2490/2520
Subj: Some questions
@MSGID: 1:234/567 12345678
Text: Hello Harry!
...
Harry forwards the message to me:
From: Harry Herrmannsdoerfer 2:2490/2520
To: Michael Hohner 2:2490/2520.17
Subj: Joe's message
@FWDFROM Joe User
@FWDORIG 1:234/567
@FWDTO Harry Herrmannsdoerfer
@FWDDEST 2:2490/2520
@FWDSUBJ Some questions
@FWDMSGID 1:234/567 12345678
Text: Hi Michael!
...
My answer using the new control lines:
From: Michael Hohner 2:2490/2520.17
To: Joe User 1:234/567
Subj: Some questions
@REPLY: 1:234/567 12345678
Text: Hi Joe!
JU&gt; ...
...
3. Compatiblity
---------------
Editor programs which are not prepared for these proposed control
lines usually just ignore them and remove them from a reply. A reply
goes to the forwarder. Nothing gained and nothing lost.
4. Known implementations
------------------------
This proposal is implemented in the author's Fidonet editor
"FleetStreet for OS/2" (versions 1.17 and newer).
Also implemented in Odinn Sorensens Fidonet editor "GoldED"
(versions 3.00.Alpha5 and newer).
A. Contacting the author
------------------------
The author may be contacted electronically at the following
addresses:
Fidonet: 2:2490/2520.17
Internet: miho@osn.de
Suggestions, comments and corrections are always welcome.
B. History
----------
Rev.1, 19960912: First release as FSC-0092.001.
Rev.2, 19971229: Submitted as FSP.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

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

@ -1,143 +0,0 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Year 2000 issues in FTN software.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1009
Revision: 1
Title: Year 2000 issues in FTN software
Author: Michael Hohner, 2:2490/2520.17
Revision Date: 29 December 1997
Expiry Date: 29 December 1999
----------------------------------------------------------------------
Contents:
1. Introduction
2. Generating Fidonet timestamps
3. Interpreting Fidonet timestamps
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
Abstract
--------
The year 2000 causes problems in many computer programs which use
two-digit year numbers. Current Fidonet software faces the very same
problems. This FSP specifies procedures which enable FTN software to
run without problems after the year 2000.
1. Introduction
---------------
Software using two-digit year numbers may cause problems in the year
2000. When the year number rolls over from "99" to "00", some
software may interpret the resulting year number as "1900" instead
of "2000". Such programs may contain code like this:
calendar_year = year_number + 1900; /* wrong! */
Fidonet software faces the very same problem: the year number in
packed messages (see FTS-0001) has only two digits. Some programs
interpreting this number incorrectly may decide that messages from
the year 1900 are too old and discard them. Other programs probably
just display a wrong calendar year.
The long-term solution would be a transition to four-digit year
numbers. However, this would require new data formats and cause
every existing software to fail. So a short-term solution is
required, resulting in only minimal changes in software. This FSP
contains guidelines for proper year-number interpretation. The
author encourages all FTN software authors to check their software
for possible year-2000 problems (and release fixed versions during
the next three years).
2. Generating Fidonet timestamps
--------------------------------
This should not cause much headache. However, some software may use
the following algorithm:
year_number = calendar_year - 1900 /* wrong! */
This will result in a three-digit year number in 2000 and lead to
incorrect Fidonet timestamps.
One correct algorithm is:
year_number = calendar_year mod 100 /* correct! */
3. Interpreting Fidonet timestamps
----------------------------------
We can make use of the fact that Fidonet didn't exist before 1980,
i.e. no messages were created before 1980. So any year number
smaller than 80 can't mean "year 19xx", but can only mean "year
20xx". One algorithm for correct year number interpretation is:
if year_number &lt; 80 then
calendar_year = 2000 + year_number
else
calendar_year = 1900 + year_number
Fidonet software should only use the calendar year for further
processing, not the year number from the timestamp.
This solution will work until 2080, giving us another 80+ years to
finally let some innovation happen in Fidonet.
A. Contacting the author
------------------------
The author may be contacted electronically at the following
addresses:
Fidonet: 2:2490/2520.17
Internet: miho@osn.de
Suggestions, comments and corrections are always welcome.
B. History
----------
Rev.1, 19971229: Submitted as FSP.
**********************************************************************
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

10
html/ftsc/index.htm
View File

@ -12,7 +12,7 @@
</HEAD>
<BODY>
<BLOCKQUOTE>
<div align=right><h5>Last update 24-May-2003</h5></div>
<div align=right><h5>Last update 13-Jul-2003</h5></div>
<div align=center><h1>Fidonet Technical Standards</h1></div>
<h3>Introduction</h3>
@ -52,14 +52,6 @@ Michiel Broek.
<h3>FSP Documents</h3>
<ul>
<li><a href="fsp-1002.html">FSP-1002 Numeric reply indication in FTN subject lines, O.Sorensen</a>
<li><a href="fsp-1003.html">FSP-1003 Suggested use of Nodelist Fields, L.Kindness</a>
<li><a href="fsp-1004.html">FSP-1004 Standard Fidonet Addressing, L.Kindness</a>
<li><a href="fsp-1005.html">FSP-1005 Zone 2 nodelist flags, F.Ellermann</a>
<li><a href="fsp-1006.html">FSP-1006 Kludge for specifying e-mail reply addresses, R.v.d.Winkel</a>
<li><a href="fsp-1007.html">FSP-1007 Multiple recipient address specification to gateway, R.v.d.Winkel</a>
<li><a href="fsp-1008.html">FSP-1008 New control lines for forwarded messages, M.Hohner</a>
<li><a href="fsp-1009.html">FSP-1009 Year 2000 issues in FTN software, M.Hohner</a>
<li><a href="fsp-1011.html">FSP-1011 BinkP - a protocol for transferring Fidonet mail over reliable connections, Dima Maloff</a>
</ul>