Text 12184, 192 rader
Skriven 2014-01-27 03:42:00 av FidoNews Robot (2:2/2.0)
Ärende: FidoNews 31:04 [04/08]: Ftsc Information
================================================
used in exceptional circumstances, since it risks conflict with
conventional dialling, and it is almost always better to list a
fully qualified domain name in a field that allows it.
Field 7: DCE speed (required, but obsolete)
Type: string; Length: 1+
In the past, this field was used to show the maximum modem speed
supported by the node, but has since been obsoleted in favour of
the more accurate modem flags.
Commonly accepted values in this field are: 300, 1200, 2400,
4800, 9600, 14400, 16800, 19200, 28800 and 33600. These values
are normally enforced by segment processing software; deviations
risk the entire entry being declared in error and dropped from
the nodelist or segment.
Systems without a listed PSTN line must use 300, including ISDN
and IP only nodes. All others may use whichever value is most
appropriate. Because this field is now of little value except
for human readers, most PSTN capable systems currently list at
most 9600. Nodelist maintainers should confirm with their
Coordinator(s) before listing higher rates.
Field 8+: Flags (optional)
Type: string; Length: varied; Characters: varied.
Any remaining fields from position eight (8) onward are flag
fields. Note there may or may not be a trailing comma after
Field 7 if there are no flags listed.
See FTS-5001 for details on the flag fields, including length
restrictions.
6. Nodediffs
------------
The nodelist, even in archive form, is a substantial document (or
file). To reduce bandwidth usage/waste and transmission times, a
smaller file called a "nodediff" is generated using the previous
week's nodelist. The nodediff is actually an editing script which
contains only new or changed lines between the two nodelists, plus a
number of editing commands.
The nodediff file is named and archived in the same way as the full
Distribution Nodelist, except with a base filename of NODEDIFF.
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 is no
terminating EOF (^Z) character on a nodediff.
There are three editing commands and all have the same format:
<command><number>
<command> is a 1-letter command; A, C, or D. <number> is an
integer from 1 to 32767 (inclusive), 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.
7. Segments
-----------
Segments are partial nodelists, usually containing only one complete
branch of nodes, starting at the relevant zone, region, host or hub
node. The Distribution Nodelist is also referred to as a composite
nodelist, as it is assembled from multiple zone-lists.
The format and structure is the same as the Distribution Nodelist,
including the header, with a base filename of local invention,
usually derived from the contents of the segment (e.g. N712LIST.nnn
or N712SEG.nnn for a segment containing all the nodes in Net 712).
To generate the Distribution Nodelist, segments propagate up through
the network's administrative hierarchy, each tier compiling segments
from the tier immediately below, then passing on the resulting
segment to the next tier upstream.
For example, a Network Coordinator will collect Hub Segments from
all the hubs in the same local network, compile it into a Network
Segment, and forward it on to the Regional Coordinator. And so on.
Segments can also be sent back downstream - this is most commonly
done with Zone Nodelists. Nodes that do not need to attempt direct
contact with nodes in other zones can use the Zone Nodelist instead
of the full composite nodelist, saving on storage space and
transmission time.
A. References
-------------
[FTS-0005] "The distribution nodelist", Ben Baker, Rick Moore.
February 1989. Obsoleted by this document.
[FTA-1006] "Keywords to indicate requirement levels"
FTSC, 2000-01-17.
[Policy] "FidoNet Policy Document" v4.07 - June 9, 1989.
B. History
----------
Rev.1, 1999-06-27: Initial Release. Principal Author David Hallford
Rev.2, 2000-04-24: 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.
Rev.2, 2004-08-17: Re-re-draft by FTSC.
Added Introduction and Segments sections.
More allowances for IP listings.
Reorganised/reindexed Content section.
Added length limits to fields where they could
be determined.
Clarification on usage of Keywords.
Clarification on special node numbers.
ZCs authorise that ZIP is now the default
Archival/compression tool for distributed files.
Rev.3, 2012-11-12: There is no version 3. The above version
2004-08-17 should have been labelled version 3,
but due to a clerical error it was also labelled
version 2. So there are two version 2's. Rather
than attempting to correct the error, which
would probably not have succeeded as it is next
to impossible to recall a file that was hatched
many years ago, it was decided to leave things
as they are, skip version 3 and carry on with
version 4.
Rev.4, 2012-12-17: Allow -Unpublished- with Down (par 5.3, field 6)
Various small rewordings, clairifications and
corrections of spelling errors.
Rev.5, 2014-01-23 Allow -Unpublished- with any or no keyword.
"must" replaced by "should" on 157 char limit.
Added reference to FTA-1006.
Corrected a few spelling errors.
Reformatted for compliance with FTA-1002.003
**********************************************************************
-----------------------------------------------------------------
--- Azure/NewsPrep 3.0
* Origin: Home of the Fidonews (2:2/2.0)
|