(1)  Short note on the background to class 2.0

Strictly speaking there is no such thing as class 2.0.  A modem that
responds to the query AT+FCLASS=? with a response that includes 2.0
is actually one that conforms to the approved class 2
ANSI/TIA/EIA-592 standard which was created from the TR-29.2
SP-2388-B documents in 1992.  This standard (with certain as-yet
unapproved extensions) has also been submitted to the ITU Study Group
8 for international approval as a T.series recommendation.  This is
provisionally known as T.Class2, and may possibly be approved as
recommndation T.32, though the ITU deny this.

Unlike the plain class 2 devices, some portions of the class 2.0
command set do appear to require some understanding of the additions
to the T.30 session protocol described in chapter 5.


(2)  Short note on software inertia

The most notable example of this is the fact that it is still true in
1995 that most IBM PC software (including large portions of the most
popular operating systems) is still written as 16-bit code, despite
the fact that the Intel CPUs capable of true 32-bit operation have
been standard for many years.

(3)  Short note on transmitting optional frames

One weakness in the proposed class 2.0 implementation of these
features is that while it is possible for an answering station to set
+FPA=1,1,1 and report any relevant data, a transmitter can only set
up the frames.  There is only one way of telling whether or not an
answering station accepts these features, or whether particular frame
for a password, a subaddress or a polling selection has been sent.
This is to enable HDLC frame reporting with AT+FBU=1 (the class 2
equivalent command was +FBUG).  This is a less than satisfactory
solution, as any display will not be as an ASCII string but will be a
set of hexadecimal digits appearing backwards.  Admittedly this is
how the frame sends the data (see chapter 4) but it is still not
immediately comprehensible.

(4)  Short note on requesting procedure interrupts when AT+FIE=0

Needless to say, this combination of circumstances should not occur.
It is the responsibility of any software that wants to request a
procedure interrupt with a PRI-Q frame, a PIP or a PIN to ensure that
the AT+FIE parameter is set appropriately.

(5)  Short note on setting maximum reporting in Class 2.0

You will probably have noticed that all the examples in this chapter
set AT+FNR=1,1,1,1 to enable as much reporting as possible. This may
be a purely personal preference rooted in my experience of
programming for Class 2 modems. On the other hand, reports such as
current session parameters may turn out to be just as useful for
Class 2.0 modems, and reports of caller and answerer IDs may continue
to be needed for fax management functions such as fax log.

(6)  Short note on the packet protocol and EIA 605

The packet protocol was originally defined as a separate standard EIA
605, but is also part of the class 2.0 EIA 592 standard. The
quotation from the overview to EIA 605.  

(7)  Short note on non-standard frames

We pointed out in chapter 6 that the codes used in NSF frames are not
available as a free-for all, and software houses are not able to use
whatever they want.  Section 5.3.6.2.7 in ITU T.30 tell us that for
all NSF, NSC and NSS frames,

"when a non-standard capabilities FCF is utilised, it must be
immediately followed by ... a CCITT country code ... the procedure
for obtaining a registered CCITT code is given in Recommendation
T.35"

And ITU recommendation T.35 states

"The binary coded control procedures provide for the inclusion of
non-standard facilities in addition to the standard facilities given
in the appropriate Series-T Recommendations and require a unique code
to be allocated to each provider who includes such non-standard
facilities.  This Recommendation defines the procedure for the
allocation of CCITT defined code for non-standard facilities ... The
Director of the CCITT has the responsibility for the allocation and
management of the country codes  ... An Administration or a national
body designated by an Administration has the responsibility for the
allocation and management of the provider code ...  The procedure for
the allocation of the provider code should be defined by each
Administration or designated national body."

Implementors are warned against casual development of non-standard
facilities which disregard the terms of these recommendations, and
are encouraged to contact the ITU to find out what their local
country code is, and who the administrator of provider codes might
be.  See the disk notes for Chapter 6 for a list of country codes
currently defined.

(8)  Short note on AT+FCT

As with the class 2 AT+FPHCTO command, the TR-29.2 committee seems to
think that this default is from T.30.  If it is, I can't find it
anywhere.

(9)  Short note on AT+FHS hangup codes 

i. For transmit Phase C errors in class 2, only codes 40 and 43 were
listed.  The additional errors relate to the enhanced mismatch
checking and conversion facilities in class 2.0 and would only be
generated when <tq1> is set by the AT+FCQ command.

ii. Code 94 from the old class 2 set becomes the new code 92
(previously unused) .

(10)  Short note on RTC sequences

The following information on the composition of RTC sequences
should help with any problems.

A sequence of six one-dimensional EOL codes has the following bit
pattern :

000000000001000000000001000000000001000000000001000000000001000000000001

The representation of this using direct bit ordering is as follows :

00h 08h 80h 00h 08h 80h 00h 08h 80h

and these nine octets can be sent out as they stand.

The representation of this using reversed bit ordering is as follows:

00h 10h 01h 00h 10h 01h 00h 10h 01h

Since this sequence does contains <dle> characters it has to be sent
as the following sequence of twelve octets :

00h 10h 10h 01h 00h 10h 10h 01h 00h 10h 10h 01h

Note that the shielding is applied to the <dle> characters as they are
sent to the fax modem, not as the modem will send them over the line.

A sequence of six two-dimensional EOL codes has the following bit
pattern :

000000000001100000000000110000000000011000000000001100000000000110000000000011

Since this sequence is 78 bits long, we have to add two leading fill
bits to round off to an even number of octets.  For both bit ordering
options, the RTC is sent as a sequence of 10 octets.  The
two-dimensional RTC sent using direct bit ordering is as follows :

00h 60h 00h 0Ch 80h 01h 30h 00h 06h C0h

The same RTC using reversed bit ordering is as follows :

00h 06h 00h 30h 01h 80h 0Ch 00h 60h 03h

Note that the class 2.0 recommendation is unclear whether the +FEA
parameter is supposed to apply to incoming RTC sequences.  This is
only truly important if an incoming fax is going to be sent out again
exactly as received.  In view of the fact that 4.1.3/T.4 explicitly
states that fill is permitted only between a line of data and an EOL,
I would think the safest course would be either to check that the
final RTC sequence has no fill bits included or else to ensure that
+FEA=0 when the data is received.

(11)  Short note on AT+FDD File Diagnostic Messages used with BFT

The file diagnostic message (FDM) can optionally be used in place
of the MCF message confirmation frame during phase C of a binary file
transfer.  It is currently not at all well defined, and since a T.434
session can proceed without the need for FDM frames, they are
possibly best regarded at present as a kind of non-standard BFT frame
which can be used for implementation-specific progress messages.  In
fact, the syntax of the class 2.0 +FNS command for the generation of
non-standard frames is identical to the syntax of the +FFD command. 
Both are essentially HDLC negotiation frames composed on the fly, and
are defined very primitively as strings of hexadecimal numbers.

If +FFD is non-null, then the FDM frame will be sent instead of an
MCF whenever possible.  However, since intermediate PPS-NULL messages
are all handled transparently using ECM in class 2.0, and the
application sees nothing but data between the start and end of a
file, it is really rather difficult to see how the type of diagnostic
message could be decided on before phase C started.  The advice given
in chapter 7, to steer clear of FDM frames until the specification
stabilises and becomes more detailed, also applies to the +FFD
command in class 2.0.
