F I D O N E W S Volume 17, Number 18 01 May 2000 +----------------------------+---------------------------------------+ | The newsletter of the | ISSN 1198-4589 Published by: | | FidoNet community | "FidoNews" | | _ | 1-717-732-6820 1:270/720 | | / \ | | | /|oo \ | | | (_| /_) | | | _`@/_ \ _ | | | | | \ \\ | Editor: Douglas Myers, 1:270/720 | | | (*) | \ )) | DougM@paonline.com | | |__U__| / \// | | | _//|| _\ / | | | (_/(_|(____/ | | | (jm) | Newspapers should have no friends. | | | -- JOSEPH PULITZER | +----------------------------+---------------------------------------+ Table of Contents 1. HEADLINES ................................................ 1 2. EDITORIAL ................................................ 2 Where Are We Going? ...................................... 2 3. ARTICLES ................................................. 3 FTS-5000 Draft ........................................... 3 FTS-5001 Draft ........................................... 12 4. COLUMNS .................................................. 25 Ol'WDB: A Friend Told Me ................................. 25 This Weeks Web Page ...................................... 27 5. NET HUMOR ................................................ 29 Signs You're Getting Old ................................. 29 6. COMIX IN ASCII ........................................... 31 Remember These Famous Cows? .............................. 31 7. NOTICES .................................................. 32 Fidonews Editor Still Hangs in There :) .................. 32 8. INTERNET INFO ............................................ 33 Fidonet-related sites .................................... 33 9. FIDONEWS INFO ............................................ 37 Masthead ................................................. 37 FIDONEWS 17-18 Page 1 1 May 2000 ================================================================= HEADLINES ================================================================= This week's edition is larger than normal, mostly because of my decision to publish the FTSC material in it's entirety rather than stretching it across issues. My apologies for the bulk, but I feel it's important to keep abreast of the way FTSC defines Fidonet. Of course, our old regulars are in here too :) ----------------------------------------------------------------- FIDONEWS 17-18 Page 2 1 May 2000 ================================================================= EDITORIAL ================================================================= Where Are We Going? Doug Myers Perhaps this week's editorial is in the same vein as last week's, but with a touch of yellow journalism. I'm about to utter blasphemies which, perhaps, will bring the Fidonet Elders from their chambers tearing their robes from their chest. The BBS as we know it is a dying animal - it's not coming back in the old form we grew to know and love. Why not? Simply because we'll attract no users again - they'll log onto their ISP and play on the Internet even if they know about BBSes. Why not? The graphics are better than we ever dreamed about at the height of BBSing, the variety of activity is greater than we individual sysops could ever supply, and some areas such as e-business - which can transform lifestyle - were never even possible with BBSes. This means that Fidonet can't survive as it is presently structured - a network of sysops. If we sysops can't attract users, then we'll have nothing to do and will eventually drift off... and our network will eventually whither. Oh, I'm not totally negative here - just trying to address realities. What it all means is that we've got to redefine ourselves to continue on. What we had was great - the sense of community in particular was never, in my humble opinion, never exceeded even by today's Internet. We've got to find a new role for ourselves where we can function in the new paradigms. I don't have answers here, I can merely point out some directions. I'm hoping some of the readers can take these directions and make something of them (or possibly point out my errors). First of all, we've got to operate on the Internet in a new way. Our current efforts are good, in that they enable us to move mail and files which would probably be impossible if we tried to operate strictly through the conventional telephone system. What we don't do much of right now is to attract new users in the way they are able to operate - with a plain old preconfigured WEB browser. Somehow we've got to create WEB sites with the taste and feel of the old BBSes, drawing at least a small group of users back time after time just for the sense of community. Can we do it? I don't know. How about you folks telling me? ----------------------------------------------------------------- FIDONEWS 17-18 Page 3 1 May 2000 ================================================================= ARTICLES ================================================================= FTS-5000 Draft This is the latest draft available to FIDONEWS of the Fidonet Technical Standards Committee document defining The Distribution Nodelist. This copy was derived from a message by Colin Turner in the echo SYSOP.FTSC inviting public comment by May 15, 2000; and subsequently reported to FIDONEWS by Lesley-Dee Dylan (1:250/515). Though the period for public comment is over, and though this document is not in force yet, it and it's accompanying FTS-5001 are presented in their draft form as information of concern to all Fidonet Sysops. Minor formatting changes were required to make this document fit the FIDONEWS format, but due care was exercised to make no editorial changes to the content. * note - proposed changes are marked by asterisks [ comments of Fino Lucrezi are included in square brackets ] ********************************************************************* FTSC FIDONET TECHNICAL STANDARDS COMMITTEE ********************************************************************* Publication: FTS-5000 - REVIEW COPY - *NOT IN FORCE* Draft: *Proposed* Revision 2 Title: THE DISTRIBUTION NODELIST Author(s): Colin Turner, Andreas Klein, Michael McCabe, David Hallford, Odinn Sorensen, Gino Lucrezi Draft Date: 22 April 2000 --------------------------------------------------------------------- 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 * or copied for any purpose whatever. * Any modification should be clearly identified as such and called * with a different name FIDONEWS 17-18 Page 4 1 May 2000 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 separated 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). * Unlike most FTSC documents, this one is not only aimed at * developers, but also at maintainers of Fidonet (and other Fidonet * Technology Networks) nodelist segments. While nodelist segment * maintainers should try to be quite strict in their adherence to * this document, it is recommended that software developers be * prepared to accept deviations from this standard, especially with * regard to field and line size. 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 * L = .lzh Since .zip is usable on most computer platforms, it is recommended that this format be used for distribution of the Distribution FIDONEWS 17-18 Page 5 1 May 2000 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 white-space (spaces, tabs, etc.) at all. The file is terminated with an end-of-file character, ASCII (1AH). * Except for the above, no control characters (ASCII 0-31) should be * used in the nodelist. * Each line shouldn't exceed 157 characters. However, it is * recommended that software developers be quite liberal, and accept * unlimited-lenght strings. 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 * Please note that the above line has been split in the sole interest * of readability. It should appear on just one line. * This line contains the general interest flag, the week day, full * date, the 3-digit day-of-year number (also called "Julian date") * of publication, and ends with a 5-digit decimal check value. The * Julian date and check value are padded with leading zeros, if * necessary. FIDONEWS 17-18 Page 6 1 May 2000 * The check value is 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 first line will certainly be different from the above in the * case of nodelist segments for individual zones, regions, networks * or hubs; it will also be different for other Fidonet Technology * Networks. * Except for the day number and the CRC, developers shouldn't make * any assumption on the format of this line. The suggested parsing * algorithm is to find the last colon in the line, and then scan * backwards to get the day of issue. 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 FIDONEWS 17-18 Page 7 1 May 2000 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. They are also * considered part of a network whose number is the same as * the region number. 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. Pvt -- Defines a private node with unlisted number. Private nodes are only allowed as members of local networks. Hold -- Defines a node which is operational but can't be reached with a dial-up connection. Mail can be sent to it in care of its host or coordinator, who will hold it for that node. Down -- Defines a node which is not operational. Mail may NOT be sent to it. [ I removed the two-week limit on being down before removal; I believe it to be a policy issue, not an FTSC one] -- Defines a normal node entry. * Administrative entries (those with a Zone, Region, Host or Hub * keyword) MUST be redundant entries for one of the nodes listed * below them. * No other content is possible for this field in the master * Fidonet nodelist; however, private listings can conceivably * include other kind of entries, by marking them appropriately in * this field. It is recommended that software parsing nodelists * ignore any line which has an unknown keyword in this field. * One such example is the "Point" keyword. It can be used in * so-called "pointlists" to include entries describing points of * the Fidonet node immediately preceding. This keyword should * never be used in the Fidonet nodelist, but it is recommended * that nodelist parsers recognize it. Field 2 - Zone/Region/Net/Node number FIDONEWS 17-18 Page 8 1 May 2000 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 unique within * their net. The hub number will be treated like an extra node in * its local network. 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. * If the entry is marked by a "Point" keyword in the first field, * this field contains the point number. The address of the "boss" * node is that of the last regular node entry preceding the point. Field 3 - Node name This field may contain any alphanumeric character other than * commas and spaces. This is the name by which the node is known. * For IP nodes this field may alternately contain a numeric IP * address or E-Mail address for email tunneling programs. Field 4 - Location This field may contain any alphanumeric character 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 two or more numeric subfields separated by * dashes (-). The first field is the country code. The rest of the * phone number should be formatted according to local customs. 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), FIDONEWS 17-18 Page 9 1 May 2000 * area 800 (area code), exchange 555, and number 1212. * Alternatively, in the case of a private node, this field may * contain the notation -Unpublished-. In this case, the keyword "Pvt" must appear on the line. * If a nodelist uses "Point" keywords, such entries can also have * "-Unpublished-" in this field (and will do so almost always). * This field may also contain the IP address of an IP node * utilizing the country code of 000. This should only be done in * exceptional circumstances, since it is almost always better to * list a fully qualified domain name instead of a numeric IP * address, which could become obsolete in a matter of hours. Field 7: Obsolete * In the past, this field was used to show the maximum modem speed * supported by the node. * However, given the number of competing (and incompatible) * protocols available having the same speed, this function was * later taken over by modem flags. Today, this field carries no * relevant information, and is ignored by most software, with * only one exception. If the node has no analog modem available * on this line (it is either ISDN-only or IP-only) then it must * use a value of 300 in this field. If there is an analog modem * on this line, the value of 9600 is strongly recommended for * maximum compatibility. * Values other than 300, 1200, 2400 and 9600 (historically * accepted by any program) have to be approved by the ZCC before * being used. * However, it is recommended that developers accept any 16 bit * unsigned integer value. 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. * Each subfield should be long at most 32 characters. It is * however recommended that software developers recognize and * process even fields which are longer than this limit. 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. FIDONEWS 17-18 Page 10 1 May 2000 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 ----------- * 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: is a 1-letter command; A, C, or D. 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. FIDONEWS 17-18 Page 11 1 May 2000 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 * L = .lzh 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. FIDONEWS 17-18 Page 12 1 May 2000 [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 Rev.2 20000424: Re-draft by Gino Lucrezi, with input from others, especially Andreas Klein. Major changes: - notes on parsing line 1 - baud rate - different use of fields for IP nodes - notes to developers and maintainers - notes on pointlists - notes on line and field limits - revised definition of "Hold" nodes. - clarification on hub node numbers - clarification on point phone numbers - clarification on the former "speed" field ----------------------------------------------------------------- FTS-5001 Draft This artical accompanies the previous one on FTS-5000. The same FIDONEWS 17-18 Page 13 1 May 2000 preliminary notes apply. ********************************************************************* FTSC FIDONET TECHNICAL STANDARDS COMMITTEE ********************************************************************* Publication: FTS-5001 - REVIEW COPY - *NOT IN FORCE* Draft: *Proposed* Revision 2 Title: NODELIST FLAGS AND USERFLAGS Author(s): Colin Turner, Michael McCabe, David Hallford, Odinn Sorensen, Gino Lucrezi Draft Date: 22 April 2000 --------------------------------------------------------------------- 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 * or copied for any purpose whatever. * Any modification should be clearly identified as such and named * differently. 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 * MN No packet compression supported FIDONEWS 17-18 Page 14 1 May 2000 * B. MODEM CONNECTION PROTOCOL FLAGS: The following flags define modem connection protocols supported. * Please also read section I on flag redundancies. [ I standardized entries format, and added speeds wherever I could ] * ITU-T (formerly CCITT) Protocols: Flag Meaning * V21 ITU-T V.21 300 bps full duplex * V22 ITU-T V.22 1.200 bps full duplex * V29 ITU-T V.29 9.600 bps half duplex * V32 ITU-T V.32 9.600 bps full duplex * V32b ITU-T V.32bis 14.400 bps full duplex * V33 ITU-T V.33 * V34 ITU-T V.34 28.800 bps full duplex * (this flag also covers so-called V.34+, * capable of 33.600 bps) * V90C ITU-T V.90 Client 56.000 bps asymmetric * V90S ITU-T V.90 Server 56.000 bps asymmetric * Industry standard protocols: * Flag Meaning * V32T V.32 Terbo 28.800 bps * VFC V.Fast Class 28.800 bps * Proprietary Protocols: * Flag Meaning * HST USR Courier HST 9.600 bps asymmetric * H14 USR Courier HST 14.400 bps asymmetric * H16 USR Courier HST 16.800 bps asymmetric * X2C US Robotics x2 client 56.000 bps asymmetric * X2S US Robotics x2 server 56.000 bps asymmetric * ZYX Zyxel 16.800 bps * Z19 Zyxel 19,200 bps * H96 Hayes V9600 9.600 bps MAX Microcom AX/96xx series PEP Packet Ensemble Protocol * CSP Compucom Speedmodem * C: SESSION LEVEL ERROR-CORRECTION AND COMPRESSION FLAGS: * The following flags define type of error correction and/or data * compression available. A separate error correction flag should * not be used when the error correction type can be determined by * the modem flag. See section I for details. Flag Meaning FIDONEWS 17-18 Page 15 1 May 2000 MNP Microcom Networking Protocol error correction of type MNP1 to MNP4 * V42 ITU-T V.42: LAP-M error correction with fallback * to MNP 1-4 * V42b ITU-T V.42bis: LAP-M error correction and * compression with fallback to MNP 1-5 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 | * | none | No | No | No | No | +--------------------------------------------------+ * The following software is qualified to * use the appropriate file request flag * according to information provided by * developers: * * +-----------------------------------+ * | Flag Software Package | * |-----------------------------------| * | XA Frontdoor 1.99b and lower | * | Frontdoor 2.01 and higher | * | Dutchie 2.90c | * | Binkleyterm 2.1 and higher | * | D'Bridge 1.2 and lower | * | Melmail | * | TIMS | * |-----------------------------------| * | XB Binkleyterm 2.0 | * | Dutchie 2.90b | * |-----------------------------------| * | XC Opus 1.1 | * |-----------------------------------| * | XP Seadog | * |-----------------------------------| * | XR Opus 1.03 | * | Platinum Xpress | * |-----------------------------------| FIDONEWS 17-18 Page 16 1 May 2000 * | XW Fido 12N and higher | * | Tabby | * | TrapDoor No update processor| * |-----------------------------------| * | XX Argus 2.00 and higher | * | D'Bridge 1.30 and higher | * | Frontdoor 1.99c/2.00 | * | InterMail 2.01 | * | McMail 1.00 | * | T-Mail | * | TrapDoor - Update Processor | * |-----------------------------------| * | None QMM | * +-----------------------------------+ 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 or the Zone Coordinators Council. They * will also adequately distribute a list of valid * values. 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) * #17 Zone 3 mail hour (17:00 - 18:00 UTC) #20 Zone 6 mail hour (20:00 - 21:00 UTC) The above listing of the ZMH for each individual zone is only given for your convenience. It was correct at the time of this writing, but could be changed at any time by following the procedures established in Fidonet policy. The FTSC has no role in determining the Mail Hour of any Zone. You'll find an up-to-date list in the comments at the end of the Fidonet Nodelist. 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 FIDONEWS 17-18 Page 17 1 May 2000 given. Since observance of mail hour within one's zone is mandatory, it should not be indicated. * If one node wishes to advertise a much larger mail period, use * of the T?? flag is recommended, as described in part 2, section * C. 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 analog 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: [this is an almost complete rewrite: all lines are to be considered prefixed by *] Several different protocols are available to exchange Fidonet Mail over the Internet, and they are denoted by the following flags: Direct Connectivity Flag Protocol IBN BINKP (FSP-1011) IFC RAW protocol as used by ifcico or compatible programs ITN FTS-0001 over TELNET connection IVM FTS-0001 over VMODEM connection IP can receive TCP/IP connects using some protocol not covered by above flags; see later for another use of this FIDONEWS 17-18 Page 18 1 May 2000 flag Indirect Connectivity Flag Protocol IFT Packet exchange via FTP ITX TransX encoding for email tunneling with receipts enabled IUC uuencoding of mail bundles IMI MIME encoding of mail bundles ISE SEAT protocol for Email tunneling with receipts enabled; should always be accompanied by IUC and/or IMI IEM other mail tunneling methods not covered by above flags; see later for another use of this flag Direct connectivity means that both parties to the mail exchange must be connected to the internet at the same time, and communicate in real time. Such a connection is analogous to a crash-mail connection between two fidonet nodes. Indirect connectivity protocols require the use of one or more systems storing information to pass it to a fidonet system. This kind of connection is analogous to routed mail. To use any direct connectivity flag, a node must at least be able to process inbound calls with that protocol during ZMH. Nodes also listing flags denoting additional online times (CM, Tyz, !nn and #nn) must also support that protocol during these additional times. To use any indirect connectivity flag, a node must connect to its Internet provider at least once a day. [Tobias would like to add a requirement for CM nodes to poll their ISP every hour] To use the flag for any Email method providing for return receipts (currently ITX and ISE) a node *must* have them enabled and send such receipts within 24 hours of receiving a file. It should be noted that only some of these Internet based methods (currently IBN, IFC, ITN, IVM, ITX and ISE) can give the sender a proof of receipt of a file by the addressee, like FTS-0001 does. Other methods have no guarantee of reliability, so they shouldn't be used to transmit critical data. Also, nodelist segment maintainers should take into account the presence of at least one of these reliable protocols when deciding on application for Fidonet membership by nodes without a dial-up connection. While to set up a FTS-0001 connection you only need to know the phone number to call, for an internet connection you'll need some more information. When using a direct connectivity protocol (flags IBN, IFC, ITN, FIDONEWS 17-18 Page 19 1 May 2000 IVM) or FTP (flag IFT) a node needs to identify the Internet host to connect to. This requires a FQDN (Fully Qualified Domain Name) and a port number. This can be specified using the following format: [:][:] If the port number is not specified, the following defaults are assumed: Protocol Flag Default Port BINKP IBN 24554 RAW/IFCICO IFC 60179 TELNET ITN 23 VMODEM IVM 3141 FTP IFT 21 If a node supports more than one protocol on the same internet host (thus using the same FQDN), the FQDN should only be listed once. In this case, the IP flag should be added to the nodelist entry (even if it wouldn't be needed otherwise), with the following syntax: IP: Please note the 32 characters limit on any flag. As an alternative, the FQDN can be placed in the "Node Name" field of the nodelist entry. In general it is better to list a FQDN in the nodelist, and leave to a DNS (Domain Name Server) the task of "resolving" it, i.e. translating it to a numeric IP address. However, in some particular situations it could be preferable to list directly the IP address. This should only be done with full knowledge of the possible problems involved. In such cases, the IP address shouldn't be placed in the flags field, but in the "Node Name" field. Another possibility (though deprecated in some countries) is to put it in the "Phone Number" field, prefixed by a country code of 000 (reserved by ITU-T, and unlikely to be assigned to any country in the near future), with dashes ("-") replacing dots ("."). An IP address should never be placed in the flags section, where it could be misinterpred as a port number. Email-based transport methods (ITX, IUC, IMI, ISE, IEM) need knowledge of an Email address, in the form @. So, each of these flags has the syntax: [:@] If the same Email addess is used for more than one protocol, then it should only be listed once. In this case, the IEM flag should be used (even if it wouldn't be needed otherwise), and the Email addess should only be stated after this flag. Some programs can parse Email addresses in the "Node Name" field. This, however, conflicts with the use of it for holding FIDONEWS 17-18 Page 20 1 May 2000 an IP address. The following flags were used in the past. Please note their "modern" equivalent, and use it in their place: Old New BND -> IBN TEL -> ITN TELNET -> ITN VMD -> IVM TCP -> IP * I: FLAG REDUNDANCIES [All the section is new, and should be considered prefixed by * ] Only the smallest possible set of flags should be used in each entry. Since different people might have different perception of modem flag redundancies, the FTSC decided to provide a standard table. The relation "implies" means either that the first protocol requires all the others as a fallback or that to all practical purposes all modems which have been manufactured until today (and conceivably even future ones) implemented the other protocols anyway. For example, the protocol V.32bis implies V.32 because it's required as a fallback; on the other hand, V.32Terbo implies V.32bis because practically all modems with V.32Terbo also had V.32bis to connect to existing modems, even though it wasn't required in the protocol specifications. V32 implies V22 V32B implies V22 V32 V34 implies V22 V32 V32B V90C implies V22 V32 V32B V34 V90S implies V22 V32 V32B V34 V42 implies MNP V42B implies V42 MNP V32T implies V22 V32 V32B VFC implies V22 V32 V32B HST implies MNP H14 implies HST MNP H16 implies HST H14 MNP V42 V42B X2C implies V22 V32 V32B V34 X2S implies V22 V32 V32B V34 ZYX implies V22 V32 V32B V42 V42B MNP FIDONEWS 17-18 Page 21 1 May 2000 Z19 implies V22 V32 V32B V42 V42B MNP ZYX Please note also that: . V21 may or may not be supported by modems using higher ITU-T protocols, so it is never implied; however, this flag is not really useful, either, so it should only be used if there is a strong reason to expressely denote such a compatibility; . the V90C and V90S flags are mutually exclusive; . the X2C and X2CS flasg are are mutually exclusive; . no modem has at the same time the US Robotics proprietary protocols and the ZyXEL ones; so, use of any flag in the group HST, H14, H16, X2S and X2C is incompatible with any of the ZYX and Z19 flags, and vice versa. . all X? flags are mutually exclusive; . the #??, !??, T?? and CM flags are incompatible with each other. 2. Userflags ------------ Registry of Userflags It is impossible to document all user flags in use. The FTSC makes no attempt at it. This document lists those flags which got at least some kind of official sanction or were deemed of technical interest by FTSC. 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. FIDONEWS 17-18 Page 22 1 May 2000 * Developers should note that the distinction between * "normal" flags and user flags is a non-technical, * purely political one. It often happened that a user * flag was "promoted" to regular status, and the * reverse could conceivably happen. It is recommended * that, while parsing nodelist entries, no distinction * at all be done between the two categories of flags. 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. 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. SDS Software Distribution System * SMH Secure Mail Hub - or one of the following variations, * indication the specific level of the hub: * NSMH - Net SecureMail Host - only one per net * RSMH - Region SecureMail Host - only one per region * ZSMH - Zone SecureMail Host - only one in Zone 1 * ISMH - International SecureMail Host - only one in Fidonet * RPK Regional Pointlist Keeper. * This user-flag identifies the person who compiles the * region-pointlist (only 1 entry per region allowed) * NPK Net Pointlist Keeper. * This user-flag identifies the person who compiles the * net-pointlist (only 1 entry per net allowed) * K12 This flag identifies systems offering the full range of * educational K12-conferences. * ENC This node accepts inbound encrypted mail and will route * it like other mail FIDONEWS 17-18 Page 23 1 May 2000 * CDP This node will accept points auto-created by the * CD-point software. * C: SYSTEM ONLINE USERFLAGS [This section was relocated between user flags] 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. A. Contact Data --------------- David Hallford Fidonet: 1:208/103 Michael McCabe Fidonet: 1:297/11 Odinn Sorensen Fidonet: N/A E-mail: odinn@goldware.dk WWW: http://www.goldware.dk FIDONEWS 17-18 Page 24 1 May 2000 Colin Turner Fidonet: 2:443/13 E-mail: ct@piglets.com WWW: http://www.piglets.com Gino Lucrezi Fidonet: 2:335/610 E-Mail: gino.lucrezi@ftsc.org B. History ---------- Rev.1, 19990627: Initial Release. Principal Author David Hallford Rev.2, 20000422: new draft by Gino Lucrezi; major changes: - reorganization of flags classification - rewrite for clarification of internet connection flags - note on difference between "regular" and "user" flags - description of flag redundancies new draft by Gino Lucrezi with input from others - removed Andreas Klein from authors - ENC flag - distinction of direct and indirect IP connectivity - requirement for return recepits with ITX and ISE - additional requirement for IP-nodes with CM flag - clarification on some flag redundancies new draft by Gino Lucrezi with input from others - corrected Z3MH and added note on changing of ZMHs ----------------------------------------------------------------- FIDONEWS 17-18 Page 25 1 May 2000 ================================================================= COLUMNS ================================================================= Ol'WDB's Column A Friend Told Me... wdbonner@pacbell.net When I was quite young, my father had one of the first telephones in our neighborhood. I remember well, the polished, old case fastened to the wall and shiny receiver on the side of the box. I was too little to reach the telephone, but used to listen with fascination when my mother used to talk to it. Then I discovered that somewhere inside the wonderful device lived an amazing person - her name was "Information Please" and there was nothing she did not know. "Information Please" could supply anybody's number and the correct time. My first personal experience with this genie-in-the-bottle came one day while my mother was visiting a neighbor. Amusing myself at the tool bench in the basement. I whacked my finger with a hammer. The pain was terrible, but there didn't seem to be any reason in crying because there was no one home to give sympathy. I walked around the house sucking my throbbing finger, finally arriving at the stairway. The telephone! Quickly, I ran for the footstool in the parlor and dragged it to the landing. Climbing up, I unhooked the receiver in the parlor and held it to my ear. "Information Please," I said into the mouthpiece just above my head. A click or two and a small clear voice spoke into my ear. "Information" "I hurt my finger." I wailed into the phone. The tears came readily enough now that I had an audience. "Isn't your mother home?" came the question. Nobody's home but me," I blubbered. "Are you bleeding?" the voice asked. "No," I replied. "I hit my finger with the hammer and it HURTS! "Can you open your icebox?" she asked. I said I could. "Then take an ice cube and hold it to your finger," said the voice. After that, I called "Information Please" for everything. I asked her for help with my geography and she told me where Philadelphia was. She helped me with my math. She told me my pet chipmunk, that I had caught in the park just the day before, would eat fruit and nuts. Then, there was the time Petey, our pet canary died. I called FIDONEWS 17-18 Page 26 1 May 2000 "Information Please" and told her the sad story. She listened, then said the usual things grown ups say to soothe a child. But I was un-consoled. I asked her, "Why is it that birds should sing so beautifully and bring joy to all families, only to end up as a heap of feathers on the bottom of a cage?" She must have sensed my deep concern, for she said quietly, "Paul, always remember that there are other worlds to sing in." Somehow I felt better. Another day I was on the telephone. "Information Please." "Information," said the now familiar voice. "How do you spell fix?" I asked. All this took place in a small town in the Pacific northwest. When I was nine years old, we moved across the country to Boston. I missed my friend very much. "Information Please" belonged in that old wooden box back home and I somehow never thought of trying the tall, shiny new phone that sat on the table in the hall. As I grew into my teens, the memories of those childhood conversations never really left me. Often, in moments of doubt and perplexity I would recall the serene sense of security I had then. I appreciated now how patient, understanding and kind she was to have spent her time on a little