Subj : human-readable nodelist format
To   : andrew clarke
From : Scott Little
Date : Sat Nov 02 2002 10:47 am

[ 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).

<end brainstorm session>
<makes note to switch to decaf>


-- Scott Little  [fidonet#3:712/848 / [email protected]]

--- FMail/Win32 1.60+
* Origin:  Cyberia: All your msgbase are belong to us! (3:712/848)

You are viewing proxied material from vert.synchro.net. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.