DD> YMMV if you use a shim kludge.

 ml> hunh? what shim kludge are you speaking of? my 
 ml> mailer uses a FOSSIL to 
 ml> contact and converse with remote systems and hardware... 

 PK> The shim kludge of software specifically set up to handle IP
 PK> addresses extracted from a Phone no. field...

 ml> hunh?? sorry but frontdoor doesn't require a shim 
 ml> kludge to draw the IP number from the contact number 
 ml> field in the nodelist... 

 PK> Whatever the software is that translates the Nodelist Phone entry
 PK> field into an IP address is the "shim or kludge" that is being
 PK> discussed. Its irrelevant if that S/W is FD or something else, but
 PK> something is translating it from one meaning (a PSTN Phone number)
 PK> into another (an IP address). THAT is the "shim or kludge".

nothing is translating anything WRT this on my system... the only thing
that is done is that 000- is stripped... other than that, my system
operated based on the existance (or lack thereof) of 000- and/or the ITN
flag...

it is all due to the basic configuration... my POTS nodes are configured to
specifically HOLD mail for systems that fly IP flags whereas my IP nodes
are configured to only contact systems that fly the ITN or IVM flags... 

 ml> it never has since the feature/capability was introduced... in 
 ml> fact, at the time that it was introduced, it was perfectly within 
 ml> developing and existing practise ;)

 PK> I suspect what you are saying is that FD handles the data recored
 PK> in the Nodelist Phone number field in a manner that allows it to be
 PK> interpreted as an IP address, which means that FD itself IS the
 PK> "shim or kludge". 

no, what was actually done was that limiting code was removed so that
anything in the "contact number" field was valid... in other
words, there was, once upon a time, specific code in place that validated
the entry in that field... that code was simply removed...

 PK> So in reality it all comes down to identifying what is meant by "a
 PK> shim kludge"..........;-)

that might be an impossibility...

 ml> well, i happen to know that DD was trying to go after 
 ml> the use of the SIO/vmodem package written for OS/2 
 ml> systems by the creator of x00, ray gwinn...

 PK> Which is also a form of shim or kludge, taking a modem "Dial
 PK> String" and interpreting that as an IP address (does Vmodem do DNS
 PK> lookups???). 

yet, no one stops to think that it is nothing but a FOSSIL driver and that
the mailer only talks to the FOSSIL driver...

 ml> my system just happens to have the capability of doing something 
 ml> that your's doesn't... 

 PK> Which is no loss to me because I have no need of doing
 PK> that.......;-) 

hehehe... O:)

 PK> I actually think that nicely describes a "shim" or
"kludge". Your
 PK> software is making something designed for one thing think its
 PK> something else so that it can use it...

no, actually, it is my configuration that does that and my configuration is
based on the flags flown and the "country code"...

 ml> hunh? so you are saying that the FOSSIL stuff developed 
 ml> by fidonet and its developers is a kludge? 

 PK> No. I am saying that the original FOSSIL simply passes DATA from A
 PK> (the CPU) to B (a serial port) without a need to "translate" the
 PK> meaning of that data into something else. 

BINGO!! however, in this case, B is not a serial port... so what? that
doesn't make it a shim or a kludge... hell, some years back, i actually
built an infrared unit that i used to transfer data over short lineofsight
distances... my original design was highly proprietary and then i got the
bright idea of simply using the serial signals and transmitting the raw
data via my device... for the most part it worked great... when i quit
messing with it, i had wrapped the serial traffic within a validation
sequence in much the same way that the binkp folk ended up doing since
TCP/IP wasn't as fault tolerant as had been presumed... 

 PK> The fact that SOME FOSSIL implementations (Vmodem notably) need to 
 PK> do something else other than talk to a serial port, which means 
 PK> that is it ADDING to the original task of the FOSSIL (Fido Opus 
 PK> Seadog Serial Interface Layer) by talking to the TCP/IP stack, 
 PK> which is most definately NOT a Serial port.

and that negates or changes the FOSSIL portion of the setup?? no one has
ever said or written in the specs that FOSSIL drivers /had/ to talk to
serial port devices, have they? seems that someone is trying to introduce
something in to evidence that is not available...

 ml> somehow i think they'd all highly disagree with you on that 
 ml> without failure...

 PK> Well I think it would take a fairly brave person to try and sell
 PK> the TCP/IP stack as "just another form of serial port"........;-)

hahaha, why would someone want to do that? that would not be any different
than trying to see shortwave/ham radio as just another form of FM ;)

 PK> But all this coems down to what is meant by "shim" and/or
 PK> "kludge"... 

 ml> almost :)

 PK> You forgot to add "surely" after "almost"........;-)

possibly, yes... maybe i did ;)

)\/(ark