Tillbaka till svenska Fidonet
English   Information   Debug  
ENET.SYSOP   33888
ENET.TALKS   0/32
ENGLISH_TUTOR   0/2000
EVOLUTION   0/1335
FDECHO   0/217
FDN_ANNOUNCE   0/7068
FIDONEWS   24099
FIDONEWS_OLD1   0/49742
FIDONEWS_OLD2   0/35949
FIDONEWS_OLD3   0/30874
FIDONEWS_OLD4   0/37224
FIDO_SYSOP   12852
FIDO_UTIL   0/180
FILEFIND   0/209
FILEGATE   0/212
FILM   0/18
FNEWS_PUBLISH   4393
FN_SYSOP   41678
FN_SYSOP_OLD1   71952
FTP_FIDO   0/2
FTSC_PUBLIC   0/13598
FUNNY   0/4886
GENEALOGY.EUR   0/71
GET_INFO   105
GOLDED   0/408
HAM   0/16069
HOLYSMOKE   0/6791
HOT_SITES   0/1
HTMLEDIT   0/71
HUB203   466
HUB_100   264
HUB_400   39
HUMOR   0/29
IC   0/2851
INTERNET   0/424
INTERUSER   0/3
IP_CONNECT   719
JAMNNTPD   0/233
JAMTLAND   0/47
KATTY_KORNER   0/41
LAN   0/16
LINUX-USER   0/19
LINUXHELP   0/1155
LINUX   0/22090
LINUX_BBS   0/957
mail   18.68
mail_fore_ok   249
MENSA   0/341
MODERATOR   0/102
MONTE   0/992
MOSCOW_OKLAHOMA   0/1245
MUFFIN   0/783
MUSIC   0/321
N203_STAT   924
N203_SYSCHAT   313
NET203   321
NET204   69
NET_DEV   0/10
NORD.ADMIN   0/101
NORD.CHAT   0/2572
NORD.FIDONET   189
NORD.HARDWARE   0/28
NORD.KULTUR   0/114
NORD.PROG   0/32
NORD.SOFTWARE   0/88
NORD.TEKNIK   0/58
NORD   0/453
OCCULT_CHAT   0/93
OS2BBS   0/787
OS2DOSBBS   0/580
OS2HW   0/42
OS2INET   0/37
OS2LAN   0/134
OS2PROG   0/36
OS2REXX   0/113
OS2USER-L   207
OS2   0/4786
OSDEBATE   0/18996
PASCAL   0/490
PERL   0/457
PHP   0/45
POINTS   0/405
POLITICS   0/29554
POL_INC   0/14731
PSION   103
R20_ADMIN   1121
R20_AMATORRADIO   0/2
R20_BEST_OF_FIDONET   13
R20_CHAT   0/893
R20_DEPP   0/3
R20_DEV   399
R20_ECHO2   1379
R20_ECHOPRES   0/35
R20_ESTAT   0/719
R20_FIDONETPROG...
...RAM.MYPOINT
  0/2
R20_FIDONETPROGRAM   0/22
R20_FIDONET   0/248
R20_FILEFIND   0/24
R20_FILEFOUND   0/22
R20_HIFI   0/3
R20_INFO2   3207
R20_INTERNET   0/12940
R20_INTRESSE   0/60
R20_INTR_KOM   0/99
R20_KANDIDAT.CHAT   42
R20_KANDIDAT   28
R20_KOM_DEV   112
R20_KONTROLL   0/13259
R20_KORSET   0/18
R20_LOKALTRAFIK   0/24
R20_MODERATOR   0/1852
R20_NC   76
R20_NET200   245
R20_NETWORK.OTH...
...ERNETS
  0/13
R20_OPERATIVSYS...
...TEM.LINUX
  0/44
