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{at}ozzmosis.com

--- Msged/NT 6.1.1