Hi Stephen,

     About "SBBS/W32 Kermit SABOTAGE" of November 16:

SH> ...I'm wondering...
MS> Stop wondering...  http://public.sogetel.net/bicephale/MSK.INI
SH> ...I added a link to the kermit docs as shipped with Synchronet.
MS> This economy of words tells a lot about your so called "honesty"...
MS> Remember `Kermit.INI v1.5' of October 17?...  ...still unchanged...
SH> That will be there forever.  It's CVS.  Are we done with this now?

     How convenient...  I'm supposed to believe you have no control over
the content of your Hard-Disks and there's no way to erase any *TRASH*?!

                                  %-o

SH> ...breaking "kermit" because the interface is somehow
"weak".    [?]
MS} Wrong...  ...his decision made him responsible for disabling some of
MS} the `Kermit' features...  I also informed him that hanged sessions
MS} fail to be detected...  ...message-pointer UpDating may be wrong...
MS} ...users are at risk to be kept out of an `SBBS' system for a day.
MS> This matter of a weak external protocol-driver interface only makes
MS> things worst as he won't even try to address it but `Kermit' was
MS> made crippled because of "fluff" he has rejected...
MP> If goofing up the setup could result in these things, they sound
MP> like good reasons not to risk setting up Kermit at all.
MS} That's why i refer to Rob Swindell's `Kermit.INI' as SABOTAGE!
MS> The `MS-Kermit.EXE' external file-transfer protocol-driver isn't 
MS> involved...  This `SBBS' issue is out of my hands...
SD> I can't seem to make sense out of this statement...

     It's no surprize, one must be somewhat biased to distort statements
like you did but i may have detected a sign of hope later in your reply.

SD> SBBS must retain control of the socket...  Sockets have no concept
SD> of a carrier...  ...Honest, that's how TCP works...

     A "Socket"!?  What "Socket"?  There's just no
"Socket" when drivers
are considered from a ~FOSSIL~ environment perspective!...  Guess again.

SD> If the problem is in fact a carrier hang, the problem is with the
SD> FOSSIL driver not the kermit setup.

     I can agree on something, at last!  `MS-Kermit.EXE' isn't involved,
just lets not take for granted ~FOSSIL~ layer problems alone can explain
why the "CARRIER" signal hangs, though.  You appear to get the point:  i
simply stated that the hanged "CARRIER" problem occurs at Rob's SoftWare
level...  In other words, the external protocol drivers (`MS-Kermit.EXE'
included) only react to the (simulated) "CARRIER" condition accordingly.

     If you take a look at `Kermit.INI v1.3' of October 12 you'll find a
real-life application illustrating what i refer to:  "Set Port Fossil 1"
combined to "Set Carrier On", so far so good!  It happens that `MSK.INI'
of November 16 also has the very same settings, but with a nuance in the
implementation sequence and the comments...  Rob doesn't set the port to
~FOSSIL~ early, i do;  we both "Set Carrier On", nonetheless.  Rob has a
side-line note saying "Recover from HangUps IMMEDIATELY" but notice that
there's a significant difference in my comment as mine says "Immediately
recover from hangups if well supported in the BBS program", to be exact.
                     ^^
SD) These same unspecified results...
               ^^^^^^^^^^^
     Hummm...  As if i never wrote a word!  Well, i notice you discarded
the part which i re-inserted in a quote above (lines eighteen to twenty-
one, inclusively)!!!  Some special people who can't stop themselves from
banging on the walls will appreciate the following distraction, i guess.

                                  ;->

     Rob's comment is "misleading" at best if one reads in `Kermit.INI':
"Set Flow None", followed by "No flow control (this is
handled by TCP)"!
                                                                  ^^^
                                  8^o

     As far as external file-transfer protocol-drivers are concerned, it
has nothing to do with Flow-Control done at other levels:  if a SysOp is
using `COM/IP' and it's set for ~RTS~/~CTS~ Flow-Control then the advice
i'd find appropriate would be to revise the .INI and set it accordingly.

     This is why `MSK.INI' says "Seems OKay for this particular use":  i
never got an opportunity to put `MSK.INI' to test when i submitted it to
the attention of Rob Swindell on July, 2003, to say the least - he seems
to think he's omnipotent enough to decide what qualifies as "Ready-Made"
before tests are over but i don't (i'm only an ordinary user after all)!

     The comment in Rob's `Kermit.INI' is valid only when `MS-Kermit' is
communicating with a DOS InterNet interface, like `Waterloo-TCP' packet-
drivers, a Novell ~ODI~ setup, etc., and which would mean using INTERNAL
~TelNet~ support.  There's no reference to speed or, euh...  ~TCP~/~IP~,
euh...  because the port is set to ~FOSSIL~.  Isn't that simple enough?!

     Now, back to "unspecified" stuff, after this educative interlude...

                                  %-b,

SD> More on this later...  ...given that a largeish number of Synchronet
SD> BBSs run a largeish number of FOSSIL doors regularily...

     Oups, your time is over!...  You've got fifteen months to check it.

                                                           Salutations,

                                                           Michel Samson
                                                           a/s Bicephale


... Rob's SBBS/Kermit:  spend spare-time just to probe weak interfacing!
--- MultiMail/MS-DOS v0.45 - Who votes for UNIVERSAL TelNet OLMR BBSing?