JB>>> Hi mark. subj. tell me more.

 ml>> here's what i had spoken of some years ago...

 JB> It's long, and I've replied as I went... so I may
 JB> have duplicated some of your ideas...

n.p.

 ml>> i'd love to be able to list all my capabilities on my main address
 ml>> and any AKAs that need it... that'd mean that we'd need another
 ml>> "phone" field... the nodelist does need a
"bit" of reworking but i
 ml>> don't see it as reducing the size of it..

 JB> Are there filesize issues with the nodelist?

not a FILEsize issue... not really... the nodelist was originally created
as the "phonebook" of fidonet... it was not designed for human
consumption, though... many folk complain that they can't read the nodelist
because of various factors... the meanings of the flags, and other such
that we've been hearing about for many many years...

 JB> IIRC most of the issues with the nodelist in the FIDONEWS
 JB> thread were problems with it just not working.

not sure i understand... the nodelist works... but there are some who may
not know their software as well as they may think and thus may have issues
with certain conventions being used...

 JB> As I see it the nodelist is mainly a list of all the
 JB> nodes in fidonet so giving their identieies and contact
 JB> information that they can be crashmailed

direct, endpoint to endpoint connection capabilities was desired and needed
at one point in time... there are still cases where it is desirable...
however, due to the ability of fidonet to transport information over
disparate networks (POTS being one, TCP/IP being another and others may
also be out there), its been known by the developers, even way back when,
that there would come a time where one may not be able to contact ~ALL~
nodes directly unless one's own system is multiply connected to the various
networks...

 JB> It's not really needed for routed netmail, or for
 JB> echomail etc which is basically just passed node to node
 JB> (to pass for echomail and netmail you only need to know
 JB> your neighbours)

right... however, there is software that only allows one to create and or
send mail to nodes that are verified as existing... this is done via a
lookup in the nodelist... some software refuses to go on until the node is
seen in the nodelist... other software will allow you to continue and
possibly have some sort of routing in place to follow...

 ml>> ie: maybe something like this... //wrapped for clarity

 ml>>  ,12,Waldo's_Place_USA,Sanford_NC,Mark_Lewis,CM,XA,-//
 ml>>  ,1-919-774-5930,V32b,V42b,H16,V32t,V34,-//
 ml>>  ,bbs.wpusa.dynip.com,ITN,IVM,-//
 ml>>  ,USDS,PITA,PIZZA

 JB> so basically a identificaation block followed by connection
 JB> blocks, and a flags block (but all on one line)

yeah, that was the original... however, with many folk still having and
using older programming languages and compilers that do have specific line
length limits, i don't know that it is really such a good format... and
other things to consider, as well...

 ml>> basically, moving the CM,MO and mailer capability flags
 ml>> to after the sysop name... a ,-,

 JB> I think the CM flag belongs with the connection - say if
 JB> someone only has the POTS line available at night but has
 JB> internet up 24 hours.

this is one of those other things to consider...

 JB> maybe allow flags in the ID block there but also allow
 JB> them to be overridden in the connection block

that may be a possibility...


[trim]

 JB> nah. i don't like it. (I see you have better solutions later)

 JB> What if someone has internet, ISDN and two phone lines.
 JB> why limit the connection blocks,

personally, i don't see any problem/difference between ISDN and POTS other
than one being digital and the other being analogue... i've never had any
problem picking up my POTS telephone and calling someone with an ISDN phone
and talking to them... yes, i know there are several variations of ISDN
that are incompatible with each other but that is taken care of with the
current ISDN flags, right?

