[ 02 Nov 02 05:55, andrew clarke wrote to Scott Little ]

 ac> fields 3 to 8 of the Boss entry in the pointlist must be a copy of the
 ac> same corresponding fields in the nodelist entry unless those fields
 ac> are left out altogether, etc.

Speaking of which.. is it worth allowing dummy entries?  ie. dummies for
St. Louis style would be:

zone,3
region,54
host,712
,848
point,1,foo,bar,baz,-unpublished-,etc,etc,etc.

This allows specifying (but not overriding existing) missing hierarchy*
pieces that aren't part of the address (all of it for St. Louis, Domain and
Region for HRN) without back-tracing.

Of course dummy entries would only be valid for supplemental and maybe
segment nodelists.  Segment lists should also allow Origin and Password
keywords (a bit of extra security)... or maybe some convention for private
non-replicating keywords that is easily matched with wildcards (eg. x- or
pvt-) and removed.

*And on the subject of hierarchies..

1) this format allows any node to be a Zone, Region, Net or Host, where
traditionally they'd be Z:Z/0, Z:R/0 or Z:N/0.  This would allow entries
incompatible with the current scheme, therefore making backwards conversion
impossible if someone were to create such an entry.  The specs should
include the proper addressing convention for such special node types, but
stress this is current convention only and may change (ie. a note to lazy
programmers who would normally just assume /0, to implement it properly).

2) Is "uplink" the primary or alternate uplink, or both?  Perhaps
this keyword should change to "peers" and then list the systems
it peers with (that allow public relaying from it), either in order of
preference or with a numerical preference (ala DNS MX records).

This would make mapping the ideal route to a node easier, and allow Zones
to specify who they connect with.  Also, a node's Hub, Host or Region
(RINs) is automatically implied at lowest priority, if not specifically
listed otherwise.

There should be no technical limit to the number of peers allowed, but all
software should be capable of correctly parsing the list to be considered
compliant (ie. if they are numerically ordered, the software should read
the entire list and accept the X most top ranked; if they are order
dependant, the first X are accepted and the rest ignored rather than
overwriting the previous).

The maximum peers permitted in a nodelist would be determined by the *C's.
Ideally, segment processors would be able to strip excess peers before
sending to an uplink, allowing more peers for smaller segments (net, region
or zone), and fewer for the the large ones (some of the big euronets and
the international list).





-- Scott Little  [fidonet#3:712/848 / sysgod{at}sysgod.org]

--- FMail/Win32 1.60+