<HTML> <!-- $Id$ --> <HEAD> <TITLE>The Distribution Nodelist.</TITLE> </HEAD> <!-- Background white, links blue (unvisited), navy (visited), red (active) --> <BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#000080" ALINK="#FF0000" > <TT> **********************************************************************<BR> FTSC FIDONET TECHNICAL STANDARDS COMMITTEE<BR> **********************************************************************<BR> <BR> Publication: FTS-5001<BR> Revision: 1<BR> Title: NODELIST FLAGS AND USERFLAGS<BR> Author(s): Colin Turner, Andreas Klein, Michael McCabe,<BR> David Hallford, Odinn Sorensen<BR> <BR> Revision Date: 27 June 1999<BR> Expiry Date: 27 June 2001 <BR> ----------------------------------------------------------------------<BR> Contents:<BR> 1. Authorized Flags<BR> 2. Userflags<BR> ----------------------------------------------------------------------<BR> <BR> Status of this document<BR> -----------------------<BR> <BR> This document is a Fidonet Standard (FTS).<BR> <BR> This document specifies a Fidonet standard for the Fidonet<BR> community.<BR> <BR> This document is released to the public domain, and may be used,<BR> copied or modified for any purpose whatever.<BR> <BR> <BR> Abstract<BR> --------<BR> <BR> Current practice for Fidonet Technology Networks (FTN) is to<BR> maintain a nodelist used to store the details of the nodes in<BR> the network, and the network structure. Flags are used in this<BR> nodelist to aid automatic and manual control of various tasks.<BR> <BR> <BR> 1. Authorized flags<BR> -------------------<BR> <BR> Flags authorized for use in the Fidonet nodelist:<BR> <BR> A: OPERATING CONDITION FLAGS:<BR> <BR> Flag Meaning<BR> <BR> CM Node accepts mail 24 hours a day<BR> MO Node does not accept human callers<BR> LO Node accepts calls Only from Listed<BR> FidoNet addresses<BR> <BR> B. MODEM FLAGS:<BR> The following flags define modem protocols supported:<BR> <BR> Flag Meaning<BR> <BR> V21 CCITT V.21 300 bps full duplex<BR> V22 CCITT V.22 1200 bps full duplex<BR> V29 CCITT V.29 9600 bps half duplex<BR> V32 CCITT V.32 9600 bps full duplex<BR> V32b ITU-T V.32 bis 14400 bps full duplex<BR> V32T V.32 Terbo<BR> V33 CCITT V.33<BR> V34 CCITT V.34<BR> HST USR Courier HST<BR> H14 USR Courier HST 14.4<BR> H16 USR Courier HST 16.8<BR> H96 Hayes V9600<BR> MAX Microcom AX/96xx series<BR> PEP Packet Ensemble Protocol<BR> CSP Compucom Speedmodem<BR> ZYX Zyxel series<BR> VFC V.Fast Class<BR> Z19 Zyxel 19,200 modem protocol<BR> V90C ITU-T V.90 modem Client <BR> V90S ITU-T V.90 Server. <BR> X2C US Robotics x2 client. <BR> X2S US Robotics x2 server. <BR> <BR> <BR> <BR> The following flags define type of error correction available. A<BR> separate error correction flag should not be used when the error<BR> correction type can be determined by the modem flag. For instance<BR> a modem flag of HST implies MNP.<BR> <BR> Flag Meaning<BR> <BR> MNP Microcom Networking Protocol error correction<BR> of type MNP1 to MNP4<BR> V42 LAP-M error correction w/fallback to MNP<BR> <BR> C: COMPRESSION FLAGS:<BR> <BR> The following flags define the type(s) of compression of mail<BR> packets supported.<BR> <BR> Flag Meaning<BR> <BR> MN No compression supported<BR> <BR> The following flags define the type(s) of data compression<BR> available.<BR> <BR> V42b ITU-T V42bis<BR> <BR> <BR> D: FILE/UPDATE REQUEST FLAGS:<BR> <BR> The following flags indicate the types of file/update requests<BR> supported.<BR> <BR> <BR> |--------------------------------------------------|<BR> | | Bark | WaZOO |<BR> | |---------------------|---------------------|<BR> | | File | Update | File | Update |<BR> | Flag | Requests | Requests | Requests | Requests |<BR> |------|----------|----------|----------|----------|<BR> | XA | Yes | Yes | Yes | Yes |<BR> | XB | Yes | Yes | Yes | No |<BR> | XC | Yes | No | Yes | Yes |<BR> | XP | Yes | Yes | No | No |<BR> | XR | Yes | No | Yes | No |<BR> | XW | No | No | Yes | No |<BR> | XX | No | No | Yes | Yes |<BR> |--------------------------------------------------|<BR> <BR> E: GATEWAY FLAG:<BR> <BR> The following flag defines gateways to other domains (networks).<BR> <BR> Flag Meaning<BR> <BR> Gx..x Gateway to domain 'x..x', where 'x..x` is a string<BR> of alphanumeric characters. Valid values for<BR> 'x..x' are assigned by the FidoNet International<BR> Coordinator. Current valid values of 'x..x' may<BR> be found in the notes at the end of the FidoNet<BR> nodelist.<BR> <BR> F: MAIL PERIOD FLAGS:<BR> The following flags define the dedicated mail periods supported.<BR> They have the form "#nn" or !nn where nn is the UTC hour the mail<BR> period begins, # indicates Bell 212A compatibility, and !<BR> indicates incompatibility with Bell 212A.<BR> <BR> Flag Meaning<BR> <BR> <BR> #01 Zone 5 mail hour (01:00 - 02:00 UTC)<BR> #02 Zone 2 mail hour (02:30 - 03:30 UTC)<BR> #08 Zone 4 mail hour (08:00 - 09:00 UTC)<BR> #09 Zone 1 mail hour (09:00 - 10:00 UTC)<BR> #18 Zone 3 mail hour (18:00 - 19:00 UTC)<BR> #20 Zone 6 mail hour (20:00 - 21:00 UTC)<BR> <BR> NOTE: When applicable, the mail period flags may<BR> be strung together with no intervening commas, eg. <BR> "#02#09". Only mail hours other than that<BR> standard within a node's zone should be given.<BR> Since observance of mail hour within one's zone is<BR> mandatory, it should not be indicated.<BR> <BR> G: ISDN CAPABILTY FLAGS:<BR> <BR> Nodelist Specification of minimal support required for this flag;<BR> flag any additional support to be arranged via agreement <BR> between users<BR> <BR> V110L ITU-T V.110 19k2 async ('low').<BR> V110H ITU-T V.110 38k4 async ('high').<BR> V120L ITU-T V.120 56k async, layer 2 framesize 259, window 7,<BR> modulo 8.<BR> V120H ITU-T V.120 64k async, layer 2 framesize 259, window 7,<BR> modulo 8.<BR> X75 ITU-T X.75 SLP (single link procedure) with 64kbit/s B<BR> channel; layer 2 max.framesize 2048, window 2, non-ext.<BR> mode (modulo 8); layer 3 transparent (no packet layer).<BR> ISDN Other configurations. Use only if none of the above<BR> fits.<BR> <BR> NOTE: No flag implies another. Each capability MUST be specifically<BR> listed.<BR> If no modem connects are supported, the nodelist speed field should<BR> be 300.<BR> <BR> Conversion from old to new ISDN capability flags:<BR> ISDNA -> V110L<BR> ISDNB -> V110H<BR> ISDNC -> X75<BR> <BR> H: INTERNET CAPABILITY FLAGS: <BR> <BR> FLAG MEANING<BR> <BR> IBN - denotes a system that does BINKP <BR> IFC - denotes a system that is capable of RAW or IFCICO <BR> ITN - denote a system that does TELNET <BR> IVM - denotes a system that is capable of VMODEM <BR> IFT - denotes a system that allows FTP <BR> ITX - denotes a system that uses TransX encoding for email<BR> tunneling<BR> IUC - denotes a system that uses UUEncode for email tunneling <BR> IMI - denotes a system which uses MIME encoding for email<BR> tunneling<BR> ISE - denotes a system which supports SEAT receipts for anonymous<BR> mail<BR> IP - denotes a system that can receive TCP/IP connects using a<BR> protocol that is not covered by any other flag. <BR> IEM - is a deprecated flag, and new implementations must not<BR> write it in nodelist entries. This was used as a single<BR> placeholder for the InterNet address of the system if it<BR> supported several transport methods. Instead of placing<BR> the system address in the deprecated form specified below<BR> in each flag, the address would be placed once only in this<BR> flag. Implementations may need to parse this information<BR> from nodelists created with older programs.<BR> <BR> Conversion from old Internet capabilty flags to the new flags:<BR> <BR> BND -> IBN<BR> TEL -> ITN<BR> TELNET -> ITN<BR> VMD -> IVM<BR> TCP -> IP<BR> <BR> The Internet Address should be placed in the BBS name field.<BR> <BR> Previous usage has placed the InterNet address as part of the<BR> I-flag (for example ITX:r10_tx@thevision.net); in this format the<BR> flag, colon, and address combined cannot exceed 32 characters.<BR> However, this practice is deprecated, and new implementations must<BR> not place address data in the flag section of the nodelist entry,<BR> implementations may however be required to read this data from the<BR> flag section.<BR> <BR> Telnet default port is 23. If the port is not 23 then the port<BR> number must be placed after the ITN flag (eg ITN:60177) if the<BR> Telnet address is part of the ITN flag (eg ITN:farsi.dynip.com) then<BR> the port number should be last (eg ITN:farsi.dynip.com:60177) always<BR> remember that the flag cannot exceed 32 characters total.<BR> <BR> The default ports for other protocols are shown below, and changes<BR> from the default port must be flagged in a similar way.<BR> <BR> Protocol Flag Default Port<BR> <BR> FTP IFT 21<BR> BINKP IBN 24554<BR> RAW/IFCICO IFC 60179<BR> VMODEM IVM 3141<BR> <BR> Actual IP addresses can also be placed in the phone number field<BR> using the country code of 000.<BR> <BR> I: SYSTEM ONLINE USERFLAGS<BR> <BR> The flag Tyz is used by non-CM nodes online not only during ZMH,<BR> y is a letter indicating the start and z a letter indicating the<BR> end of the online period as defined below (times in UTC):<BR> <BR> A 0:00, a 0:30, B 1:00, b 1:30, C 2:00, c 2:30,<BR> D 3:00, d 3:30, E 4:00, e 4:30, F 5:00, f 5:30,<BR> G 6:00, g 6:30, H 7:00, h 7:30, I 8:00, i 8:30,<BR> J 9:00, j 9:30, K 10:00, k 10:30, L 11:00, l 11:30,<BR> M 12:00, m 12:30, N 13:00, n 13:30, O 14:00, o 14:30,<BR> P 15:00, p 15:30, Q 16:00, q 16:30, R 17:00, r 17:30,<BR> S 18:00, s 18:30, T 19:00, t 19:30, U 20:00, u 20:30,<BR> V 21:00, v 21:30, W 22:00, w 22:30, X 23:00, x 23:30.<BR> <BR> For example TuB shows an online period from 20:30 until 1:00 UTC.<BR> <BR> Daylight saving time<BR> <BR> If a node changes online times with respect to UTC when daylight<BR> saving time becomes effective (which would be the case with most<BR> part time nodes), then this is to be taken into account when<BR> assigning this flag. An online times flag assigned to a node should<BR> not be altered for the specific purpose of adjusting due to<BR> daylight saving time, since large difference files (NODEDIFF's)<BR> would result if every node was allowed to do this, e.g. my node<BR> used to be online from 2300 to 0800 in local time, which in winter<BR> is UTC, but in the summer it becomes BST (British Summer Time).<BR> This is one hour ahead of UTC, and the corresponding availability<BR> times of my node during the summer period were 2200 to 0700 UTC.<BR> Therefore my online times flag would have indicated availability<BR> between the hours of 2300 and 0700 UTC, the daily time period<BR> encompassing both times, so the flag would be TXH.<BR> <BR> 2. Userflags<BR> ------------<BR> <BR> Registry of Userflags<BR> <BR> A. FORMAT OF USER FLAGS<BR> <BR> U,x..x<BR> A user-specified string, which may contain any<BR> alphanumeric character except blanks. This string may<BR> contain one to thirty-two characters of information<BR> that may be used to add user-defined data to a specific<BR> nodelist entry. The character "U" must not be<BR> repeated, eg, ",U,XXX,YYY,ZZZ" not ",U,XXX,U,YYY,UZZZ".<BR> The 32 character limitation is per userflag, not for<BR> the total of all userflags.<BR> <BR> New implementations must place a comma after the<BR> initial "U" before the user flags. Some<BR> implementations will not place a separating comma<BR> betweent the "U" and the first user flag, but this<BR> practice is deprecated. Implementations should be<BR> prepared to read flags in this format, and must strip<BR> the "U" from the flag before analysis in this case.<BR> <BR> Entries following the "U" flag must be of a technical<BR> or administrative nature. While experimentation of new<BR> software functions using this flag is encouraged,<BR> advertisement is strictly prohibited.<BR> <BR> For applications other than those shown, or if you<BR> have questions concerning the use of this field, please<BR> contact your Regional or Zone Coordinator.<BR> <BR> <BR> B: MAIL ORIENTED USER FLAGS:<BR> <BR> ZEC Zone EchoMail Coordinator. Not more than one entry<BR> in the zone segment may carry this flag and that entry<BR> must be the current Zone EchoMail Coordinator.<BR> <BR> REC Regional EchoMail Coordinator. Not more than one<BR> entry in any region may carry this flag and that entry<BR> must be the current Regional EchoMail Coordinator.<BR> <BR> NEC Network EchoMail coordinator. Not more than one entry<BR> in any net may carry this flag and that entry must be<BR> the current Network EchoMail Coordinator of that Net.<BR> <BR> <BR> SDS Software Distribution System<BR> <BR> SMH Secure Mail Hub<BR> <BR> NC Network Coordinator. This flag is ONLY to be used by<BR> the Network Coordinator of a net which has split the<BR> duties of NC and Host and the NC does NOT occupy the<BR> Net/0 position in the nodelist.<BR> <BR> <BR> A. Contact Data<BR> ---------------<BR> <BR> David Hallford <BR> Fidonet: 1:208/103<BR> <BR> Andreas Klein<BR> Fidonet: 2:2480/47<BR> E-mail: akx@gmx.net<BR> <BR> Michael McCabe<BR> Fidonet: 1:297/11<BR> <BR> Odinn Sorensen<BR> Fidonet: N/A<BR> E-mail: odinn@goldware.dk<BR> WWW: http://www.goldware.dk<BR> <BR> Colin Turner<BR> Fidonet: 2:443/13<BR> E-mail: ct@piglets.com<BR> WWW: http://www.piglets.com<BR> <BR> <BR> B. History<BR> ----------<BR> <BR> Rev.1, 19990627: Initial Release. Principal Author David Hallford<BR> <BR> <BR> </TT> <A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A> </BODY> </HTML>