R20_PROGRAMVAROR   0/1
R20_REC2NEC   534
R20_SFOSM   0/340
R20_SF   0/108
R20_SPRAK.ENGLISH   0/1
R20_SQUISH   107
R20_TEST   2
R20_WORST_OF_FIDONET   12
RAR   0/9
RA_MULTI   106
RA_UTIL   0/162
REGCON.EUR   0/2056
REGCON   0/13
SCIENCE   0/1206
SF   0/239
SHAREWARE_SUPPORT   0/5146
SHAREWRE   0/14
SIMPSONS   0/169
STATS_OLD1   0/2539.065
STATS_OLD2   0/2530
STATS_OLD3   0/2395.095
STATS_OLD4   0/1692.25
SURVIVOR   0/495
SYSOPS_CORNER   0/3
SYSOP   0/84
TAGLINES   0/112
TEAMOS2   0/4530
TECH   0/2617
TEST.444   0/105
TRAPDOOR   0/19
TREK   0/755
TUB   0/290
UFO   0/40
UNIX   0/1316
USA_EURLINK   0/102
USR_MODEMS   0/1
VATICAN   0/2740
VIETNAM_VETS   0/14
VIRUS   0/378
VIRUS_INFO   0/201
VISUAL_BASIC   0/473
WHITEHOUSE   0/5187
WIN2000   0/101
WIN32   0/30
WIN95   0/4288
WIN95_OLD1   0/70272
WINDOWS   0/1517
WWB_SYSOP   0/419
WWB_TECH   0/810
ZCC-PUBLIC   0/1
ZEC   4

 
4DOS   0/134
ABORTION   0/7
ALASKA_CHAT   0/506
ALLFIX_FILE   0/1313
ALLFIX_FILE_OLD1   0/7997
ALT_DOS   0/152
AMATEUR_RADIO   0/1039
AMIGASALE   0/14
AMIGA   0/331
AMIGA_INT   0/1
AMIGA_PROG   0/20
AMIGA_SYSOP   0/26
ANIME   0/15
ARGUS   0/924
ASCII_ART   0/340
ASIAN_LINK   0/651
ASTRONOMY   0/417
AUDIO   0/92
AUTOMOBILE_RACING   0/105
BABYLON5   0/17862
BAG   135
BATPOWER   0/361
BBBS.ENGLISH   0/382
BBSLAW   0/109
BBS_ADS   0/5290
BBS_INTERNET   0/507
BIBLE   0/3563
BINKD   0/1119
BINKLEY   0/215
BLUEWAVE   0/2173
CABLE_MODEMS   0/25
CBM   0/46
CDRECORD   0/66
CDROM   0/20
CLASSIC_COMPUTER   0/378
COMICS   0/15
CONSPRCY   0/899
COOKING   32712
COOKING_OLD1   0/24719
COOKING_OLD2   0/40862
COOKING_OLD3   0/37489
COOKING_OLD4   0/35496
COOKING_OLD5   9370
C_ECHO   0/189
C_PLUSPLUS   0/31
DIRTY_DOZEN   0/201
DOORGAMES   0/2053
DOS_INTERNET   0/196
duplikat   6002
ECHOLIST   0/18295
EC_SUPPORT   0/318
ELECTRONICS   0/359
ELEKTRONIK.GER   1534
ENET.LINGUISTIC   0/13
ENET.POLITICS   0/4
ENET.SOFT   0/11701
Möte FIDONEWS_OLD4, 37224 texter
 lista första sista föregående nästa
Text 12183, 407 rader
Skriven 2014-01-27 03:42:00 av FidoNews Robot (2:2/2.0)
Ärende: FidoNews 31:04 [03/08]: Ftsc Information
================================================
=================================================================
                        FTSC INFORMATION
=================================================================

Publication:  FTS-5000
Revision:     5
Title:        The Distribution Nodelist
Author(s):    FTSC Members, Administrator and Honoured Guests
Date:         2014-01-23
======================================================================

Status of this document
-----------------------

  This document is a Fidonet Technical Standard (FTS) - it specifies
  the current technical requirements and recommendations for FTN
  software developers, coordinators and sysops of the Fidonet network
  and other networks using FTN technology.

  This document is released to the public domain, and may be used,
  copied or modified for any purpose whatever.

Abstract
--------

  Current practice for Fidonet Technology Networks (FTN) is to
  maintain a nodelist used to store the details of the nodes in the
  network, and the network structure.


Contents
--------

  1.  Introduction
  2.  Supersessions
  3.  Purpose
  4.  Publication and Distribution
  5.  Content
      5.1  Comment Lines
      5.2  Special Header
      5.3  Data lines
  6.  Nodediffs
  7.  Segments

  A.  References
  B.  History

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


