diff --git a/html/Makefile b/html/Makefile
index b61bb07e..07900902 100644
--- a/html/Makefile
+++ b/html/Makefile
@@ -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
diff --git a/html/ftsc/fsp-1003.html b/html/ftsc/fsp-1003.html
deleted file mode 100755
index 00b039aa..00000000
--- a/html/ftsc/fsp-1003.html
+++ /dev/null
@@ -1,117 +0,0 @@
-
-
-
-Suggested use of Nodelist Fields.
-
-
-
-
-
-**********************************************************************
-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.
-
-
-**********************************************************************
-
-
-
Go Back
-
-
-
-
diff --git a/html/ftsc/fsp-1004.html b/html/ftsc/fsp-1004.html
deleted file mode 100755
index 56b2c8ee..00000000
--- a/html/ftsc/fsp-1004.html
+++ /dev/null
@@ -1,258 +0,0 @@
-
-
-
-Standard FidoNet Addressing.
-
-
-
-
-
-**********************************************************************
-FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication: FSP-1004
-Revision: 1
-Title: Standard Fidonet Addressing
-Author: Lee Kindness
-Revision Date: 15 May 1997
-Expiry Date: 15 May 1999
-----------------------------------------------------------------------
-Contents:
- 1. Standard Fidonet Addressing
- 2. Internet Gateway Addressing
- 3. Routing Address Syntax
-----------------------------------------------------------------------
-
-
-Status of this document
------------------------
-
- This document is a Fidonet Standards Proposal (FSP).
-
- This document specifies an optional Fidonet standard protocol for
- the Fidonet community, and requests discussion and suggestions for
- improvements.
-
- This document is released to the public domain, and may be used,
- copied or modified for any purpose whatever.
-
-
-Introduction
-------------
-
- This document describes the standard form of addressing in Fidonet
- today along with the common method of addressing via internet
- gateways. In addition it proposes an extended addressing syntax,
- useful for routing purposes. This is a draft for comments and
- suggestions.
-
-
-1. Standard Fidonet Addressing
-------------------------------
-
- Fidonet addressing uses the following format:
-
- ZZ:NN/FF.PP@DO
-
- where the fields refer to...
-
- ZZ - Zone Number: The zone the node is part of.
- Min: 1 Max: 32767
- If 'ZZ:' is missing then assume 1 as the zone.
-
- NN - Net Number: The network the node is a member of.
- Min: 1 Max: 32767
- Must be present.
-
- FF - Node Number: The actual node number.
- Min: -1 Max: 32767
- Must be present.
-
- PP - Point Number: If the system is a point rather than a node then
- this is their point number off the node.
- Min: 0 Max: 32767
- If '.PP' is missing then assume 0 (ie not a
- point) as the point number.
-
- DO - Domain: The name of the 'Fidonet Technology Network'.
- Maximum length of 8 characters. The domain
- should not include periods, thus 'fidonet.org'
- is invalid (should be fidonet).
- If '@DO' is missing then fidonet can be assumed.
-
- The following are all valid examples:
- 1:234/5.6@fidonet (a '5D' address) => 1:234/5.6@fidonet
- 2:34/6.78 (a '4D' address) => 2:34/6.78@fidonet
- 4:610/34 (a '3D' address) => 4:610/34.0@fidonet
- 123/45 (a '2D' address) => 1:123/45.0@fidonet
- 955:95/2@othernet (another FTN) => 955:95/2.0@othernet
- 2:259/-1 (node application) => 2:259/-1.0@fidonet
-
- The limits on each various part of the address are a result of
- fts-0005 (zone, net, node, point), fsc-0045 (domain) and Policy 4
- (-1 node address for node application).
-
-
-2. Internet Gateway Addressing
-------------------------------
-
- An internet user can send email/netmail to a fidonet user via one of
- the fidonet->internet gateway systems (it's out-with the scope of
- this document to describe the semantics of posting). The internet
- user would send an email to a Fidonet user by using an email address
- of the following syntax:
-
- user.name@pPP.fFF.nNN.zZZ.gateway.domain
-
- where the fields refer to...
-
- user.name - Name: Name of the user the email is being sent
- to, spaces replaced by periods.
-
- PP - Point Number: As Fidonet address (FA)
- If '.pPP' is missing 0 is assumed.
-
- FF - Node Number: As FA
- Must be present.
-
- NN - Net Number: As FA
- Must be present.
-
- ZZ - Zone Number: As FA
- Must be present.
-
- gate.way - Gateway: Internet domain of the gateway, for
- example 'fidonet.org'.
- Must be present.
-
- The following are all valid examples (assuming 'fidonet.org' is an
- internet gateway):
-
- joe.bloggs@p6.f5.n234.z1.fidonet.org => 1:234/5.6@fidonet
- harry.cat@p78.f6.n34.z2.fidonet.org => 2:34/6.78@fidonet
- i.be.jolly@f34.n610.z4.fidonet.org => 4:610/34.0@fidonet
-
- and if 'foo.bar.org.uk' is a gateway for 'othernet':
-
- louise.hat@f2.n95.z955.foo.bar.org.uk => 955:95/2.0@othernet
-
-
-3. Routing Address Syntax
--------------------------
-
- The two previous address types (Fidonet and Internet->Fidonet
- gateway) are common practice, this however is a suggested standard
- of addressing for routing tables. The routing address has the
- following syntax:
-
- DD:ZZ:RR:NN:HH:FF:PP
-
- where the fields refer to:
-
- DD - Domain: As FA
- Must be present, even if blank (ie a leading
- ':') to ensure we always have 6 ':'s in an
- address to aid pattern matching.
-
- ZZ - Zone Number: As FA
- Must be present.
-
- RR - Region Number: The region (from fts-0005 nodelist) that the
- following network is in.
- Min: 1 Max: 32767
- Must be present.
-
- NN - Net Number: As FA
- Must be present.
-
- HH - Hub: The hub (from fts-0005 nodelist) that the node
- is under, or 0 (host hub).
- Min: 1 Max: 32767
- Must be present.
-
- FF - Node Number: As FA
- Must be present.
-
- PP - Point Number: As FA
- Must be present.
-
- ':' has been chosen as the separator as it is not a POSIX regular
- expression character or globing character (where as '.' is) and thus
- always easy use of wildcards on the address. The following points
- should be noted:
-
- 1. All addresses have 6 ':'s
- 2. The domain is at the front, the address gets more specific to
- the right
- 3. Nodes have 0 as their point number
- 4. A zone net has identical zone, region and net fields
- 5. A region net has identical region and net fields
-
- Example fidonet addresses converted to routing addresses:
-
- fidonet:2:25:259:0:7:0 => 2:259/7.0@fidonet, region 25, hub 0
- fidonet:1:1:1:0:23:0 => 1:1/23.0@fidonet, zone 1 net
- :955:9551:95:300:45:0 => 955:95/45.0, region 9551, hub 300
- fidonet:2:25:25:0:0:0 => 2:25/0.0@fidonet, R25C
- cnet:12:34:341:100:1:7 => 12:341/1.7@cnet, region 34, hub 100
- :2:25:259:300:300:0 => 2:259/300.0, region 25, hub 300
-
- Example POSIX regular expression patterns on routing addresses:
-
- [a-z]*:[0-9]+:[0-9]+:[0-9]+:[0-9]+:[0-9]+:[0-9]+ (any address)
- [a-z]*(:[0-9]+)+ (any address)
- fidonet:2:25:[0-9]+:[0-9]+:[0-9]+:[0-9]+ (region 25 node)
- fidonet:2:25(:[0-9]+)+ (region 25 node)
- fidonet:1:12:125(:[0-9]+)+ (all net 1:125 nodes)
- fidonet:1:12:125:200(:[0-9]+)+ (all hub 1:125/200 downlinks)
- fidonet:1:12:125:200:2:[0-9]+ (all 1:125/2 points)
- fidonet:1:12:125:[0-9]+:(25|34|56):0
- (nodes 1:125/25.0, 1:125/34.0 and 1:125/56.0)
-
- Example 'DOS style' patterns on routing addresses:
-
- *:*:*:*:*:*:* (any address)
- fidonet:2:25:*:*:*:* (region 25 node)
- fidonet:1:12:125:*:*:* (all net 1:125 nodes)
- fidonet:1:12:125:200:*:* (all hub 1:125/200 downlinks)
- fidonet:1:12:125:200:2:* (all 1:125/2 points)
- fidonet:1:12:125:*:3*:0 (any net 1:125 nodes starting with 3)
- fidonet:1:12:125:*:3?:0 (net 1:125 nodes 30 thru 39)
-
- The standard doesn't define which standard of pattern matching to
- use, only the format of the addresses. These routing addresses would
- be used in routing tables and configurations.
-
-
-A. Author contact data
-----------------------
-
- Lee Kindness
- Fidonet: n/a
- E-mail: wangi@earthling.net
- WWW: http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html
-
-
-B. History
-----------
-
- Rev.1, 971101: First release as FSP, based on the Fidonews 14/20
- article. Transformed into FSP document by Odinn
- Sorensen.
-
-
-**********************************************************************
-
-
-Go Back
-
-
-
-
diff --git a/html/ftsc/fsp-1005.html b/html/ftsc/fsp-1005.html
deleted file mode 100755
index 023a18a6..00000000
--- a/html/ftsc/fsp-1005.html
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-Zone 2 nodelist flags.
-
-
-
-
-
-**********************************************************************
-FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication: FSP-1005
-Revision: 6
-Title: Zone 2 nodelist flags
-Author: Frank Ellermann, 2:240/5815.1
-Revision Date: 27 November 1997
-Expiry Date: 27 November 1999
----------------------------------------------------------------------
-Contents:
- 1. Introduction
- 2. FTS-0005 flags
- 3. User flags
- 4. Approved zone 2 user flags
- 5. Flag implications
- 6. Invalid combinations
- 7. Baud rate field
- 8. Thanks to...
----------------------------------------------------------------------
-
-
-1. Introduction
----------------
- This document informs about known differences of FidoNet zone 2
- nodelist flags from FTS-0005.003. The ultimate sources for these
- informations are the current Z2 nodelist epilogue and the setup
- for flag corrections at Z2C, but it may be difficult to get these
- sources for readers in other zones.
-
-| All changes since version 5 are marked by a bar at the left edge.
- It is (again) possible to list V32b and V42b in zone 2, upper case
- V32B or V42B is not more enforced. Currently new flags needed for
- IP-connectivity are under test in zone 2 (only internally), e.g.
-
- -> VM VModem, default port 3141, dummy country code 000-
- -> IFC IFCico, default port 60179, dummy country code 000-
- -> BND BinkP, default port 24544, dummy country code 000-
- -> IP general IP connectivity, dummy country code 000-
- -> TELN Telnet dummy country code 000-
-
-
-2. FTS-0005 flags
------------------
- The following flags are used as specified in FTS-0005.003:
-
- CM Continuous Mail, node accepts mail 24 hours a day
- MO Mailer Only (no BBS)
- LO Listed Only, node accepts calls only from listed
- node numbers in the current FidoNet nodelist
-
- -> V21 ITU-T V21 300 bps full duplex (obsolete)
- V22 ITU-T V22 1200 bps full duplex (obsolescent)
-
-| In zone 2 the value 1200 in the baud rate field implies V22. Only
-| two nodes not supporting at least V22bis, ISDN, or IP still exist
-| in the zone 2 segment. Flag V22 is almost obsolete, and V21 is
-| already removed in Z2. Both flags should be dropped from the next
-| FTS-0005 version.
-
- V29 ITU-T V29 9600 bps half duplex (obsolescent)
- -> V33 ITU-T V33 14400 bps half duplex (obsolete)
-
- V33 cannot be used in connecting FidoNet nodes over public dial-up
- lines and is most probably a historical error in FTS-0005. A very
- similar argument is applicable on V29, all nodes flying this flag
- support at least V32. Today only one node in Z2 still flies V29,
- and V33 is already removed in Z2. Both flags should be dropped in
- the next FTS-0005 version.
-
- V32 ITU-T V32 9600 bps full duplex
- V32b ITU-T V32bis 14400 bps full duplex (implies V32)
-| V34 ITU-T V34 28800 bps full duplex (33600 bps option)
-
- FTS-0005 specifies V32b and V42b (capital V and small b), current
- nodelist practice in FidoNet shows all combinations of small and
- capital letters for flags. This was no problem before FSC-0062
- introduced case-sensitive flags. The best solution is to stick to
- the current practice and treat all old flags as case-insensitive.
-
- H96 Hayes V9600
- HST USR Courier HST up to 9600 (implies MNP)
- H14 USR Courier HST up to 14400 (implies HST)
- -> H16 USR Courier HST up to 16800 (implies H14 and V42b)
- MAX Microcom AX/96xx series (almost obsolete)
- PEP Packet Ensemble Protocol
- CSP Compucom Speedmodem
- -> ZYX Zyxel series 16800 bps (implies V32b and V42b)
- -> V32T V.32 Terbo 19200 bps (implies V32b)
- VFC V.Fast Class 28800 bps (should imply V32b and V42b)
-
- If a flag directly or indirectly implies other flags, then these
- other flags are not shown in a nodelist entry, because this would
- be redundant. Unfortunately the rules for redundancies in zone 2
- and FTS-0005 are different. Zone 2 continued to avoid redundancy
- with most "new" flags, but FTS-0005.003 specified no redundancies
- for "new" flags like ZYX, H16, V32T, or VFC. "New" flags in this
- context are flags approved by FidoNet International Coordinators
- since 1989, when FTS-0005.TXT, the predecesssor of FTS-0005.003,
- was published.
-
- For details see the chapter "implications" below, for now only
- note, that in zone 2 H16 implies V42b, ZYX implies V32b and V42b,
- and V32T implies V32b.
-
- Zone 1 and zone 2 have introduced a user flag Z19 approved by the
- corresponding Zone Coordinator. User flags are discussed later,
- for now only note, that in zone 2 ZYX is specified as Zyxel 16k8,
- while FTS-0005.003 not knowing Z19 specifies ZYX as generic flag
- for all Zyxel protocol speeds.
-
- Today only one node in FidoNet still really flies MAX, this flag
- is obsolete and should be dropped from FTS-0005. The flags CSP
- (7 nodes worldwide) and H96 should be marked as obsolescent.
-
-| MNP Microcom Networking Protocol 2-4 error correction
-| V42 ITU-T LAP-M error correction w/ fallback to MNP 2-4
-| V42b ITU-T V.42bis BTLZ data compression over V.42 LAP-M
-
- The next version of FTS-0005 should adopt the better V42b and
- MNP definitions of the zone 3 nodelist epilogue. FTS-0005.003
- specifies an implication of V42 by V42b, but the exact meaning of
- the flag MNP is unclear. Most probably this flag was meant to
-| indicate support of MNP 2-4, and in this sense V42 implies MNP.
-
-| Note the difference between the flag V42b (implying V42) and the
-| standard V.42bis (not necessarily based on LAP-M as data link
-| layer protocol), without this difference the flag V42b would be
-| ambiguous for combined modem and ISDN node entries.
-
- MN No compression supported in insecure inbound
-
- XA Bark and WaZOO file/update requests
- XB Bark file/update requests, WaZOO file requests
- XC Bark file requests, WaZOO file/update requests
- XP Bark file/update requests
- XR Bark and WaZOO file requests
- XW WaZOO file requests
- XX WaZOO file/update requests
-
- These flags are equivalent in FTS-0005 and in the zone 2 segment.
-
- Gx..x Gateway to domain 'x..x'
-
- Valid values for this flag are assigned by the Fido International
- Coordinator, FTS-0005.003 explicitly mentions GUUCP. In zone 2
- only GUUCP gateways are flagged.
-
- #01 Zone 5 mail hour (01:00 - 02:00 UTC) w/ Bell 212A
- #02 Zone 2 mail hour (02:30 - 03:30 UTC) w/ Bell 212A
- -> #08 Zone 4 mail hour (08:00 - 09:00 UTC) w/ Bell 212A
- #09 Zone 1 mail hour (09:00 - 10:00 UTC) w/ Bell 212A
- #18 Zone 3 mail hour (18:00 - 19:00 UTC) w/ Bell 212A
- #20 Zone 6 mail hour (20:00 - 21:00 UTC) w/ Bell 212A
-
- The variants !01, !02, !08, !09, !18, and !20 indicate missing
- Bell 212A support. In zone 2 #02 or !02 would be obviously
- redundant.
-
- Today less than four 1200 modems (V22 or Bell 212A) are listed.
- A future version of FTS-0005 should drop !mn variants together
- with V21 and V22 flags.
-
- Further most non-CM systems flagging #mn or !mn today probably
- want to show additional online times instead of additional mail
- hours. As soon as FSC-0062 flags have been approved by the IC
- or adopted as FTS by the FTSC, the following version of FTS-0005
- should mark #mn as obsolescent and recommend the more flexible
- FSC-0062 flags (see below).
-
-
-3. User flags
--------------
- An example for one of several problems in zone 2 with user flags:
-
- ...,U,Z19,V110H,V120L,V120H,X75,ENC,NEC
-
- These flags indicate a modern Zyxel ISDN-modem and two additional
- user flags ENC and NEC. This possible user flags string contains
- 34 characters, but at most 32 characters are allowed in FTS-0005.
-
- ...,U,Z19,V110L,V110H,X75,ISDNA,ISDNB,ISDNC
-
- During the period for the replacement of old by new ISDN flags
- (several months !) many nodes listed both old and new flags for
- maximal compatibility, and no problems with nodelist compilers
- or mailers caused by too long user flags strings were reported.
-
- Therefore the length limit in FTS-0005 is probably unnecessary
- and at least inconsequent: Other nodelist fields like the system
- name are unlimited, so why only restrict the user flags string ?
- To help developpers an upper limit of e.g. 255 characters for a
- nodelist line and 63 characters for fields 3 to 6 would be more
- useful.
-
- The next problem with user flag strings as specified in FTS-0005
- is their introduction by the letter U with no comma following:
-
- Nodelist compilers could parse ...,UISDN,USR in user flags ISDN
- and USR. But USR cannot be approved as "real" flag, because the
- combination ...,USR,UISDN would then be parsed in SR and UISDN.
-
- Other side effects of the FTS-0005 specification are additional
- difficulties in finding flags. Almost all flags are separated
- by a comma, only the first user flag can be an exception to this
- simple rule. If the order of user flags has no meaning, then...
-
- ...,UV120L,V120H
- ...,UV120H,V120L
-
- ... are equivalent. A "simple" solution of this problem could be
- to treat UV120L as synonym for V120L, and UV120H as synonym for
- V120H. Similar problems show up, if user flags are counted, etc.
-
- Obviously a nodelist compiler looking for user flags has always
- to consider the case "user flag separated by comma". In zone 2
- this idea was simply extended to the first user flag:
-
- All flags are separated by commas. Flags not yet approved by the
- International Coordinator or the FTSC (i.e. user flags only used
- experimentally or locally) are separated by a new pseudo flag U.
-
- -> U pseudo flag to the left of at least one user flag
-
- All flags following this pseudo flag U are user flags, all flags
- before this pseudo flag are "real" flags specified in FTS-0005 or
- approved by the International Coordinator.
-
- Because this definition should be compatible with any reasonable
- software implementation based on FTS-0005.003, and simplifies the
- handling of user flags significantly, a future FTS-0005 version
- will hopefully adopt it.
-
-
-4. Approved zone 2 user flags
------------------------------
- In zone 2 user flags have to be approved by the Zone Coordinator.
- Currently the following zone 2 user flags exist:
-
- -> V110L ITU-T V.110 19k2 async 'Low' (former ISDNA)
- -> V110H ITU-T V.110 38k4 async 'High' (former ISDNB)
- -> V120L ITU-T V.120 56k6 async, N1 = 259, W = 7, modulo 8
- -> V120H ITU-T V.120 64k async, N1 = 259, W = 7, modulo 8
- -> X75 ITU-T X.75 SLP (single link procedure),
- 64kbit/s B channel; layer 2 max. framesize N1 = 2048,
- window size W = 2, frame numbering modulo 8;
- layer 3 transparent (no packet layer)
- -> ISDN Other configuration, used only if none of above fits
-
- These ISDN flags follow the specification in FSC-0091.
-
- -> Tyz Online time flags as specified in FSC-0062
-
- The flag Tyz is used by non-CM nodes online not only during ZMH,
- y is a letter indicating the start and z a letter indicating the
- end of the online period as defined below (times in UTC):
-
- A 0:00, a 0:30, B 1:00, b 1:30, C 2:00, c 2:30,
- D 3:00, d 3:30, E 4:00, e 4:30, F 5:00, f 5:30,
- G 6:00, g 6:30, H 7:00, h 7:30, I 8:00, i 8:30,
- J 9:00, j 9:30, K 10:00, k 10:30, L 11:00, l 11:30,
- M 12:00, m 12:30, N 13:00, n 13:30, O 14:00, o 14:30,
- P 15:00, p 15:30, Q 16:00, q 16:30, R 17:00, r 17:30,
- S 18:00, s 18:30, T 19:00, t 19:30, U 20:00, u 20:30,
- V 21:00, v 21:30, W 20:00, w 20:30, X 23:00, x 23:30.
-
- For example TuB shows an online period from 20:30 until 1:00 UTC.
-
- -> Z19 Zyxel series 19200 bps (implies ZYX)
- -> X2C x2 client w/ 56000 bps (should imply V34 and V42b)
- -> X2S x2 server w/ 64000 bps (should imply V34 and V42b)
-
- -> K12 Systems offering all educational K12-conferences
- -> ENC The node accepts inbound encrypted mail
-
- -> NC Network Coordinator (only if the NC is not the host)
- -> NEC Net Echomail Coordinator (at most one per net)
- -> REC Region Echomail Coordinator (at most one per region)
-
- Redundant AKAs used to indicate echomail coordination in zone 2
- are no longer permitted. One *EC flag is valid for all AKAs of
- a given sysop.
-
-
-5. Flag implications
---------------------
- Flag implications directly or indirectly specified in FTS-0005:
-
- HST => MNP
- H14 => MNP HST
- H16 => MNP HST H14
- V42b => V42 (MNP ?)
- V32b => V32
-
- Flag implications specified in the zone 2 nodelist epilogue:
-
- HST => MNP
- H14 => HST MNP
- -> H16 => V42 MNP V42b H14 HST
- -> V42b => V42 MNP
- -> ZYX => V42 MNP V42b V32 V32b
- -> Z19 => V42 MNP V42b V32 V32b ZYX
- V32b => V32
- -> V32T => V32 V32b
-
- -> V110L => ISDN
- -> V110H => ISDN
- -> V120L => ISDN
- -> V120H => ISDN
- -> X75 => ISDN
-
- The latter ISDN flag redundancies are a consequence of FSC-0091.
- Maybe some of the following implications could be added in zone 2:
-
- VFC => V32 V32b MNP V42 V42b
- X2C => V34 MNP V42 V42b
- X2S => V34 MNP V42 V42b
-
- Flag implications (i.e. not listing redundant flags) have several
- advantages: Some old nodelist tools are unable to handle too long
- lines. Old flags like HST, MNP, V42, or V32 vanish automatically,
- if they are implied by H16, V42b, V32b, or better. Redundancies
- defined globally for the whole nodelist help to avoid flag errors.
-
-
-6. Invalid combinations
------------------------
- All file request flags exclude each other (at most 1 is possible):
- XA, XB, XC, XP, XR, XW, and XX. For flag checkers only supporting
- implications a good approximation based on FTS-0005 definitions is
-
-| XA => XW XR XP XB XC XX,
-| XB => XW XR XP,
-| XC => XW XR XX,
-| XR => XW,
-| XX => XW.
-
- Further X2C cannot be combined with X2S, and FSC-62 Tyz-flags are
- not possible with CM. Also Tyz with y = z is of course incorrect.
-
- Some modem protocols are "proprietary" in a sense, that all today
- known modems can fly at most one of the corresponding modem flags:
- MAX, CSP, H96, PEP, HST, H14, H16, ZYX, and Z19.
-
- A few "old" modem protocol flags are known to be invalid if used
- together with "new" protocol flags, i.e. each "old" flag excludes
- all "new" flags and vice versa:
-
- "Old" in this sense are MAX, CSP, H96, HST, H14, V32, and PEP.
- "New" in this sense are X2S, X2C, V34, VFC, V32T, and H16.
-
- For Z2 add ZYX as "old" and Z19 as "new". A simple REXX script to
- test some known inconsistencies is available as NLSCHECK.REX at
- the site of the author. While erroneously listing redundant flags
- causes no harm, other errors like combining V34 with HST or Z19
- with H16 indicate serious problems, which can result in connection
- failures or other damage.
-
-
-7. Baud rate field
-------------------
- The baud rate field 7 in the nodelist as specified in FTS-0005 is
- nearly useless today: Except from a few remaining 1200 and 2400
- nodes almost all nodelist entries show either 9600 for all modem
- protocols better than V22bis or 300 for ISDN (or IP) only nodes.
- No more V21 or Bell 103 modems are listed for more than 2 years.
-
- The baud rate values 19200 and 38400 specified in FTS-0005.003
- have not been used in the FidoNet nodelist. So all a reasonable
- nodelist compiler can do today, is treat 300 as indicator for
- ISDN or IP only, and treat unknown or missing values in field 7
- like 9600.
-
- A new meaning for field 7 as speed field could be really useful.
- An example is ZYX, if we would have 16800, 19200, 28800, and 33600
- as speed values, then their combination with ZYX is all we need
- technically, Z19 would be unnecessary. Another example is HST,
- flags H14 and H16 are unnecessary, if HST is combined with 9600,
- 14400, 16800, 28800, or better. Variants of PEP could be shown in
- the speed field without new flags. "Enhanced V32.terbo" could be
- shown by 21600.
-
- Most important: V34 may have the famous bug not allowing connects
- from new "V34+", unless the caller disabled symbol rate 3429. If
- "V34+" is indicated by speed 33600 or better, then an appropriate
- setup for all kinds of V34 connects is possible.
-
- A future version of FTS-0005 hopefully allows the following speed
- values in field 7:
-
- 300 reserved for ISDN or IP only (for historical reasons)
- 1200 obsolete (either V.22 in Z2 / Z3, or Bell 212A in Z1)
- 2400 implies V22bis, qualifies as least common denominator
- 9600 default, used with PEP, V32, HST, H96, (CSP), (MAX)
- 12000 rare variant of V32
- 14400 used with V32b or HST (obsoleting H14)
- 16800 used with ZYX or HST (obsoleting H16)
- 19200 used with V32T or ZYX (obsoleting Z19)
- 21600 rare variant of V32T (no "H21" needed)
- 28800 used with VFC or V34
- 33600 used with V34 (no V34+ or V34b needed)
-| 56000 used with X2C, X2S, or V.PCM
-
- Allowing more than 12 speed values or allowing speed values above
- 64000 could break existing software (MakeNL, V7). Therefore the
- next step in FidoNet could be, to add 12000, 14400, 16800, 19200,
- 21600, 28800, 33600, and 56000, where 19200 is already specified
- in FTS-5 since 1989.
-
-
-8. Thanks to...
----------------
- Ben Baker St. Louis nodelist format
- Rick Moore FTS-0005.TXT
- David Nugent FTS-0005.003 and NLTOOLS
- Jonny Bergdahl ERRFLAGS 2.6
- Ward Dossche Zone 2 nodelist epilogue
- David J. Thomas FSC-0062.003 (FRL-0062)
- Jan Ceuleers FSC-0075.001 (FRL-0075)
- Arjen Lentz FSC-0091.001 (FRL-0091)
- Leonard Erickson CHECKNL 2.14 and many discussions in NET_DEV
- Jim Barchuk LNDL 2.7
- Marius Ellen FASTV7 2.04
-| Jan Vermeulen, Ian Smith, Gisbert Rudolph, Carlos Fernandez Sanz,
-| Tom Schlangen, Craig Ford, Pedro Lima, and many others...
-
-
-**********************************************************************
-
-
-Go Back
-
-
-
-
diff --git a/html/ftsc/fsp-1006.html b/html/ftsc/fsp-1006.html
deleted file mode 100755
index 6ff9de32..00000000
--- a/html/ftsc/fsp-1006.html
+++ /dev/null
@@ -1,160 +0,0 @@
-
-
-
-Kludge for specifying addition e-mail reply addresses.
-
-
-
-
-
-**********************************************************************
-FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication: FSP-1006
-Revision: 1
-Title: Kludge for specifying addition e-mail reply addresses
-Author: Ramon van der Winkel, 1:320/42.46
- ramon@wsd.wline.se
-Revision Date: 12 December 1997
-Expiry Date: 12 December 1999
-----------------------------------------------------------------------
-Contents:
- 1. Scope
- 2. Background
- 3. Format
- 4. Implementation notes
- 5. Example
-----------------------------------------------------------------------
-
-
-Status of this document
------------------------
-
- This document is a Fidonet Standards Proposal (FSP).
-
- This document specifies an optional Fidonet standard protocol for
- the Fidonet community, and requests discussion and suggestions for
- improvements.
-
- This document is released to the public domain, and may be used,
- copied or modified for any purpose whatever.
-
-
-Abstract
---------
-
- An Internet message can have several reply addresses. After gating
- to FidoNet, the recipient is only presented with one of the reply
- addresses. The others are lost. This is a suggestion for an
- additional kludge to FSC-0035 to change that.
-
-
-1. Scope
---------
-
- This standard is specified for FTN netmail messages sent by a
- FidoNet-to-Internet gateway to a recipient. Message editors will
- have to support this to allow the user to select the reply address
- to use.
-
-
-2. Background
--------------
-
- An Internet message has three headers to indicate where to send a
- reply. These are, in order of priority, Reply-To:, Sender: and
- From:. When a message is distributed by a mailing list, then one of
- the headers could contain the e-mail address of the poster and one
- of the other headers the address of the mailing list.
-
- When the message is gated to FidoNet, the gateway currently selects
- of the reply addresses and creates the message so that a reply will
- return at the gateway and sent to this one address. The other
- addresses are lost.
-
- The FSC-0035 kludges REPLYTO and REPLYADDR allow for one return
- address only. This is a proposal for an additional kludge inserted
- by the gateway to specify an addtional reply address. The message
- editor used by the recipient will present a list of all reply
- addresses and allows the user to select the appropriate address.
-
- This way, the user can send a message back to the mailing list (for
- distribution), or to the e-mail address of the poster only.
-
-
-3. Format
----------
-
- Following the REPLYTO and REPLYADDR kludges, one or more kludges
- with the name REPLYALSO can be inserted, each listing one possible
- reply address.
-
- @REPLYALSO <e-mail address>
-
- Where <e-mail address> is in the form of
-
- ramon@wsd.wline.se
- or
- wsd.wline.se!ramon
-
- Each line MUST contain one address only.
-
-
-4. Implementation notes
------------------------
-
- Gateways supporting the REPLYALSO kludge MUST put the the reply
- address with the highest priority in the REPLYADDR kludge. The order
- of priority is Reply-To:, Sender: and From: header. The other
- addresses may be listed in any priority.
-
-
-5. Example
-----------
-
- From: odinn@goldware.dk, 1:320/42
- To: Ramon van der Winkel, 1:320/42.46
- Subj: Another test
- ---------------------------------------
- @INTL 1:320/42 1:320/42
- @TOPT 46
- @MSGID: wgmid$<123455@goldware.dk> 45AB23CD
- @REPLYTO UUCP 1:320/42
- @REPLYADDR odinn@goldware.dk
- @REPLYALSO newftsc-l@brazerko.com
- This message was distributed by the mailing list "New FTSC"
- at brazerko.com.
-
- ...
-
-
-A. Author contact data
-----------------------
-
- Ramon van der Winkel
- Fidonet: 1:320/42.46
- E-mail: ramon@wsd.wline.se
- WWW: http://www2.sbbs.se/hp/ramon
-
-
-B. History
-----------
-
- Rev.1, 971212: First release.
-
-
-**********************************************************************
-
-
-Go Back
-
-
-
-
diff --git a/html/ftsc/fsp-1007.html b/html/ftsc/fsp-1007.html
deleted file mode 100755
index 5862e16f..00000000
--- a/html/ftsc/fsp-1007.html
+++ /dev/null
@@ -1,163 +0,0 @@
-
-
-
-Multiple recipient address specification to gateway.
-
-
-
-
-
-**********************************************************************
-FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication: FSP-1007
-Revision: 1
-Title: Multiple recipient address specification to gateway
-Author: Ramon van der Winkel, 1:320/42.46
- ramon@wsd.wline.se
-Revision Date: 12 December 1997
-Expiry Date: 12 December 1999
-----------------------------------------------------------------------
-Contents:
- 1. Scope
- 2. Background
- 3. Format
- 4. Implementation notes for gateways
- 5. Example
-----------------------------------------------------------------------
-
-
-Status of this document
------------------------
-
- This document is a Fidonet Standards Proposal (FSP).
-
- This document specifies an optional Fidonet standard protocol for
- the Fidonet community, and requests discussion and suggestions for
- improvements.
-
- This document is released to the public domain, and may be used,
- copied or modified for any purpose whatever.
-
-
-Abstract
---------
-
- Private messages within FidoNet only have one recipient address.
- Multiple copies of the same message have to be sent to a FidoNet-
- to-Internet gateway in order to address multiple recipients. This is
- a proposal to indicate the addresses of multiple recipients in the
- body of the message sent to the gateway.
-
-
-1. Scope
---------
-
- This standard is specified for FTN netmail messages sent to a
- FidoNet-to-Internet gateway. Users are able to add this information
- manually, although message editors could support this and make it
- transparent to the user.
-
-
-2. Background
--------------
-
- Three types of recipient addresses can be specified on the Internet
- and are reflected in this suggestion: To, Cc and Bcc. "To" are the
- primary recipient(s) of the message. "Cc" is short for Carbon Copy
- and lists the recipients that are intended to receive the message as
- "informational". The last option "Bcc" is short for Blind Carbon
- Copy. Recipients lists as Bcc recipients will not show up in the
- headers of the Internet message, but get a copy anyway.
-
-
-3. Format
----------
-
- Immediately following the kludge lines, one or more of the following
- lines can be inserted in the message. If a To: line is present, then
- these lines follow the To: line.
-
- GW-To: <e-mail address>[,<e-mail address>[...]]
- GW-Cc: <e-mail address>[,<e-mail address>[...]]
- GW-Bcc: <e-mail address>[,<e-mail address>[...]]
-
- Where <e-mail address> is in the form of
-
- ramon@wsd.wline.se
- or
- wsd.wline.se!ramon
-
- Multiple addresses can be specified on the same line, separated by a
- comma with optionally spaces around the comma. There is no limit
- regarding the length of the line. The line must be terminated by a
- single carriage return.
-
- The GW-To: line replaces the To: lines.
-
- The reason for GW-Cc is that "Cc:" by itself is expanded by some
- editors and used to generate multiple copies of a message.
-
-
-4. Implementation notes for gateways
-------------------------------------
-
- Gateways supporting this format add the e-mail addresses mentioned
- in any of these three headers to the envelope file and create on
- outbound (probably UUCP or SMTP) body text message. Rules for the
- maximum length of envelope files (if any) apply.
-
- The headers section of the RFC822 message will list the e-mail
- addresses under the To: and Cc: headers. A Bcc: header must not be
- added!
-
-
-5. Example
-----------
-
- From: Ramon van der Winkel, 1:320/42.46
- To: UUCP, 1:320/42
- Subj: New header test
- ---------------------------------------
- @INTL 1:320/42 1:320/42
- @FMPT 46
- GW-To: groupElist@newftsc.org
- GW-Cc: odinn@goldware.dk
- GW-Bcc: groupAadmin@newftsc.org
- Hi!
-
- This is a test
-
- Ramon
-
-
-A. Author contact data
-----------------------
-
- Ramon van der Winkel
- Fidonet: 1:320/42.46
- E-mail: ramon@wsd.wline.se
- WWW: http://www2.sbbs.se/hp/ramon
-
-
-B. History
-----------
-
- Rev.1, 971212: First release.
-
-
-**********************************************************************
-
-
-Go Back
-
-
-
-
diff --git a/html/ftsc/fsp-1008.html b/html/ftsc/fsp-1008.html
deleted file mode 100755
index 0eedb418..00000000
--- a/html/ftsc/fsp-1008.html
+++ /dev/null
@@ -1,276 +0,0 @@
-
-
-
-New control lines for forwarding messages.
-
-
-
-
-
-**********************************************************************
-FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication: FSP-1008
-Revision: 2
-Title: New control lines for forwarded messages
-Author: Michael Hohner, 2:2490/2520.17
-Revision Date: 29 December 1997
-Expiry Date: 29 December 1999
-----------------------------------------------------------------------
-Contents:
- 1. Specifications
- 2. Usage
- 3. Compatiblity
- 4. Known implementations
-----------------------------------------------------------------------
-
-
-Status of this document
------------------------
-
- This document is a Fidonet Standards Proposal (FSP).
-
- This document specifies an optional Fidonet standard protocol for
- the Fidonet community, and requests discussion and suggestions for
- improvements.
-
- This document is released to the public domain, and may be used,
- copied or modified for any purpose whatever.
-
- This revision is an update to FRL-0092.001. The basic specifications
- are unchanged.
-
-
-Abstract
---------
-
- Most fidonet message editors offer a "forward" function. Using this
- function a user A ("forwarder") can sort of "redirect" a message
- from user B ("author") to another user C ("final recipient"), maybe
- because the forwarder is not the correct recipient, or because the
- final recipient is a better person to answer the message. The name
- and address of the author are usually included in the forward in
- free-text format. The message text is included in non-quoted format.
-
- A problem arises when the final recipient wants to reply to the
- author of the forwarded message. The forward contains the forwarder
- as the sender. So the final recipient must insert the name and
- address of the author manually, using the information contained in
- the message text. The message editor of the final recipient can't do
- this automatically because of the free-text format. The editor will
- also use incorrect quote initials, which is at least irritating.
-
- This document introduces 7 new control lines which contain the
- header information of the original message. With these control lines
- the message editor can use the original header information
- automatically.
-
-
-1. Specifications
------------------
-
- There are 7 new control lines: FWDFROM, FWDTO, FWDORIG, FWDDEST,
- FWDSUBJ, FWDAREA, FWDMSGID. As all control lines they start with an
- ASCII 01 character (SOH) followed by the control line name followed
- by whitespace followed by the control line's content followed by
- ASCII 13 (CR).
-
- Please note that all these control lines do not have a colon (like
- the control lines in FTS-0001). This would be just waste of space.
-
- FWDFROM
- -------
-
- This control line contains the name of the original sender as found
- in the FROM field of the original message. Leading and trailing
- whitespace should be removed. This control line should be omitted
- altogether if the FROM field is empty.
-
- FWDTO
- -----
-
- This control line contains the name of the original recipient as
- found in the TO field of the original message. Leading and trailing
- whitespace should be removed. This control line should be omitted
- altogether if the TO field is empty.
-
- FWDORIG
- -------
-
- This control line contains the address of the original sender as
- found in the ORIG field of the original message. The usual 5D ASCII
- notation (zone:net/node.point@domain) should be used. This control
- line should be omitted altogether if the address is not known.
-
- FWDDEST
- -------
-
- This control line contains the address of the original recipient as
- found in the DEST field of the original message. The usual 5D ASCII
- notation (zone:net/node.point@domain) should be used. This control
- line should be omitted altogether if the address is not known or
- unsure (as it is the case with forwarded echomail messages).
-
- FWDSUBJ
- -------
-
- This control line contains the subject line of the original message.
- This control line should be omitted altogether if the SUBJ field is
- empty.
-
- This control line should by made optional for security reasons. Echo
- manager passwords are too easily revealed with it.
-
- FWDAREA
- -------
-
- This control line contains the name of the echomail area where the
- original message was forwarded from. It should be omitted altogether
- if the original message was not forwarded from an echomail area.
-
- FWDMSGID
- --------
-
- This control line contains the MSGID control line of the original
- message. It should be omitted altogether if a MSGID control line is
- not present in the original message.
-
-
-2. Usage
---------
-
- When the "forward" function of the message editor is invoked, the
- editor program should generate the proposed control lines from the
- header of the original message. If the original message already was
- a forwarded one (indicated by the presence of at least a FWDORIG
- control line), the editor should keep all FWD* control lines and
- should not add any FWD* control lines. This preserves the FWD*
- control lines of the first forwarder, containing the header data of
- the author of the original message.
-
- The editor should not generate FWD* control lines, if the message
- isn't to be forwarded. A mail forwarding robot may also generate
- these control lines, if it not just readdresses the message.
-
- When the "reply" function of the editor is invoked the program
- should use the control lines' contents instead of the header
- information. The control lines should not be included in the reply.
-
- Since it may not be immediately clear whether the user wants to
- reply to the forwarder or to the original sender, the editor should
- offer a means to ignore the proposed control lines and start a
- "normal" reply instead, e.g. by two distinct functions, by user
- preference or a dialog.
-
-
- Pseudo code:
-
- forwarding_message:
- if is_forwarded_message then
- don't change FWD* control lines
- else
- add FWD* control lines
-
- quoting_message:
- if is_forwarded_message then
- if reply_to_forwarder then
- use header data (normal quoting)
- else
- use FWD* control lines
- remove FWD* control lines from reply
- else
- use header data (normal quoting)
-
- other_functions:
- remove/ignore FWD* control lines
-
-
- Example:
-
- Message from Joe User to my boss node:
-
- From: Joe User 1:234/567
- To: Harry Herrmannsdoerfer 2:2490/2520
- Subj: Some questions
- @MSGID: 1:234/567 12345678
- Text: Hello Harry!
- ...
-
- Harry forwards the message to me:
-
- From: Harry Herrmannsdoerfer 2:2490/2520
- To: Michael Hohner 2:2490/2520.17
- Subj: Joe's message
- @FWDFROM Joe User
- @FWDORIG 1:234/567
- @FWDTO Harry Herrmannsdoerfer
- @FWDDEST 2:2490/2520
- @FWDSUBJ Some questions
- @FWDMSGID 1:234/567 12345678
- Text: Hi Michael!
- ...
-
- My answer using the new control lines:
-
- From: Michael Hohner 2:2490/2520.17
- To: Joe User 1:234/567
- Subj: Some questions
- @REPLY: 1:234/567 12345678
- Text: Hi Joe!
-
- JU> ...
- ...
-
-
-3. Compatiblity
----------------
-
- Editor programs which are not prepared for these proposed control
- lines usually just ignore them and remove them from a reply. A reply
- goes to the forwarder. Nothing gained and nothing lost.
-
-
-4. Known implementations
-------------------------
-
- This proposal is implemented in the author's Fidonet editor
- "FleetStreet for OS/2" (versions 1.17 and newer).
-
- Also implemented in Odinn Sorensens Fidonet editor "GoldED"
- (versions 3.00.Alpha5 and newer).
-
-
-A. Contacting the author
-------------------------
-
- The author may be contacted electronically at the following
- addresses:
-
- Fidonet: 2:2490/2520.17
- Internet: miho@osn.de
-
- Suggestions, comments and corrections are always welcome.
-
-
-B. History
-----------
-
- Rev.1, 19960912: First release as FSC-0092.001.
- Rev.2, 19971229: Submitted as FSP.
-
-
-**********************************************************************
-
-
-Go Back
-
-
-
-
diff --git a/html/ftsc/fsp-1009.html b/html/ftsc/fsp-1009.html
deleted file mode 100755
index ba046259..00000000
--- a/html/ftsc/fsp-1009.html
+++ /dev/null
@@ -1,143 +0,0 @@
-
-
-
-Year 2000 issues in FTN software.
-
-
-
-
-
-**********************************************************************
-FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
-**********************************************************************
-
-Publication: FSP-1009
-Revision: 1
-Title: Year 2000 issues in FTN software
-Author: Michael Hohner, 2:2490/2520.17
-Revision Date: 29 December 1997
-Expiry Date: 29 December 1999
-----------------------------------------------------------------------
-Contents:
- 1. Introduction
- 2. Generating Fidonet timestamps
- 3. Interpreting Fidonet timestamps
-----------------------------------------------------------------------
-
-
-Status of this document
------------------------
-
- This document is a Fidonet Standards Proposal (FSP).
-
- This document specifies an optional Fidonet standard protocol for
- the Fidonet community, and requests discussion and suggestions for
- improvements.
-
- This document is released to the public domain, and may be used,
- copied or modified for any purpose whatever.
-
-
-Abstract
---------
-
- The year 2000 causes problems in many computer programs which use
- two-digit year numbers. Current Fidonet software faces the very same
- problems. This FSP specifies procedures which enable FTN software to
- run without problems after the year 2000.
-
-
-1. Introduction
----------------
-
- Software using two-digit year numbers may cause problems in the year
- 2000. When the year number rolls over from "99" to "00", some
- software may interpret the resulting year number as "1900" instead
- of "2000". Such programs may contain code like this:
-
- calendar_year = year_number + 1900; /* wrong! */
-
- Fidonet software faces the very same problem: the year number in
- packed messages (see FTS-0001) has only two digits. Some programs
- interpreting this number incorrectly may decide that messages from
- the year 1900 are too old and discard them. Other programs probably
- just display a wrong calendar year.
-
- The long-term solution would be a transition to four-digit year
- numbers. However, this would require new data formats and cause
- every existing software to fail. So a short-term solution is
- required, resulting in only minimal changes in software. This FSP
- contains guidelines for proper year-number interpretation. The
- author encourages all FTN software authors to check their software
- for possible year-2000 problems (and release fixed versions during
- the next three years).
-
-
-2. Generating Fidonet timestamps
---------------------------------
-
- This should not cause much headache. However, some software may use
- the following algorithm:
-
- year_number = calendar_year - 1900 /* wrong! */
-
- This will result in a three-digit year number in 2000 and lead to
- incorrect Fidonet timestamps.
-
- One correct algorithm is:
-
- year_number = calendar_year mod 100 /* correct! */
-
-
-3. Interpreting Fidonet timestamps
-----------------------------------
-
- We can make use of the fact that Fidonet didn't exist before 1980,
- i.e. no messages were created before 1980. So any year number
- smaller than 80 can't mean "year 19xx", but can only mean "year
- 20xx". One algorithm for correct year number interpretation is:
-
- if year_number < 80 then
- calendar_year = 2000 + year_number
- else
- calendar_year = 1900 + year_number
-
- Fidonet software should only use the calendar year for further
- processing, not the year number from the timestamp.
-
- This solution will work until 2080, giving us another 80+ years to
- finally let some innovation happen in Fidonet.
-
-
-A. Contacting the author
-------------------------
-
- The author may be contacted electronically at the following
- addresses:
-
- Fidonet: 2:2490/2520.17
- Internet: miho@osn.de
-
- Suggestions, comments and corrections are always welcome.
-
-
-B. History
-----------
-
- Rev.1, 19971229: Submitted as FSP.
-
-
-**********************************************************************
-
-
-Go Back
-
-
-
-
diff --git a/html/ftsc/index.htm b/html/ftsc/index.htm
index ae47d037..c6ed51ed 100644
--- a/html/ftsc/index.htm
+++ b/html/ftsc/index.htm
@@ -12,7 +12,7 @@
-Last update 24-May-2003
+Last update 13-Jul-2003
Fidonet Technical Standards
Introduction
@@ -52,14 +52,6 @@ Michiel Broek.
FSP Documents