in any case, i do see the "bottom of the stack" of what you are
looking at... being able to list each method for one address and thus not
having to have multiple addresses and the added complexity that that brings
with it... i'm also not eliminating multiple address capabilities because
they are still necessary... even if only for administrative addresses...

 ml>> with one empty field where all the IP stuff would be... an IP
 ml>> only, continous mail, mail only system would look like..

 ml>> of course, a system with no POTS or IP or userflags would simply
 ml>> be...

 ml>> ,12,Waldo's_Place_USA,Sanford_NC,Mark_Lewis,-,,-,,-,,

 ml>> -=%*)

 JB> no PVT flag ? (i guess it's not really needed)

exactly >

 ml>> the first problem i see is one of line length unless we also
 ml>> implement something like the above //wrapped style..

 JB> yeah, definately, why not make it the law:
 JB> how about this instead.

 JB> any reason why the userflags can't follow the identity line.

not that i can see... i just chose an arbitrary layout after seperating the
data into the basic "chunks"...

 DM>>> However, the standard could be written so that software
 DM>>> developers know the direction we're headed and nodes would
 DM>>> know what future upgrades might be necessary.

 ml>> i'm sure the developers will already know what direction
 ml>> folks want to head off in long before any work on documenting
 ml>> anything gets started >

 JB> too true :(

yeah... and i was right, too... folks are heading to the 'net and the
developers, too... and nothing has even come close to being as fully
documented as it should be...

 ml>> maybe i should go ahead and document what i've just proposed and
 ml>> present it to some mailer developers for feedback and
 ml>> adjustment... then to the FTSC after the necessary nodelist
 ml>> manipluation tools are in use... i see no difference in this and
 ml>> the switch to the current St. Louis format back in '85... maybe
 ml>> i'll call it the ESL nodelist format... ;-)

 ml>> then again, i dunno... whatever we come up with must be
 ml>> extensible... the above will run into a linelength problem, i'm
 ml>> sure...

 JB> I think it's be better to document line length as unlimitted
 JB> and leave it to the developers to implement it. C compilers
 JB> for instance don't have any problems with line length (thst
 JB> is, C progams can have lines of any length.)

my understanding is that they are limited (in older compilers) to 64k...
yes, we could leave it to developers to implement it but then we are also
hobbling wanna-be developers with good ideas and a mind and desire to code
for us...

 ml>> we could do a multiline format... off the top of my head,
 ml>> maybe something like this... again with the //wrappin

 JB> back in 1980 comma delimeted lists were the last word in
 JB> open data formats. these days we have better tools maybe
 JB> some osrt of structured language would be more flexible?

i dunno... it is faster and easier to grab data from know positions... as a
coder, i want my code to run as fast as possible without having to rely on
the CPU speed to make it tolerable... yes, i still code with an eye on
streamlined and i do still run code optimizers so as to be able to
streamline routines are are often used and may be slow...

 JB> -- break---

 ml>> POTS,Host,3634,Fayetteville_Net_(039),Sanford_NC,Mark_Lewis,//
 ml>> 1-919-774-5930,33600,CM,XA,V32b,V42b,H16,V32t,V34
 ml>> IP,,,,,,000-012-146-166-242,,CM,XA,ITN,IVM, IP,,,,,,,,MO,CM,XX,IBN

 ml>> POTS,Node,12,Waldo's_Place_USA,central_north_carolina_usa,//
 ml>> mark_lewis,1-919-774-5930,33600,CM,XA,V32b,V42b,H16,V32t,V34
 ml>> IP,,,bbs.wpusa.dynip.com,,,000-012-146-242,,CM,XA,ITN,IVM,IBN
 ml>> IP,,,,,,,,LO,MO,CM,XX,IBN

 JB> all those empty fields makes it hard to read, and escpcially
 JB> hard to find mistakes by eye.

just as in the current/original nodelist, its not designed for human
consumption... it is a database... a flat ASCII textfile, CSV database...
the editing program(s) know how many fields are supposed to be there
>

 ml>> fields are left empty... essentially, what we are doing is
 ml>> "overriding" those fields that are different and everything
 ml>> is built from the first entry..

 ml>> you'll notice that i'm allowing for multiple IP lines...this
 ml>> answers the FREQ flags "problem" and also allows for one to
 ml>> indicate, as i did above, that the IBN connection can't pass
 ml>> the connection off to a bbs (the MO flag)...

 JB> yeah...

 ml>> this format appears to be more extensible and easier to work
 ml>> with... for one thing, it's easy enough for a utility tool to
 ml>> build a SLF nodelist from the above...

 JB> a most important feature...

 ml>> that utility tool could be crafted to handle special situations
 ml>> like ION nets/hosts/regions in some manner that POTS nodes
 ml>> could still verify their existance (some systems won't pass
 ml>> mail unless the destination system is in their nodelist) and be
 ml>> able to route mail to(ward) them..

 JB> that way existing nodes could keep their old mailers (and
 JB> nodelist tools) and if the nodelist extraction tool is smart
 JB> enough it could extract the useful information only,

right! and we could maybe even add additional features... like internetwork
gateways? ie: ones connected to POTS and IP and willing to act as a routing
point insofar as crossing the mail from POTS to IP for POTSonly and IPonly
nodes...

 JB> People with IP capabilities could set it to extract the IP
 JB> information into a SLF nodelist id a form that their mailer
 JB> understands (IP in the phone field)  and those whose mailers
 JB> are confused by by that could set it to put unpublished there.

right...

)\/(ark