JP> With a NetComm M11F I always get 28800/REL/LAPM/V42BIS to 3:712/816,
 JP> but when I crashmailed 3:711/401 a few weeks ago, I got CONNECT
 JP> 28800/REL/MNP/V42BIS.

 IS> MNP and V42BIS together look like a bit of a worry, unless you're talking
 IS> to an old Netcomm E5/M5 or Series 3 E7/M7,

 JP> Why is that?

Oh dear .. I thought it might indicate the use of BTLZ compression over
MNP4 error-correction, which was a troublesome thing that some early
Netcomms used to do - suffice it to say that it caused lots of other modems
to throw their hands up in disgust, and fail to connect, which had
ramifications for Fidonet.

However, as it was a Microcom you connected to - they invented MNP,
remember - then that's most likely just what you got.  I think I recall
Anthony Rumble or someone saying that the Netcomms still had that
capability, but didn't try it on with modems that weren't other Netcomms
(or Microcoms) that understood - it's non-standard as far as V.42 and
V.42bis go - please don't say 'why?' :)

 IS> error-correction,

 JP> I always do. :-)

 IS> though it would pay to be sure to disallow MNP5 compression on mail
 IS> calls.

 JP> Again, why?

Because MNP5 compression goes into reverse on already-well-compressed
files, of course.  I'm sure you got here well before that was last
discussed?

Enable MNP5 inbound for any BBS callers who want it (or other sysops silly
enough to call out with it on :) and disable it for outbound calls. 
V.42bis, on the other hand, you may as well leave on - it won't hurt, and
will help some on any compressible data you might exchange, and possibly
even help on compressed files, purely because of selecting a larger frame
(block) size.

Ian

--- MaltEd 1.0.b5