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

Tue 2002-11-05 17:54, Scott Little (3:712/848) wrote to andrew clarke:

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.

Or one pass, then an in-memory search.  I don't think this is a big problem.

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.

OK.

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

Yep.  I'd like to get over the first hurdle of actually getting people used to
the idea of a new format though.  ;-)

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

diff -n ?

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.

I suppose it could happen.  ;-)

I don't actually know what the situation is with the Pvt,-Unpub- issue.

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.

It's not difficult technically.  The problem is whether people want to have
web-structure routing information in the nodelist in addition to the default
tree-structure.  Some may not to.  But I suppose at the end of the day each ZC
will have control over what goes into their nodelist so it's probably not a big
deal.

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.

Yes, "ignore", not "strip out".  ;-)  I was refering to nodelist parsing
software ignoring new keywords it doesn't recognise (instead of failing).
Segment merging software shouldn't strip out anything unless it's been told to.

-- [email protected]

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

You are viewing proxied material from cvs.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.