Subj : human-readable nodelist format
To   : andrew clarke
From : Scott Little
Date : Sat Nov 02 2002 09: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 / sysgod@sysgod.org]

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

.