Hi...

the following text tries to document differences between
FTS-0005.003 and common practice in zone 2, and proposes a
few changes of FTS-0005.003.

                Greets, Frank
~~~ cut ~~~

   Introduction
   ------------
   This document informs about known differences of FidoNet zone 2
   nodelist flags from FTS-0005.003.  The ultimate sources for these
   informations are the current zone 2 nodelist epilog and the setup
   for flag corrections at Z2C, but it may be difficult to get these
   sources for readers in other zones.

   FTS-0005 flags
   --------------
   The following flags are used as specified in FTS-0005.003:

        CM      Node accepts mail 24 hours a day
        MO      Node does not accept human callers
        LO      Node accepts calls only from valid listed node
                numbers in the current FidoNet nodelist

        V21     ITU-T V21      300 bps full duplex
        V22     ITU-T V22     1200 bps full duplex

   In zone 2 a value of 1200 in the former "baud rate" field implies
   V22.  Today only two nodes not supporting at least V22bis or ISDN
   still exist in the zone 2 segment, therefore the flags V21 and V22
   are obsolescent.  Both flags should be dropped from FTS-0005.

        V29     ITU-T V29     9600 bps half duplex
        V33     ITU-T V33

   V33 cannot be used in connecting Fido nodes over public dial-up
   lines and is most probably a historical error in FTS-0005.  This
   flag should be removed from FTS-0005 a.s.a.p.  A similar argument
   is applicable on V29, and few nodes flagging V29 today all support
   at least V32.  The next version of FTS-0005 should drop V29.

        V32     ITU-T V32     9600 bps full duplex
   ->   V32B    ITU-T V32bis 14400 bps full duplex (implies V32)
        V34     ITU-T V34    28800 bps full duplex

   FTS-0005 specifies V32b and V42b (capital V and small b), current
   nodelist practice in FidoNet shows all combinations of small and
   capital letters for flags.  This was no problem before FSC-0062
   introduced case-sensitive flags.  In zone 2 all old flags except
   from FSC-0062 flags are upper case, and a NODEDIFF changing this
   convention would be annoying.  The best solution is to stick to
   the current practice and treat all old flags as case-insensitive.

        H96     Hayes V9600
        HST     USR Courier HST up to 9600  (implies MNP)
        H14     USR Courier HST up to 14400 (implies HST)
   ->   H16     USR Courier HST up to 16800 (implies H14 and V42B)
        MAX     Microcom AX/96xx series
        PEP     Packet Ensemble Protocol
        CSP     Compucom Speedmodem
   ->   ZYX     Zyxel series 16800 bps (implies V32B and V42B)
   ->   V32T    V.32 Terbo   19200 bps (implies V32B)
        VFC     V.Fast Class 28800 bps

   If a flag directly or indirectly implies other flags, then these
   other flags are not shown in a nodelist entry, because this would
   be redundant.  Unfortunately the rules for redundancies in zone 2
   and FTS-0005 are different.  Zone 2 continued to avoid redundancy
   with most "new" flags, but FTS-0005.003 specified no redundancies
   for "new" flags like ZYX, H16, V32T, or VFC.  "New"
