Subj : human-readable nodelist format
To   : andrew clarke
From : Scott Little
Date : Tue Nov 05 2002 05:54 pm

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

ac> The hierachy is only important when it comes down to default mail
ac> routing, and politics. Parsing software should be able to handle

Thing is, this format requires at least two scans of the nodelist to find a
node and it's uplink.  The only shortcut is to assume an uplink of /0 for
normal nodes.

ac> Probably a good idea.  I think nodelist segments (and diffs) should
ac> probably be the subject of another document though

St Louis segments are the same as the complete nodelist, only smaller, but they
rely on static filenames to figure out who it's from and what it's for, which
bothers me.  If the nodelist contains it's origin, basic security, and any
necessary dummy hierarchial information, that is no longer necessary.

ac> and Password keywords can be described in terms of segment processing
ac> software and not in terms of the entire nodelist, because it would

It still needs to be standardised otherwise everyone will come up with their
own method :)

ac> goes on now to propose what should happen in future.  I do think a
ac> diff format that is standard (like GNU diff/patch) should be used
ac> rather than the obscure format used with nodediffs now.

"diff" has a mode that is more or less identical to the current nodediff format

ac> I'll add the proper addressing convention in.  I'm not sure about the
ac> "may change" part though.  It will never change until people stop
ac> using FTS-5 nodelists outright for a start.

You never know.  Insufficient separation between Policy and Technical lead us
to the Pvt,-unpublished- issue, for example.

ac> FTSC_PUBLIC also) about listing non-default/ideal routing is fine
ac> technically but it may be difficult to get a consensus as to whether
ac> it's achievable if/when it comes to implementing it

It's no more difficult than back tracing "uplink" keywords until you bump into
a node that I'm able to connect to.

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

That will limit future developments, as old software will strip out new lines.
The equivalent of all IP flags getting removed because an old processor was
written before they exists.  Best to pass on unknown keywords, the ZC's can
determine what's valid in their zones and filter out the rest intelligently.


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

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