Subj : human-readable nodelist format
To   : Scott Little
From : andrew clarke
Date : Tue Nov 05 2002 10:31 am

Sat 2002-11-02 09:47, Scott Little (3:712/848) wrote to andrew clarke:

 ac>> fields 3 to 8 of the Boss entry in the pointlist must be a copy of 
 ac>> the same corresponding fields in the nodelist entry unless those 
 ac>> fields 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.

Well, the spec just defines a way to list nodes.  The hierachy is only 
important when it comes down to default mail routing, and politics. Parsing 
software should be able to handle undefined nodes referenced by other nodes 
without failing (and maybe just print a warning message) unless this is 
unavoidable.

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

Probably a good idea.  I think nodelist segments (and diffs) should probably be 
the subject of another document though, where the Origin and Password keywords 
can be described in terms of segment processing software and not in terms of 
the entire nodelist, because it would make no sense there, although maybe the 
Origin keyword would, I'm not sure.

The actual process of merging HRN segments isn't something I've given a great 
deal of thought yet, because I don't know enough about what goes on now to 
propose what should happen in future.  I do think a diff format that is 
standard (like GNU diff/patch) should be used rather than the obscure format 
used with nodediffs now.  And of course, get rid of the vastly obsolete CRC in 
the new format nodelist altogether.

 > *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.

True.

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

I'll add the proper addressing convention in.  I'm not sure about the "may 
change" part though.  It will never change until people stop using FTS-5 
nodelists outright for a start.  Then there is still the human problem (?) of 
people without a nodelist assuming that for eg. if they send mail to 3:3/0 they 
will get the Z3C.  But yes, if the HRN happens to have an entry like:

Address 3:666/666
Status Zone

Then there should probably be no reason why this can't be allowed in principle, 
but that HRN parsers should probably print a really big agressive warning 
saying that it's not backwards compatible with FTS-5 and that you'll go blind 
if you keep doing that.

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

....

Uplink is the primary uplink, ie. the parent of the node.

Your idea (and somebody else mentioned something like this in FTSC_PUBLIC also) 
about listing non-default/ideal routing is fine technically but it may be 
difficult to get a consensus as to whether it's achievable if/when it comes to 
implementing it, and/or whether it's relevant in the basic nodelist at all.  So 
it should probably be addressed in another document.

And I should add to the current spec that "keywords in the nodelist that are 
not recognised should be ignored"!

-- mail@ozzmosis.com

--- Msged/NT 6.1.1
 * Origin: Blizzard of Ozz, Mt Eliza, Victoria, Australia (3:633/267)

.