=============================== Autocreated area ===============================
   From: Colin Turner                        2:443/13        19 Apr 99  20:45:54
     To: All                                                 20 Apr 99  17:25:30
   Subj: FTS5 Review                                                            
================================================================================
Hi Folks,

I am pleased to publish drafts of FTS-5000 and FTS-5001 in the next messages. 
These are intended to supercede FTS-5.

I would like to take a few moments to discuss the rationale behind some of these 
changes.

My predecessor as FTSC Administrator, Odinn Sorensen, proposed some time ago 
that the FTS family should be expanded into several series. Therefore nodelist 
related documents should all take the form of a code like FTS-5???. This concept 
was agreed by the committee, and it is hoped it will make the documents easier 
to navigate as we add new standards in the not too distant future. Odinn had 
also done some work on the document review.

The nodelist document has been split for pragmatic reasons, although the format 
of the distribution nodelist changes little as such, the various flags in use 
are much more dynamic. For this reason the flags have been moved to a separate 
document to make revisions more convenient.

David Hallford has been the instrumental member in this review of FTS5, 
consulting widely within the committee and drawing together the strands of these 
discussions in these documents. I would like to thank him here for his work so 
far on this document.

-=-

Now, to business, you may or may not know that a requirement of the committee is 
to publish standard drafts before they are finally published as official 
standards.

Comments and feedback from you is greatly appreciated, but if you want to be 
part of this process your comments much reach me (or David, or some other 
committee member) in good time.

Therefore I ask for comments before 10th May, which gives a generous three weeks 
to allow for some lag and some discussion.

This forum is the ideal venue for such comments, but if this is not possible, 
netmail me at 2:20/0 or email me at ct@ftsc.org and I will pass on the comments.

Thanks,

CT.

---
 * Origin:  - FTSC Member -  (2:443/13)

================================================================================
=============================== Autocreated area ===============================
   From: Colin Turner                        2:443/13        19 Apr 99  20:47:00
     To: All                                                 20 Apr 99  17:25:30
   Subj: FTS-5000 | Draft | Request for comments by 10th May                    
================================================================================
**********************************************************************
FTSC                             FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************

Publication:    FTS-5000
Revision:       0
Title:          THE DISTRIBUTION NODELIST
Author(s):      Colin Turner, Andreas Klein, Michael McCabe,
                David Hallford, Odinn Sorensen

Revision Date:  12 April 1999
Expiry Date:    12 April 2001
----------------------------------------------------------------------
Contents:
                1. Supercessions
                2. Purpose
                3. Publication and Distribution
                4. Contents
                5. Nodediff
----------------------------------------------------------------------

1. SUPERCESSIONS
----------------

  FTS-0005 superceded and replaced the documents known under the names
  of FSC002,  FSC-0002,  and FTS-0002.

  This document supercedes and replaces FTS-0005, FSC-0009, FSC-0040,
  FSC-0075, FSC-0091, and FSP (Lothar Behets IP flag proposal)

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 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
  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 (EOF = decimal
  character value 26).

  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, networks, 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.


      --
          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:

          

      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.

     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. HISTORY
-----------
   Rev.0, 19990404: Draft Release. Author David Hallford

---
 * Origin:  - FTSC Member -  (2:443/13)

================================================================================
=============================== Autocreated area ===============================
   From: Colin Turner                        2:443/13        19 Apr 99  20:45:02
     To: All                                                 20 Apr 99  17:25:30
   Subj: FTS-5001 | Draft | Request for comments by 10th May                    
================================================================================
**********************************************************************
FTSC                             FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************

Publication:    FTS-5001
Revision:       0
Title:          NODELIST FLAGS AND USERFLAGS
Author(s):      Colin Turner, Andreas Klein, Michael McCabe,
                David Hallford, Odinn Sorensen

Revision Date:  12 April 1999
Expiry Date:    12 April 2001
----------------------------------------------------------------------
Contents:
                1. Authorized Flags
                2. Userflags
