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

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

----[ Z1_ELECTION ]-------------------------------------------------
On: Thu 24 Jun 1999 23:35    (Sent: Thu 24 Jun 1999 23:38)
By: mark lewis
To: Douglas Myers
Re: Connection
St: Local Sent
--------------------------------------------------------------------
 DM>> Look at the 1:1/3xxx node numbers in the current nodelist.
 DM>> They're putting the address information in the NAME field
 DM>> to make it available :)

 ml>> it'll be much better when we can put it in the "PHONE"
 ml>> field... my system currently "dials" IP and domain names
 ml>> in the same way that it dials POTS connections... having
 ml>> to perform other tricks is a real PITA currently...

 DM>  This was probably the best compromise approach for now.  The
 DM>  nodelist still works for the current mailers, but allows for
 DM>  advanced solutions.

true to a point... i don't know of any mailer that'll dial anything other
than what's in the PHONE field... yes, many mailers have some sort of
override mechanism...

 DM>  Here's an area where the FTSC and the Coordinator structure
 DM> could work together.  Instead of taking the notion that an
 DM> FTSC document takes effect immediatly, the FTSC document
 DM> could define the nodelist we want to have, and we could start
 DM> working towards it.

unfortunately, that's not how it works... in fact, it's not even the
opposite of how it works... here's how it works (extremely basic
outline)...

1. developer comes up with "snazzy new whatsis."
2. developer implements "snazzy new whatsis" in his
"neato" program.
3. users of "neato" start using "snazzy new whatsis."
4. as the use of "snazzy new whatsis" spreads, other developers ask
   about details.
5. developer decides to document "snazzy new whatsis" in FTSC "Fido
   Standard Proposal" format.
6. other developers implement "snazzy new whatsis" in their programs.
7. after some (undefined) period of time, the FTSC decides to promote
   developer's "snazzy new whatsis" FSP to FTS because it is in
   widespread use throughout the network.

 DM> One of the proposals I heard in the conversation was to
 DM> identify an internet capability from the flags in the
 DM> nodelist, and then have the mailer either dial POTS or
 DM> Internet based on that information. This would obviously
 DM> require a new generation of mailers and couldn't be
 DM> implemented to be backwards compatible with the current
 DM> mailers.

unfortunately, that's going to be a "bit" tricky... my system
currently uses special "config settings" for the IP nodes i
contact. my feed, for instance, has both, POTS and IP capabilities as do i.
if his line in the nodelist contained both POTS and IP information, i would
have to "lock" my system into one or the other modes of
contacting him. currently, i can do both with little effort and there have
been times that i _had_ to use the POTS lines to "move the mail."

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

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

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

basically, moving the CM,MO and mailer capability flags to after the sysop
name... a ,-, field to denote modem section with same format as in use
today... a ,-, field to denote IP capability section with domain or IP
address and new IP capability flags... and a final ,-, seperator field that
would either end the line or into the user flags section...

a POTS only system would look like...

,12,Waldo's_Place_USA,Sanford_NC,Mark_Lewis,CM,XA,-,//
1-919-774-5930,V32b,V42b,H16,V32t,V34,-,,-,USDS,PITA,PIZZA

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

,12,Waldo's_Place_USA,Sanford_NC,Mark_Lewis,CM,MO,XA,-,,-,//
bbs.wpusa.dynip.com,ITN,IVM,-,USDS,PITA,PIZZA

with one empty field where the POTS stuff would be... and finally, one with
no user flags could look like...

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

with an empty field where the user flags would be...

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

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

-=%*)


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

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

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

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

)\/(ark

 # Origin: (1:3634/12)
--------------------------------------------------------------------


the only thing i think i'd change in the above is the flags stuff... i've
found a need to be able to use multiple Xx flags to denote mailer FREQ
abilities... my main mailer is an XA system but i can also do whatever
allfix's stuff would be with binkd...

then again, i dunno... whatever we come up with must be extensible... the
above will run into a linelength problem, i'm sure... we could do a
multiline format... off the top of my head, maybe something like this...
again with the //wrapping

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

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


the above being two examples... basically adding another field to the
beginning of the current nodelist lines that would denote POTS or IP and is
extensible such that one might even have something like SW2M for
ShortWave-2Meter band with a frequency in the number field... anyway,
everything up to and including the speed field is required... everything
else is flags and must be repeated due to their variable ordering... in
additional entries, duplicated fields are left empty... essentially, what
we are doing is "overriding" those fields that are different and
everything is built from the first entry...

you'll notice that i'm allowing for multiple IP lines... this answers the
FREQ flags "problem" and also allows for one to indicate, as i
did above, that the IBN connection can't pass the connection off to a bbs
(the MO flag)... it also allows for one to list several POTS numbers... the
only major thing different in subsequent POTS entries would be the phone
numbers... yes, thinking of "back in the day" multiline dialup
systems... even with IP entries, one could list seperate IP numbers if one
has them... that could even give the capability of something similar to the
currently used DNS round-robin stuff where there are several ip numbers
listed for a domain name...

this format appears to be more extensible and easier to work with... for
one thing, it's easy enough for a utility tool to build a SLF nodelist from
the above... that utility tool could be crafted to handle special
situations like ION nets/hosts/regions in some manner that POTS nodes could
still verify their existance (some systems won't pass mail unless the
destination system is in their nodelist) and be able to route mail to(ward)
them...

)\/(ark