TIP: Click on subject to list as thread! ANSI
echo: locsysop
to: Bill Grimsley
from: david begley
date: 1996-03-07 18:37:00
subject: V.34 spec

On Mar 06, 1996 at 09:06, Bill Grimsley of 3:640/305.9 wrote:

 PE>> You're doing it again, Bill.  Nowhere has the man said that the
 PE>> M34F violates the V.34 spec, he's even said he doesn't have a
 PE>> copy of it, and to try elsewhere for an answer to the question.
 BG>
 BG> The discussion was about whether or not NetComms are 100% ITU
 BG> V.34-compliant, and as the USR supports MORE of V.34 than the M34F, I
 BG> have my answer.

Bill, if something is "mandatory" in a spec but not implemented
in a product, then that product is not 100% *compliant* (key word);  if
something is "optional" in that same spec and not implemented,
then the product can still be 100% *compliant* even though it doesn't
support all the options.

For example, the infamous "64-state trellis coding" - s9.6.3.2
("Convolutional Encoder" - part of the trellis encoder) says that
*three* encoders are *available*:  16-state, 32-state and 64-state.  It
doesn't say that all three should be implemented.

To further add weight to the fact that 64-state trellis coding can be
considered optional is the very that that the type of coding is selectable;
 a number of times the following appears (in this case, from Table
20/V.34):

    29:30   Trellis encoder select bits:
            0 = 16 state, 1 = 32 state, 2 = 64 state, 3 = reserved for ITU.
            Receiver requires remote-end transmitter to use selected
            trellis encoder.

This is from one of those "capabilities" information data packets.

I haven't gone completely through this document that I don't really have,
but from what I have seen, there's no canonical statement about the type of
trellis coding that should be supported in order to claim V.34 compliance -
'cept of course that it's gotta be one of the three above.

I'm happy to hear alternative interpretations or pointers to where else in
here I should be looking .. it's not a clear on compliance as the ISO/IEC C
standard is.  :-(

Oh, and the 200bps auxiliary channel is guaranteed *optional* (says so
right up front).

Cheers..

    - dave
    d.begley{at}ieee.org

---
* Origin: [ epicentre of the universe -- sydney australia ] (3:711/934.4)
SEEN-BY: 711/934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.