----------------------------------------------------------------------

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 V21   300 bps full duplex
          V22       CCITT V22   1200 bps full duplex
          V29       CCITT V29   9600 bps half duplex
          V32       CCITT V32   9600 bps full duplex
          V32b      ITU-T V32bis 14400 bps full duplex
          V32T      V.32 Terbo
          V33       CCITT V33
          V34       CCITT V34
          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
          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

  F: INTERNET CAPABILITY FLAGS:

    FLAG   MEANING

    IBN - denotes a system that does BINKP
    IFC - denotes a system that is capable of RAW or IFCIFO
    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
    IEM - denotes a system which uses an e-mail tranfer protocol
         which is not covered by any other flag.
    IMI - denotes a system which uses MIME encoding for email
          tunneling
    ISE - denotes a system which uses SEAT encodeing for email
          tunneling
     IP  - denotes a system that can receive TCP/IP connects using a
        protocol that is not covered by any other flag.

  Conversion from old Internet capabilty flags to the new flags:

    BND -> IBN
    TEL -> ITN
    TELNET -> ITN
    VMD -> IVM
    TCP -> IP

  The Internet Address can be placed in the BBS name field or as part
  of the I-flag (example ITX:r10_tx@thevision.net). The flag, colon,
  and address combined cannot exceed 32 characters.

  Telnet default port is 23. If the port is not 23 then the port
  number should 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 same
  is true for FTP (IFT flag) except the default port is 21.

  Actual IP addresses can also be placed in the phone number field
  using  the country code of 000.

  G: 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

     Ux..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" should NOT be
               repeated, eg, ",UXXX,YYY,ZZZ" not ",UXXX,UYYY,UZZZ".
               The 32 character limitation is per userflag, not for
               the total of all userflags.

               It is recommended that the initial "U" is not followed
               by a comma and that flags following the first entry be
               separated by a comma, as in the above example.

               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. HISTORY
-----------
   Rev.0, 19990404: Draft Release. Author David Hallford

---
 * Origin:  - FTSC Member -  (2:443/13)

================================================================================
=============================== Autocreated area ===============================
   From: Mario Mure'                         2:335/533       20 Apr 99  21:42:28
     To: Colin Turner                                        21 Apr 99  05:40:46
   Subj: Re: FTS-5001 | Draft | Request for comments by 10th May                
================================================================================
 In a message dated 19 Apr 1999 about < FTS-5001 | Draft | Request for
 comments by 10th May >, Colin Turner wrote:

 CT>     IFC - denotes a system that is capable of RAW or IFCIFO
                                                ^^^^^^^^^^^^^^^^
Pardon ? I'm afraid there is some misspelling here :)


Ciao !


        /mario/       mure@sputnik.linux.it
                      http://www.fidoitalia.net

Grave Mistakes: by Paul Bearer
---
 * Origin: Give peace a chance (2:335/533)

================================================================================
=============================== Autocreated area ===============================
   From: Jan Vermeulen                       2:280/100       21 Apr 99  00:00:00
     To: Colin Turner                                        21 Apr 99  21:23:24
   Subj: FTS-5001 | Draft | Request for comments by 10th May                    
================================================================================
    Quoting Colin Turner on Mon 19 Apr 1999 20:45 to All:

    [...]
 ct>           Flag      Meaning

 ct>           MNP       Microcom Networking Protocol error correction

    [...]

    Could you please confirm (and indicate) that this relates to MNP1 thru MNP5, 
Colin, and not to MNP10 which AFAIK is a protocol used by GSM equipment prior to 
calling out


    -=<[ JV ]>=-

 * Origin: The Poor Man's Workstation (2:280/100)

================================================================================
=============================== Autocreated area ===============================
   From: Jan Vermeulen                       2:280/100       21 Apr 99  00:00:00
     To: Colin Turner                                        21 Apr 99  21:23:24
   Subj: FTS-5000 | Draft | Request for comments by 10th May                    
================================================================================
    Quoting Colin Turner on Mon 19 Apr 1999 20:47 to All:

 ct>   Field 4 - Location

 ct>      ... Wherever possible,  standard postal abbreviations for
 ct>      the major regional district should be used (IL, BC, NSW, etc.).

    Preferably: the ISO indication for the region or country:

    CN not PRC
    TW not ROC
    US not USA
    FI not SF
    IE not EIR


    -=<[ JV ]>=-

 * Origin: The Poor Man's Workstation (2:280/100)

================================================================================
=============================== Autocreated area ===============================
   From: Andre Grueneberg                    2:2411/525.1    21 Apr 99  16:36:20
     To: Colin Turner                                        22 Apr 99  03:22:20
   Subj: FTS-5001 | Draft | Request for comments by 10th May                    
================================================================================
                            -=( Hi *Colin*! )=-

*Colin Turner* schrieb eine Message an *All*, in der es heisst:

 CT>   A. FORMAT OF USER FLAGS
[...]
 CT> It is recommended that the initial "U" is not followed by a comma 
 CT> and that flags following the first entry be separated by a comma, 
 CT> as in the above example. 

But using a comma after the initial "U" makes parsing easier, because you 
don't need to handle two flags for one purpose "Uxxx" and "xxx". I would 
suggest a comma after the "U" especially for compatibility reasons.

    -=( CU *Andre* )=-         E-Mail: andre@grueneberg.de 
... Minds, like parachutes, work only when open...
---
 * Origin: No advertisement for ComTel BBS anymore (2:2411/525.1)

================================================================================