Richard Town wrote the following to Craig Ford, and I quote (in part):

-=> Note: Copied from USR_MODEMS by WIMM/2 1.31

   CF> Don't confuse V.42 with the error control functions it defines (ie.
   CF> LAP-M, and the "alternate" protocol which is equivalent
to MNP service
   CF> levels 2-4), V.42 is predominately a scheme for negotiating error
   CF> control methods. 

 RT> V42 is _entirely_ a scheme for negotiating error control methods 

Not quite, there are control functions also incorporated.

   CF> provisions are intrinsically made to accomodate modems which support
   CF> MNP 2-4, and additional measures are included to accomodate virtually
   CF> any other scheme.

 RT> These are not "intrinsic" provisions.

Look up the definition.

   CF> If LAP-M is negotiated, the modems will also attempt to negotiate
   CF> V.42bis. If the "alternate" protocol defined by V.42 is
negotiated,
   CF> V.42bis can also be negotiated on top of it (Microcom has published
   CF> procedures for accomplishing this), but it is rarely implemented.

 RT> There is nothing in V42 which would or should command the then
 RT> CCITT recommended compression method (V42bis) to be switched off. 

If error control is not sucessfully negotiated, V.42bis cannot be negotiated.

 RT> V42bis is not "on top of" anything.

It rides on top of an error control layer.

 RT> V42bis is entirely seperate from V42. It's not "can" also be 
 RT> negotiated either.  It _must_ be available for negotiation.

Ther is no MUST to it.

 RT> As to being "rarely implimented", both V42/LAP-M and V42/MNP-2-3 
 RT> or -4 are commonplace. MNP-2 or -3  or -10 may be commanded in 
 RT> place of -4 as the EC.

MNP10 is totally proprietary, it is not covered except by passing private
parameters (which are provided for).

 RT> Using V42bis as compression too. MNP-4 _must_ be available for 
 RT> compliance. V42bis _must_ be available for compliance as well...

Nope.

Regards....

Craig
aka: cford{at}ix.netcom.com

--- timEd/2 1.10+