flags in this
   context are flags approved by FidoNet International Coordinators
   since 1989, when FTS-0005.TXT, the predecesssor of FTS-0005.0003,
   was published.

   For details see the chapter "implications" below, for now only
   note, that in zone 2 H16 implies V42B, ZYX implies V32B and V42B,
   and V32T implies V32B.

   Zone 1 and zone 2 have introduced a user flag Z19 approved by the
   corresponding Zone Coordinator.  User flags are discussed later,
   for now only note, that in zone 2 ZYX is specified as Zyxel 16k8,
   while FTS-0005.003 not knowing Z19 specifies ZYX as generic flag
   for all Zyxel protocol speeds.

   Marginal note: Variants of V32 at 12000 bps compatible with V32B
   and of V32T up to 21600 bps (seen as H21 flag in zone 1) have no
   more practical relevance today, therefore new flags for these
   protocol variants are useless.  However, if a future version of
   FTS-0005 replaces the former "baud rate" field by a speed field,
   then 12000 and 21600 should be allowed among others like 57600.

   Today there is only one node in FidoNet still flagging MAX, this
   flag is obsolete and should be dropped from FTS-0005. The flags
   HST, H14, and CSP should be marked as obsolescent.

        MNP     Microcom Networking Protocol error correction
        V42     ITU-T LAP-M error correction w/fallback to MNP 1-4
   ->   V42B    ITU-T LAP-M error correction w/fallback to MNP 1-5

   As mentioned above FTS-0005 specifies V42b (capital V, small b).
   In zone 2 all case-insensitive flags are listed in upper case.

   The next version of FTS-0005 will probably adopt the better V42B
   and MNP definitions of the zone 3 nodelist epilog.  FTS-0005.003
   specifies an implication of V42 by V42B, but the exact meaning of
   the flag MNP is unclear.  Most probably this flag was meant to
   indicate support of MNP 1-4, and in this sense V42B implies MNP.

   In zone 2 MNP is considered as redundant, if V42B is flagged or
   implied by other flags like H16, ZYX, or Z19.

        MN      No compression supported

        XA      Bark and WaZOO file/update requests
        XB      Bark file/update requests, WaZOO file requests
        XC      Bark file requests, WaZOO file file/update
        XP      Bark file/update requests
        XR      Bark and WaZOO file requests
        XW      WaZOO file requests
        XX      WaZOO file/update requests

   These flags are equivalent in FTS-0003 and in the zone 2 segment.

        Gx..x   Gateway to domain 'x..x'

   Valid values for this flag are assigned by the Fido International
   Coordinator, FTS-0005.003 explicitly mentions GUUCP.  In zone 2
   only GUUCP gateways are flagged.

        #01     Zone 5 mail hour (01:00 - 02:00 UTC) w/ Bell 212A
        !01     Zone 5 mail hour (01:00 - 02:00 UTC) no Bell 212A
        #02     Zone 2 mail hour (02:30 - 03:30 UTC) w/ Bell 212A
        !02     Zone 2 mail hour (02:30 - 03:30 UTC) no Bell 212A
        #08     Zone 4 mail hour (08:00 - 09:00 UTC) w/ Bell 212A
        !08     Zone 4 mail hour (08:00 - 09:00 UTC) no Bell 212A
        #09     Zone 1 mail hour (09:00 - 10:00 UTC) w/ Bell 212A
        !09     Zone 1 mail hour (09:00 - 10:00 UTC) no Bell 212A
        #18     Zone 3 mail hour (18:00 - 19:00 UTC) w/ Bell 212A
        !18     Zone 3 mail hour (18:00 - 19:00 UTC) no Bell 212A
        #20     Zone 6 mail hour (20:00 - 21:00 UTC) w/ Bell 212A
        !20     Zone 6 mail hour (20:00 - 21:00 UTC) no Bell 212A

   In zone 2 #02 or !02 would be obviously redundant.  These flags
   are old-fashioned, as they indicate an obsolete protocol, and are
   less flexible than FSC-0062.  Concatenations of more than one mail
   hour into one flag like #08#09 don't exist in the zone 2 segment.

   A future version of FTS-0005 should mark these flags as obsolete
   as soon as FSC-0062 has been adopted as FTS by the FTSC.

   User flags
   ----------
   An example for one of several problems in zone 2 with user flags:

        ...,U,Z19,V110H,V120L,V120H,X75,ENC,NEC

   These flags indicate a modern Zyxel ISDN-modem and two additional
   user flags ENC and NEC.  This possible user flags string contains
   34 characters, but at most 32 characters are allowed in FTS-0005.

        ...,U,Z19,V110L,V110H,X75,ISDNA,ISDNB,ISDNC

   During the period for the replacement of old by new ISDN flags
   (several months !) many nodes listed both old and new flags for
   maximal compatibility, and no problems with nodelist compilers
   or mailers caused by too long user flags strings were reported.

   Therefore the length limit in FTS-0005 is probably unnecessary
   and at least inconsequent: Other nodelist fields like the system
   name are unlimited, so why only restrict the user flags string ?
   To help developpers an upper limit of e.g. 255 characters for a
   nodelist line could be probably more useful.

   The next problem with user flag strings as specified in FTS-0005
   is their introduction by the letter U with no comma following:

   Nodelist compilers could parse ...,UISDN,USR in user flags ISDN
   and USR.  But USR cannot be approved as "real" flag, because the
   combination ...,USR,UISDN would then be parsed in SR and UISDN.

   Other side effects of the FTS-0005 specification are additional
   difficulties in finding flags.  Almost all flags are separated
   by a comma, only the first user flag can be an exception to this
   simple rule.  If the order of user flags has no meaning, then...

        ...,UV120L,V120H
        ...,UV120H,V120L

   ... are equivalent.  A "simple" solution of this problem could be
   to treat UV120L as synonym for V120L, and UV120H as synonym for
   V120H.  Similar problems show up, if user flags are counted, etc.

   Obviously a nodelist compiler looking for user flags has always
   to consider the case "user flag separated by comma".  In zone 2
   this idea was simply extended to the first user flag:

   All flags are separated by commas.  Flags not yet approved by the
   International Coordinator or the FTSC (i.e. user flags only used
   experimentally or locally) are separated by a new pseudo flag U.

   ->   U       pseudo flag to the left of at least one user flag

   All flags following this pseudo flag U are user flags, all flags
   before this pseudo flag are "real" flags specified in FTS-0005 or
   approved by the International Coordinator.

   Because this definition should be compatible with any reasonable
   software implementation based on FTS-0005.003, and simplifies the
   handling of user flags significantly, a future FTS-0005 version
   will hopefully adopt it.

   Approved zone 2 user flags
   --------------------------
   In zone 2 user flags have to be approved by the Zone Coordinator.
   Currently the following zone 2 user flags exist:

   ->   V110L   ITU-T V.110 19k2 async 'Low'    (former ISDNA)
   ->   V110H   ITU-T V.110 38k4 async 'High'   (former ISDNB)
   ->   V120L   ITU-T V.120 56k6 async, N1 = 259, W = 7, modulo 8
   ->   V120H   ITU-T V.120 64k  async, N1 = 259, W = 7, modulo 8
   ->   X75     ITU-T X.75 SLP (single link procedure),
                64kbit/s B channel; layer 2 max. framesize N1 = 2048,
                window size W = 2, frame numbering modulo 8;
                layer 3 transparent (no packet layer)
   ->   ISDN    Other configuration, used only if none of above fits

   These ISDN flags follow the specification in FSC-0091.

   ->   Tyz     Online time flags as specified in FSC-0062

   The flag Tyz is used by non-CM nodes online not only during ZMH,
   y is a letter indicating the start and z a letter indicating the
   end of the online period as defined below (times in UTC):

        A  0:00,  a  0:30,   B  1:00,  b  1:30,   C  2:00,  c  2:30,
        D  3:00,  d  3:30,   E  4:00,  e  4:30,   F  5:00,  f  5:30,
        G  6:00,  g  6:30,   H  7:00,  h  7:30,   I  8:00,  i  8:30,
        J  9:00,  j  9:30,   K 10:00,  k 10:30,   L 11:00,  l 11:30,
        M 12:00,  m 12:30,   N 13:00,  n 13:30,   O 14:00,  o 14:30,
        P 15:00,  p 15:30,   Q 16:00,  q 16:30,   R 17:00,  r 17:30,
        S 18:00,  s 18:30,   T 19:00,  t 19:30,   U 20:00,  u 20:30,
        V 21:00,  v 21:30,   W 20:00,  w 20:30,   X 23:00,  x 23:30.

   For example TUB shows an online period from 20:00 until 1:00 UTC.

   ->   Z19     Zyxel series 19200 bps (implies ZYX)

   ->   K12     Systems offering all educational K12-conferences
   ->   ENC     The node accepts inbound encrypted mail

   ->   NC      Network Coordinator (only if the NC is not the host)
   ->   NEC     Net Echomail Coordinator    (at most one per net)
   ->   REC     Region Echomail Coordinator (at most one per region)
   ->   ZEC     Zone Echomail Coordinator   (at most one per zone)

   Redundant AKAs used to indicate echomail coordination in zone 2
   are no longer permitted.  One *EC flag is valid for all AKAs of
   a given sysop.

   Flag implications
   -----------------
   Flag implications directly or indirectly specified in FTS-0005:

        HST     => MNP
        H14     => MNP HST
        H16     => MNP HST H14
        V42b    => V42 (MNP ?)
        V32b    => V32

        XA      => XW XR XP XB XC XX
        XB      => XW XR XP
        XC      => XW XR XX
        XR      => XW
        XX      => XW

   Of course flags checking software handling not only redundancies
   would simply look for more than one of flag XA XB XC XP XR XW XX
   and treat this as error.

   Flag implications specified in the zone 2 nodelist epilog:

        HST     => MNP
        H14     => HST MNP
   ->   H16     => V42 MNP V42B H14 HST
   ->   V42B    => V42 MNP
   ->   ZYX     => V42 MNP V42B V32B
   ->   Z19     => V42 MNP V42B V32B ZYX
        V32B    => V32
   ->   V32T    => V32 V32B

   ->   V110L   => ISDN
   ->   V110H   => ISDN
   ->   V120L   => ISDN
   ->   V120H   => ISDN
   ->   X75     => ISDN

   The latter ISDN flag redundancies are a consequence of FSC-0091.
   Maybe one of the following implications could be added in zone 2:

        VFC     => V32 V32B
        VFC     => V32 V32B MNP V42 V42B


---