1. Introduction
---------------

  Fidonet is a peer-to-peer network utilising multiple different, and
  often incompatible, communication technologies that are independent
  of Fidonet itself, and is organised into a particular hierarchy for
  both technical and management purposes.

  For direct communication, it is necessary that the originating node
  knows in advance the exact method and capabilities of the destina-
  tion node in order to determine if, when, and how a direct Fidonet
  mail session can be established.  For routing and management, the
  stated hierarchy must also be known.

  All this information is collected into a file called the "nodelist".

  While nodelists of various flavours and completeness are in use, the
  "Distribution Nodelist" is the official record of all Fidonet nodes,
  their operators, their capabilities and their relation to each other
  in the network hierarchy.  In essence, the nodelist defines Fidonet.


2. Supersessions
----------------

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

  This document supersedes and replaces FTS-0005.


3. Purpose
----------

  Along with the companion technical standard (FTS-5001) this document
  defines the format and content of Fidonet's distribution nodelist.

  Unlike most FTSC documents, the nodelist standards are 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.

  It is assumed you're already familiar with Fidonet structure and
  addressing terminology.


4. Publication and Distribution
-------------------------------

  The Distribution Nodelist uses the filename NODELIST.nnn, where nnn
  is the day-of-year of publication, starting at 001 for the first day
  of January.  Partial and/or alternate nodelists must use some other
  base filename (i.e. in place of NODELIST).

  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
        J = .arj
        L = .lzh
        R = .rar
        Z = .zip

  The ZIP format is presently the official Fidonet standard, although
  others may be distributed in addition.


5. Content
----------

  The nodelist is a flat text file containing any number of lines,
  using only the ASCII (7 bit) character set.

  For the remainder of this document, characters in the range 00h to
  1Fh, plus 7Fh, shall be called "control characters," and characters
  in the range 20h to 7Eh shall be called "printable ASCII."

  Every line must be terminated with a carriage return (^M, 0Dh) and a
  line feed (^J, 0Ah), in that order.  The file itself must be
  terminated with a single EOF character (^Z, 1Ah), and no other data
  following.  Future implementations should accept nodelists with the
  EOF (^Z) character omitted.  No other control characters are
  permitted anywhere in the nodelist.

  Where the operating system uses a different format for text files
  software that reads the nodelist should also be able to handle
  nodelists stored in that format.  Where CRCs are to be calculated
  (see section 5.2) the calculations must be done as if the nodelist
  has the exact binary format described above.

  For compatibility with certain broken segment processors, nodelist
  maintainers should limit all lines to at most 157 characters (plus
  terminator).  It is very likely this limitation will be removed in
  the future, therefore future software implementations should be able
  to process lines of up to 1024 characters, and individual fields of
  up to 255 characters (unless otherwise specified).


5.1. Comment Lines
------------------

  Comment lines begin with a semicolon (3Bh) 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.


5.2. Special Header
-------------------

  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 publication date (described in section 4), and
  ends with a 5-digit decimal check value.  The publication date and
  check value are padded to length with leading zeros, if necessary.

  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.


