diff --git a/html/ftsc/fts-5000.html b/html/ftsc/fts-5000.html
new file mode 100644
index 00000000..dae9ae2e
--- /dev/null
+++ b/html/ftsc/fts-5000.html
@@ -0,0 +1,452 @@
+
+
+The Distribution Nodelist.
+
+
+
+
+
+**********************************************************************
+FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
+**********************************************************************
+
+Publication: FTS-5000
+Revision: 1
+Title: THE DISTRIBUTION NODELIST
+Author(s): Colin Turner, Andreas Klein, Michael McCabe,
+ David Hallford, Odinn Sorensen
+
+Revision Date: 27 June 1999
+Expiry Date: 17 June 2001
+----------------------------------------------------------------------
+Contents:
+ 1. Supercessions
+ 2. Purpose
+ 3. Publication and Distribution
+ 4. Contents
+ 5. Nodediff
+----------------------------------------------------------------------
+
+Status of this document
+-----------------------
+
+ This document is a Fidonet Standard (FTS).
+
+ This document specifies a Fidonet standard for the Fidonet
+ community.
+
+ This document is released to the public domain, and may be used,
+ copied or modified for any purpose whatever.
+
+
+Abstract
+--------
+
+ Current practice for Fidonet Technology Networks (FTN) is to
+ maintain a nodelist used to store the details of the nodes in
+ the network, and the network structure.
+
+
+1. Supercessions
+----------------
+
+ FTS-0005 superceded and replaced the documents known under the names
+ of FSC-0002, and FTS-0002.
+
+ This document supercedes and replaces FTS-0005, FSC-0009, FSC-0040,
+ FSC-0075, FSC-0091, and FSP-1012.
+
+2. Purpose
+----------
+
+ Along with the companion technical standard (FTS-5001) this document
+ defines the format and content of the nodelist for the FidoNet
+ International Hobby Network. The FTS-5001 is seperated into two
+ parts - the first part is a listing of authorized flags and the
+ second part is a registry of userflags. The registry is used to
+ prevent a userflag from being used for more than one meaning. The
+ registry is maintained by the Fidonet Technical Standards Committee
+ Working Group D (the Nodelist).
+
+3. Publication and Distribution
+-------------------------------
+
+ The nodelist is published as an ASCII text file named NODELIST.nnn,
+ where nnn is the day-of-year of the publication date.
+ For actual distribution, NODELIST.nnn is packed into an archive
+ file named NODELIST.Pnn, where nn are the last two digits of day-of
+ -year and P is the compression format used as listed below.
+ A = .arc
+ Z = .zip
+ J = .arj
+ R = .rar
+ Since .zip is useable on most computer platforms, it is recommended
+ that this format be used for distribution of the Distribution
+ Nodelist.
+
+
+4. Contents
+-----------
+
+ As stated above, NODELIST.nnn is an ASCII text file. It contains
+ two kinds of lines, comment lines and data lines. Each line is
+ terminated with an ASCII carriage return and line feed character
+ sequence, and contains no trailing white-space (spaces, tabs, etc.).
+ The file is terminated with an end-of-file character, ASCII <EOF>
+ (1AH).
+
+ Comments lines contain a semicolon (;) in the first character
+ position followed by zero or more alphabetic characters called
+ "interest flags". A program which processes the nodelist may use
+ comment interest flags to determine the disposition of a comment
+ line. The remainder of a comment line (with one exception, treated
+ below) is free-form ASCII text.
+
+ There are five interest flags defined as follows:
+
+ ;S This comment is of particular interest to Sysops.
+
+ ;U This comment is of particular interest to BBS users.
+
+ ;F This comment should appear in any formatted "Fido List".
+
+ ;A This comment is of general interest (shorthand for ;SUF).
+
+ ;E This comment is an error message inserted by a nodelist
+ generating program.
+
+ ; This comment may be ignored by a nodelist processor.
+
+ The first line of a nodelist is a special comment line containing
+ identification data for the particular edition of the nodelist. The
+ following is an example of the first line of a nodelist:
+
+ ;A FidoNet Nodelist for Friday, July 3, 1987 --
+ Day number 184 : 15943
+
+ This line contains the general interest flag, the day, date, and
+ day-of-year number of publication, and ends with a 5-digit decimal
+ number with leading zeros, if necessary. This number is the decimal
+ representation of a check value derived as follows:
+
+ Beginning with the first character of the second line, a 16-bit
+ cyclic redundancy check (CRC) is calculated for the entire file,
+ including carriage return and line feed characters, but not
+ including the terminating EOF character. The check polynomial
+ used is the same one used for many file transfer protocols:
+
+ 2**16 + 2**12 + 2**5 + 2**0
+
+ The CRC may be used to verify that the file has not been edited. The
+ importance of this will become evident in the discussion of NODEDIFF
+ below. CRC calculation techniques are well documented in the
+ literature, and will not be treated further here.
+
+ The content of the remaining comments in the nodelist are intended
+ to be informative. Beyond the use of interest flags for distribution
+ , a processing program need not have any interest in them.
+
+ A nodelist data line contains eight variable length "fields"
+ separated by commas (,). No space characters are allowed in a data
+ line, and underscore characters are used in lieu of spaces. The
+ term "alphanumeric character" is defined as the portion of the ASCII
+ character set from 20 hex through 7E hex, inclusive. The following
+ discussion defines the contents of each field in a data line.
+
+
+ Field 1: Keyword
+
+ The keyword field may be empty, or may contain exactly one keyword
+ approved by the Zone Coordinator Council. Current approved keywords
+ are:
+
+ Zone --
+ Begins the definition of a geographic zone and define its
+ coordinator. All the data lines following a line with the
+ "Zone" keyword down to, but not including, the next
+ occurrence of a "Zone" keyword, are regions, nets, and
+ nodes within the defined zone.
+
+ Region --
+ Begins the definition of a geographic region and defines its
+ coordinator. All the data lines following a line with the
+ "Region" keyword down to, but not including, the next
+ occurrence of a "Zone", "Region", or "Host" keyword, are
+ independent nodes within the defined region.
+
+ Host --
+ Begins the definition of a local network and defines its
+ host. All the data lines following a line with the Host
+ keyword down to, but not including, the next occurrence of
+ a "Zone", "Region", or "Host" keyword, are local nodes,
+ members of the defined local network.
+
+ Hub --
+ Begins the definition of a routing subunit within a
+ multilevel local network. The hub is the routing focal
+ point for nodes listed below it until the next occurrence
+ of a "Zone", "Region", "Host", or "Hub" keyword. The hub
+ entry MUST be a redundant entry, with a unique number,
+ for one of the nodes listed below it. This is necessary
+ because some nodelist processors eliminate these entries
+ in all but the local network.
+
+ Pvt --
+ Defines a private node with unlisted number. Private nodes
+ are only allowed as members of local networks.
+
+ Hold --
+ Defines a node which is temporarily down,or is a region/zone
+ independent node which is reachable via IP only. Mail may be
+ sent to it and is held by its host or coordinator.
+
+ Down --
+ Defines a node which is not operational. Mail may NOT be
+ sent to it. This keyword may not be used for longer than
+ two weeks on any single node, at which point the "down"
+ node is to be removed from the nodelist.
+
+
+ <empty> --
+ Defines a normal node entry.
+
+
+
+ Field 2 - Zone/Region/Net/Node number
+
+ This field contains only numeric digits and is a number in the
+ range of 1 to 32767. If the line had the "Zone", "Region", or
+ "Host" keyword, the number is the zone, net, or region number,
+ and the node has an implied node number of 0, therfore the use of
+ a 0 in this field is strictly forbidden. Otherwise, the
+ number is the node number. The zone number, region or net number,
+ and the node number, taken together, constitute a node's FidoNet
+ address.
+
+ Zone numbers must be unique. Region or net numbers must be
+ unique within their zone. Hub numbers must be within their net.
+ Node numbers must be unique within their region (for regional
+ independents) or net (for members of a local network). Duplicate
+ node numbers under different hubs within the same net are not
+ allowed.
+
+ Field 3 - Node name
+
+ This field may contain any alphanumeric characters other than
+ commas and spaces. Underscores are used to represent spaces.
+ This is the name by which the node is known.
+ For IP nodes this field may alternately contain an ip address or
+ E-Mail address for email tunneling programs.
+
+ Field 4 - Location
+
+ This field may contain any alphanumeric characters other than
+ commas and spaces. Underscores are used to represent spaces.
+ This field contains the location of the node. It is usually
+ expressed as the primary local location (town, suburb, city,
+ etc.) plus the identifier of the regional geopolitical admin-
+ istrative district (state, province, department, county,
+ etc.). Wherever possible, standard postal abbreviations for
+ the major regional district should be used (IL, BC, NSW, etc.).
+
+ Field 5 - Sysop name
+
+ This field may contain any alphanumeric characters other than
+ commas and spaces. Underscores are used to represent spaces.
+ This is the name of the system operator.
+
+ Field 6 - Phone number
+
+ This field contains at least three and usually four numeric
+ subfields separated by dashes (-). The fields are country code,
+ city or area code, exchange code, and number. The various parts
+ of the phone number are frequently used to derive cost and
+ routing information, as well as what number is to be dialed.
+ A typical example of the data in a phone number field is 1-800-
+ 555-1212, corresponding to country 1 (USA), area 800 (inbound
+ WATS), exchange 555, and number 1212.
+
+ Alternatively, this field may contain the notation -Unpublished-
+ in the case of a private node. In this case, the keyword "Pvt"
+ must appear on the line.
+
+ This field may also contain the IP address for an IP node
+ utilizing the country code of 000.
+
+ Field 7 - Baud rate
+
+ This field contains the maximum baud rate supported by the node.
+ (eg: 9600, 14400, 38400, etc)
+
+ Field 8 - Flags
+
+ This optional field contains data about the specific operation of
+ the node, such as file requests, modem protocol supported, etc.
+ Any text following the seventh comma on a data line is taken
+ collectively to be the flags field. The required format is zero
+ or more subfields, separated by commas. Each subfield consists
+ of a flag, possibly followed by a value. The authorized flags
+ for use in the distribution nodelist are distributed as in
+ FTS-5001 to facilitate additions and deletions of the authorized
+ flags without requiring an amendment to this FTS.
+
+ FTSC recognizes that the FidoNet Zone Coordinator Council with
+ the International Coordinator as the ZCC Chairman is the
+ ultimate authority over what appears in the FidoNet nodelist.
+ Also, FTSC is by definition a deliberative body, and adding or
+ changing a flag may take a considerable amount of time.
+ Therefore, the FidoNet International Coordinator or Zone
+ Coordinators may temporarily make changes or additions to the
+ flags as defined in FTS-5001. The FidoNet International
+ Coordinator/Zone Coordinators will then consult with FTSC over
+ the changes needed to FTS-5001 to reflect these temporary
+ changes.
+
+
+
+ The following are examples of nodelist data lines:
+
+ Host,102,SOCALNET,Los_Angeles_CA,Richard_Mart,1-213-874-9484,2400,XP
+
+ ,101,Rainbow_Data,Culver_City_CA,Don_Brauns,1-213-204-2996,2400,
+
+ ,102,fido.tree.com,Los_Angeles_CA,Bill_Smart,1-213-555-1212,9600,
+ CM,IP,ITN
+
+
+5. Nodediff
+-----------
+
+ With more than twenty thousand nodes as of this date, the nodelist,
+ even in archive form, is a substantial document (or file). Since
+ distribution is via electronic file transfer, this file is NOT
+ routinely distributed. Instead, when a new nodelist is prepared, it
+ is compared with the previous week's nodelist, and a file containing
+ only the differences is created and distributed.
+
+ The distribution file, called NODEDIFF.nnn, where nnn is the
+ day-of-year of publication, is actually an editing script which will
+ transform the previous week's nodelist into the current nodelist. A
+ definition of its format follows:
+
+ The first line of NODEDIFF.nnn is an exact copy of the first line of
+ LAST WEEK'S nodelist. This is used as a first-level confidence check
+ to insure that the right file is being edited. The second and sub-
+ sequent lines are editing commands and editing data.
+
+ There are three editing commands and all have the same format:
+
+ <command><number>
+
+ <command> is a 1-letter command; A, C, or D. <number> is a
+ decimal number greater than zero, and defines the number of
+ lines to be operated on by the command. Each command appears on
+ a line by itself. The commands have the following meanings:
+
+ Ann - Add the following nn lines to the output file.
+
+ Cnn - Copy nn unchanged lines from the input to the output file.
+
+ Dnn - Delete nn lines from the input file.
+
+ The following illustrate how the first few lines of NODEDIFF.213
+ might look:
+
+ ;A Friday, July 25, 1986 -- Day number 206 : 27712
+ D2
+ A2
+ ;A Friday, August 1, 1986 -- Day number 213 : 05060
+ ;A
+ C5
+
+ This fragment illustrates all three editing commands. The first line
+ is the first line from NODELIST.206. The next line says "delete the
+ first two lines" from NODELIST.206. These are the identification
+ line and the line following it. The next command says "add the next
+ two lines" to NODELIST.213. The two data lines are followed by a
+ command which says "copy five unchanged lines" from NODELIST.206 to
+ NODELIST .213. Notice that the first line added will ALWAYS contain
+ the new nodelist's CRC.
+
+ Since only the differences will be distributed, it is important to
+ insure the accuracy of the newly created nodelist. This is the
+ function of the CRC mentioned above. It is sufficient for a program
+ designed to perform the above edits to pick the CRC value from the
+ first line added to the output file, then compute the CRC of the
+ rest of the output file. If the two CRCs do not agree, one of the
+ input files has been corrupted. If they do agree, the probability
+ is very high (but not 100%) that the output file is accurate.
+
+ For actual distribution, NODEDIFF.nnn is packed into an archive file
+ named NODEDIFF.Pnn, where nn are the last two digits of day-of-year
+ and P is the compression format used as listed below.
+ A = .arc
+ Z = .zip
+ J = .arj
+ R = .rar
+ Since .zip is useable on most computer platforms, it is recommended
+ that this format be used for distribution of the Distribution
+ Nodediff.
+
+A. References
+-------------
+
+ [FTS-5] "The distribution nodelist", Ben Baker, Rick Moore.
+ February 1989. Obsoleted by this document.
+
+ [FSC-9] "Nodelist flag Changes draft document", Ray Gwinn, David
+ Dodell. November 1987. Obsoleted by this document.
+
+ [FSC-40] "Extended Modem Handling", Michael Shiels. February 1990.
+ Obsoleted by this document.
+
+ [FSC-75] "ISDN capability flags in the nodelist", Jan Ceuleers.
+ October 1993. Obsoleted by this document.
+
+ [FSC-91] "ISDN nodelist flags", Arjen Lentz.
+ October 1995. Obsoleted by this document.
+
+ [FSP-1012] "Integration of IP Nodes in the nodelist", Lothar Behet
+ June 1999.
+
+B. Contact Data
+---------------
+
+ David Hallford
+ Fidonet: 1:208/103
+
+ Andreas Klein
+ Fidonet: 2:2480/47
+ E-mail: akx@gmx.net
+
+ Michael McCabe
+ Fidonet: 1:297/11
+
+ Odinn Sorensen
+ Fidonet: N/A
+ E-mail: odinn@goldware.dk
+ WWW: http://www.goldware.dk
+
+ Colin Turner
+ Fidonet: 2:443/13
+ E-mail: ct@piglets.com
+ WWW: http://www.piglets.com
+
+C. History
+----------
+
+ Rev.1, 19990627: Initial Release. Principal Author David Hallford
+
+
+
+
+
Go Back
+
+
+
diff --git a/html/ftsc/fts-5001.html b/html/ftsc/fts-5001.html
new file mode 100644
index 00000000..a1bbfac1
--- /dev/null
+++ b/html/ftsc/fts-5001.html
@@ -0,0 +1,402 @@
+
+
+The Distribution Nodelist.
+
+
+
+
+
+**********************************************************************
+FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
+**********************************************************************
+
+Publication: FTS-5001
+Revision: 1
+Title: NODELIST FLAGS AND USERFLAGS
+Author(s): Colin Turner, Andreas Klein, Michael McCabe,
+ David Hallford, Odinn Sorensen
+
+Revision Date: 27 June 1999
+Expiry Date: 27 June 2001
+----------------------------------------------------------------------
+Contents:
+ 1. Authorized Flags
+ 2. Userflags
+----------------------------------------------------------------------
+
+Status of this document
+-----------------------
+
+ This document is a Fidonet Standard (FTS).
+
+ This document specifies a Fidonet standard for the Fidonet
+ community.
+
+ This document is released to the public domain, and may be used,
+ copied or modified for any purpose whatever.
+
+
+Abstract
+--------
+
+ Current practice for Fidonet Technology Networks (FTN) is to
+ maintain a nodelist used to store the details of the nodes in
+ the network, and the network structure. Flags are used in this
+ nodelist to aid automatic and manual control of various tasks.
+
+
+1. Authorized flags
+-------------------
+
+ Flags authorized for use in the Fidonet nodelist:
+
+ A: OPERATING CONDITION FLAGS:
+
+ Flag Meaning
+
+ CM Node accepts mail 24 hours a day
+ MO Node does not accept human callers
+ LO Node accepts calls Only from Listed
+ FidoNet addresses
+
+ B. MODEM FLAGS:
+ The following flags define modem protocols supported:
+
+ Flag Meaning
+
+ V21 CCITT V.21 300 bps full duplex
+ V22 CCITT V.22 1200 bps full duplex
+ V29 CCITT V.29 9600 bps half duplex
+ V32 CCITT V.32 9600 bps full duplex
+ V32b ITU-T V.32 bis 14400 bps full duplex
+ V32T V.32 Terbo
+ V33 CCITT V.33
+ V34 CCITT V.34
+ HST USR Courier HST
+ H14 USR Courier HST 14.4
+ H16 USR Courier HST 16.8
+ H96 Hayes V9600
+ MAX Microcom AX/96xx series
+ PEP Packet Ensemble Protocol
+ CSP Compucom Speedmodem
+ ZYX Zyxel series
+ VFC V.Fast Class
+ Z19 Zyxel 19,200 modem protocol
+ V90C ITU-T V.90 modem Client
+ V90S ITU-T V.90 Server.
+ X2C US Robotics x2 client.
+ X2S US Robotics x2 server.
+
+
+
+ The following flags define type of error correction available. A
+ separate error correction flag should not be used when the error
+ correction type can be determined by the modem flag. For instance
+ a modem flag of HST implies MNP.
+
+ Flag Meaning
+
+ MNP Microcom Networking Protocol error correction
+ of type MNP1 to MNP4
+ V42 LAP-M error correction w/fallback to MNP
+
+ C: COMPRESSION FLAGS:
+
+ The following flags define the type(s) of compression of mail
+ packets supported.
+
+ Flag Meaning
+
+ MN No compression supported
+
+ The following flags define the type(s) of data compression
+ available.
+
+ V42b ITU-T V42bis
+
+
+ D: FILE/UPDATE REQUEST FLAGS:
+
+ The following flags indicate the types of file/update requests
+ supported.
+
+
+ |--------------------------------------------------|
+ | | Bark | WaZOO |
+ | |---------------------|---------------------|
+ | | File | Update | File | Update |
+ | Flag | Requests | Requests | Requests | Requests |
+ |------|----------|----------|----------|----------|
+ | XA | Yes | Yes | Yes | Yes |
+ | XB | Yes | Yes | Yes | No |
+ | XC | Yes | No | Yes | Yes |
+ | XP | Yes | Yes | No | No |
+ | XR | Yes | No | Yes | No |
+ | XW | No | No | Yes | No |
+ | XX | No | No | Yes | Yes |
+ |--------------------------------------------------|
+
+ E: GATEWAY FLAG:
+
+ The following flag defines gateways to other domains (networks).
+
+ Flag Meaning
+
+ Gx..x Gateway to domain 'x..x', where 'x..x` is a string
+ of alphanumeric characters. Valid values for
+ 'x..x' are assigned by the FidoNet International
+ Coordinator. Current valid values of 'x..x' may
+ be found in the notes at the end of the FidoNet
+ nodelist.
+
+ F: MAIL PERIOD FLAGS:
+ The following flags define the dedicated mail periods supported.
+ They have the form "#nn" or !nn where nn is the UTC hour the mail
+ period begins, # indicates Bell 212A compatibility, and !
+ indicates incompatibility with Bell 212A.
+
+ Flag Meaning
+
+
+ #01 Zone 5 mail hour (01:00 - 02:00 UTC)
+ #02 Zone 2 mail hour (02:30 - 03:30 UTC)
+ #08 Zone 4 mail hour (08:00 - 09:00 UTC)
+ #09 Zone 1 mail hour (09:00 - 10:00 UTC)
+ #18 Zone 3 mail hour (18:00 - 19:00 UTC)
+ #20 Zone 6 mail hour (20:00 - 21:00 UTC)
+
+ NOTE: When applicable, the mail period flags may
+ be strung together with no intervening commas, eg.
+ "#02#09". Only mail hours other than that
+ standard within a node's zone should be given.
+ Since observance of mail hour within one's zone is
+ mandatory, it should not be indicated.
+
+ G: ISDN CAPABILTY FLAGS:
+
+ Nodelist Specification of minimal support required for this flag;
+ flag any additional support to be arranged via agreement
+ between users
+
+ V110L ITU-T V.110 19k2 async ('low').
+ V110H ITU-T V.110 38k4 async ('high').
+ V120L ITU-T V.120 56k async, layer 2 framesize 259, window 7,
+ modulo 8.
+ V120H ITU-T V.120 64k async, layer 2 framesize 259, window 7,
+ modulo 8.
+ X75 ITU-T X.75 SLP (single link procedure) with 64kbit/s B
+ channel; layer 2 max.framesize 2048, window 2, non-ext.
+ mode (modulo 8); layer 3 transparent (no packet layer).
+ ISDN Other configurations. Use only if none of the above
+ fits.
+
+ NOTE: No flag implies another. Each capability MUST be specifically
+ listed.
+ If no modem connects are supported, the nodelist speed field should
+ be 300.
+
+ Conversion from old to new ISDN capability flags:
+ ISDNA -> V110L
+ ISDNB -> V110H
+ ISDNC -> X75
+
+ H: INTERNET CAPABILITY FLAGS:
+
+ FLAG MEANING
+
+ IBN - denotes a system that does BINKP
+ IFC - denotes a system that is capable of RAW or IFCICO
+ ITN - denote a system that does TELNET
+ IVM - denotes a system that is capable of VMODEM
+ IFT - denotes a system that allows FTP
+ ITX - denotes a system that uses TransX encoding for email
+ tunneling
+ IUC - denotes a system that uses UUEncode for email tunneling
+ IMI - denotes a system which uses MIME encoding for email
+ tunneling
+ ISE - denotes a system which supports SEAT receipts for anonymous
+ mail
+ IP - denotes a system that can receive TCP/IP connects using a
+ protocol that is not covered by any other flag.
+ IEM - is a deprecated flag, and new implementations must not
+ write it in nodelist entries. This was used as a single
+ placeholder for the InterNet address of the system if it
+ supported several transport methods. Instead of placing
+ the system address in the deprecated form specified below
+ in each flag, the address would be placed once only in this
+ flag. Implementations may need to parse this information
+ from nodelists created with older programs.
+
+ Conversion from old Internet capabilty flags to the new flags:
+
+ BND -> IBN
+ TEL -> ITN
+ TELNET -> ITN
+ VMD -> IVM
+ TCP -> IP
+
+ The Internet Address should be placed in the BBS name field.
+
+ Previous usage has placed the InterNet address as part of the
+ I-flag (for example ITX:r10_tx@thevision.net); in this format the
+ flag, colon, and address combined cannot exceed 32 characters.
+ However, this practice is deprecated, and new implementations must
+ not place address data in the flag section of the nodelist entry,
+ implementations may however be required to read this data from the
+ flag section.
+
+ Telnet default port is 23. If the port is not 23 then the port
+ number must be placed after the ITN flag (eg ITN:60177) if the
+ Telnet address is part of the ITN flag (eg ITN:farsi.dynip.com) then
+ the port number should be last (eg ITN:farsi.dynip.com:60177) always
+ remember that the flag cannot exceed 32 characters total.
+
+ The default ports for other protocols are shown below, and changes
+ from the default port must be flagged in a similar way.
+
+ Protocol Flag Default Port
+
+ FTP IFT 21
+ BINKP IBN 24554
+ RAW/IFCICO IFC 60179
+ VMODEM IVM 3141
+
+ Actual IP addresses can also be placed in the phone number field
+ using the country code of 000.
+
+ I: SYSTEM ONLINE USERFLAGS
+
+ 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 22:00, w 22:30, X 23:00, x 23:30.
+
+ For example TuB shows an online period from 20:30 until 1:00 UTC.
+
+ Daylight saving time
+
+ If a node changes online times with respect to UTC when daylight
+ saving time becomes effective (which would be the case with most
+ part time nodes), then this is to be taken into account when
+ assigning this flag. An online times flag assigned to a node should
+ not be altered for the specific purpose of adjusting due to
+ daylight saving time, since large difference files (NODEDIFF's)
+ would result if every node was allowed to do this, e.g. my node
+ used to be online from 2300 to 0800 in local time, which in winter
+ is UTC, but in the summer it becomes BST (British Summer Time).
+ This is one hour ahead of UTC, and the corresponding availability
+ times of my node during the summer period were 2200 to 0700 UTC.
+ Therefore my online times flag would have indicated availability
+ between the hours of 2300 and 0700 UTC, the daily time period
+ encompassing both times, so the flag would be TXH.
+
+2. Userflags
+------------
+
+ Registry of Userflags
+
+ A. FORMAT OF USER FLAGS
+
+ U,x..x
+ A user-specified string, which may contain any
+ alphanumeric character except blanks. This string may
+ contain one to thirty-two characters of information
+ that may be used to add user-defined data to a specific
+ nodelist entry. The character "U" must not be
+ repeated, eg, ",U,XXX,YYY,ZZZ" not ",U,XXX,U,YYY,UZZZ".
+ The 32 character limitation is per userflag, not for
+ the total of all userflags.
+
+ New implementations must place a comma after the
+ initial "U" before the user flags. Some
+ implementations will not place a separating comma
+ betweent the "U" and the first user flag, but this
+ practice is deprecated. Implementations should be
+ prepared to read flags in this format, and must strip
+ the "U" from the flag before analysis in this case.
+
+ Entries following the "U" flag must be of a technical
+ or administrative nature. While experimentation of new
+ software functions using this flag is encouraged,
+ advertisement is strictly prohibited.
+
+ For applications other than those shown, or if you
+ have questions concerning the use of this field, please
+ contact your Regional or Zone Coordinator.
+
+
+ B: MAIL ORIENTED USER FLAGS:
+
+ ZEC Zone EchoMail Coordinator. Not more than one entry
+ in the zone segment may carry this flag and that entry
+ must be the current Zone EchoMail Coordinator.
+
+ REC Regional EchoMail Coordinator. Not more than one
+ entry in any region may carry this flag and that entry
+ must be the current Regional EchoMail Coordinator.
+
+ NEC Network EchoMail coordinator. Not more than one entry
+ in any net may carry this flag and that entry must be
+ the current Network EchoMail Coordinator of that Net.
+
+
+ SDS Software Distribution System
+
+ SMH Secure Mail Hub
+
+ NC Network Coordinator. This flag is ONLY to be used by
+ the Network Coordinator of a net which has split the
+ duties of NC and Host and the NC does NOT occupy the
+ Net/0 position in the nodelist.
+
+
+A. Contact Data
+---------------
+
+ David Hallford
+ Fidonet: 1:208/103
+
+ Andreas Klein
+ Fidonet: 2:2480/47
+ E-mail: akx@gmx.net
+
+ Michael McCabe
+ Fidonet: 1:297/11
+
+ Odinn Sorensen
+ Fidonet: N/A
+ E-mail: odinn@goldware.dk
+ WWW: http://www.goldware.dk
+
+ Colin Turner
+ Fidonet: 2:443/13
+ E-mail: ct@piglets.com
+ WWW: http://www.piglets.com
+
+
+B. History
+----------
+
+ Rev.1, 19990627: Initial Release. Principal Author David Hallford
+
+
+
+
+ Go Back
+
+
+