From 1ba8de5d89962c62afe5a5068d0b21c933be3822 Mon Sep 17 00:00:00 2001 From: Michiel Broek Date: Sun, 13 Jul 2003 14:34:20 +0000 Subject: [PATCH] Updated FTSC docs --- html/Makefile | 10 +- html/ftsc/fsp-1003.html | 117 ----------- html/ftsc/fsp-1004.html | 258 ----------------------- html/ftsc/fsp-1005.html | 451 ---------------------------------------- html/ftsc/fsp-1006.html | 160 -------------- html/ftsc/fsp-1007.html | 163 --------------- html/ftsc/fsp-1008.html | 276 ------------------------ html/ftsc/fsp-1009.html | 143 ------------- html/ftsc/index.htm | 10 +- 9 files changed, 6 insertions(+), 1582 deletions(-) delete mode 100755 html/ftsc/fsp-1003.html delete mode 100755 html/ftsc/fsp-1004.html delete mode 100755 html/ftsc/fsp-1005.html delete mode 100755 html/ftsc/fsp-1006.html delete mode 100755 html/ftsc/fsp-1007.html delete mode 100755 html/ftsc/fsp-1008.html delete mode 100755 html/ftsc/fsp-1009.html 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.
-
-
-**********************************************************************
-
- -BackGo 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.
-
-
-**********************************************************************
-
- -BackGo 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...
-
-
-**********************************************************************
-
- -BackGo 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.
-
-
-**********************************************************************
-
- -BackGo 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.
-
-
-**********************************************************************
-
- -BackGo 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.
-
-
-**********************************************************************
-
- -BackGo 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.
-
-
-**********************************************************************
-
- -BackGo 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