5.3.  Data lines
----------------
  A nodelist data line contains no less than seven (7) variable length
  fields separated by commas (2Ch), defined below.  Each data line is
  a record/entry for an individual Fidonet node.

  Printable ASCII characters except for commas and spaces are allowed
  in all string fields unless specified otherwise.  Underscores (5Fh)
  are always used in place of spaces (20h).

  Field 1: Keyword

    Type: string;  Length: 1 to 6.

    The keyword field defines the type of node, and will either be
    empty or contain exactly one of the keywords defined below,
    grouped by functional class.

    No other keywords are valid in the distribution nodelist at this
    time, but private nodelist distributions may include other node
    types by marking them appropriately in this field.  One common
    example is the "Point" keyword.  See FTS-5002 for the pointlist
    specification.

    It is recommended that future implementations allow for keywords
    of up to 32 characters, and gracefully handle entries using
    unrecognized keywords.

    Full/Member Nodes -- these are the system numbers of individual
    Fidonet members.  See [Policy] for details on Fidonet membership.

      <empty>
        Defines a normal node entry.

      Pvt
        This keyword defines a Private node (see Policy v4.07,
        Section 2.1.9) - i.e. a node that is operational, but
        not publicly available for direct contact. When this keyword
        is used, field six should contain the string "-Unpublished-".

        In case the coordinator's nodelist processing software does
        not allow the use of "-Unpublished-" without the Pvt keyword,
        this keyword may also be used to list an internet only node.

        In either case, if the originating node cannot contact the
        destination node, mail may instead be routed via its Hub or
        Host.

        Pvt entries are only allowed as members of local networks.

      Hold
        Defines a node which is operational but cannot be publicly
        contacted.  This is expected to be a temporary condition.

        Mail may be sent to such nodes, routed via its Hub, Host or
        Coordinator, or held locally by the originating node until the
        Hold keyword is removed.

      Down
        Defines a node which is not operational.  This is expected to
        be (semi-)permanent.  Mail may NOT be sent or routed to it.

    Administrative Nodes -- these nodes indicate the beginning of a
    branch in the Fidonet addressing/management hierarchy.

    Each branch may contain one or more administrative nodes of lower
    tier, or any of the above member node types unless stated
    otherwise.

    Since the nodelist is a flat file, a branch is simply terminated
    at the next administrative node of equal or higher tier (or EOF).

    Member nodes are always part of an administrative branch, and may
    never appear at the top level of the nodelist.

    In order from highest to lowest:

      Zone
        Begins the definition of a geographic zone and defines its
        coordinator.  A zone is also a logical region AND net.

        Normal nodes immediately below a Zone node, and before any
        other administrative nodes, are Zone Independent Nodes.

      Region
        Begins the definition of a geographic region and defines its
        coordinator.  A region is also a logical net.

        Normal nodes immediately below a Region node, and before any
        other administrative nodes, are Region Independent Nodes.

      Host
        Begins the definition of a local network (net) and normally
        defines its coordinator (see FTS-5001 for the override flag).

      Hub
        Begins the definition of a routing subunit within a multilevel
        local network.


  Field 2: Node number

     Type: integer;  Range: 1 to 32767;  Length: 1 to 5.

     For member nodes and Hubs (which are treated as member nodes as
     far as addressing goes), this number is the node number, and must
     be unique within their local network.

     For a Zone entry, this number is the zone number.  A region and
     net number of equal value is implied, and the node number is
     zero.  Zone numbers must be unique across the entire network.

     For a Region entry, this number is the region number.  A net
     number of equal value is implied, and the node number is zero.
     Region numbers must be unique within each zone, but it is
     recommended future Region numbers be unique across the entire
     network for better 2D compatibility.

     For a Host entry, this number is the net number, and the node
     number is zero.  As with Region numbers, net numbers must be
     unique within each zone, but should be fully unique if possible.

     Because the node number zero is reserved for Zone, Region and
     Host entries, the value "0" is strictly forbidden in this field.


  Field 3: Node name

     Type: string.

     This is the name by which the system is known.

     Alternatively, this field may be used by IP nodes for a host
     name, static IP address or E-Mail address for email tunnelling
     programs.

     NOTE: There may be formatting limitations on this field for IP
     capable systems; consult the section on IP flags in FTS-5001.


  Field 4: Location

     Type: string.

     This is the physical location of the node.

     Generally, this is expressed as the primary local area (town,
     suburb, city, etc.) and where applicable, an underscore followed
     by the abbreviation of the regional geopolitical administrative
     district (state, province, department, county, etc.).


  Field 5: Sysop name

     Type: string;  Length: 1 to 36.

     This is the name of the Fidonet member responsible for the node.


  Field 6: Phone number (PSTN or ISDN)

     Type: string;  Length: 3 to 29 (theoretically);  Characters:
     digits and dashes, or the exact string "-Unpublished-"

     This field contains two or more numeric subfields separated by
     dashes (2Dh). The first field is the country code. The rest of
     the phone number should be formatted according to local practise.

     The various parts of the phone number are frequently used to
     derive cost and routing information, as well as what number is to
     be dialled. A typical example of the data in a phone number field
     is 1-800-555-0100, corresponding to country 1 (USA), area 800
     (area code), exchange 555, and number 0100.

     Alternatively, this field may contain the string "-Unpublished-"
     if the node has no conventional phone number. Software must
     recognize this string as an indicator to never attempt to dial
     this node by PSTN/ISDN.

     This field may also contain the static IPv4 address of an IP-only
     node in decimal format with periods replaced with dashes, and
     prefixed with a country code of 000.  This method should only be

--- Azure/NewsPrep 3.0
 * Origin: Home of the Fidonews (2:2/2.0)