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.

-- mail{at}ozzmosis.com

--- Msged/NT 6.1.1