(1)  Short note on 2400 bps handshaking

The T.30 recommendation permits the use of the V.27 ter 2400 bps
modulation scheme in order to achieve this.  A fax machine which is
capable of using 2400 bps instead of 300 bps for negotiation
indicates this by setting bit 25 of the DIS or DTC facsimile
information field to 1, while a transmitter intending to use 2400 bps
for negotiations sets bit 25 of its DCS to 1.

A parallel modification to the T.30 protocol is that while the 300
bps preamble (used at the start of each session and on each line
turnaround) consists of 1 second 15% of flag sequences, the 2400 bps
preamble is different, and consists of the long training sequence
with echo protection defined in the V.27 ter specification. While
this ought to be a technical detail that concerns only hardware
engineers, it is worth noting that as the 2400 training sequence
lasts for 1148 milliseconds, there may be a slight loss of
performance from using this for both the initial preamble and those
needed each time the line turns around.

Phase A is also modified when a fax has 2400 bps negotiating
capability.  An answering fax with 2400 bps negotiating capability is
allowed to cycle through phase A, after starting off with its CED
tone, by alternating the sending of its initial identification
sequence at the usual speed of 300 bps with the same sequence sent at
the higher speed of 2400 bps on each occasion that it attempts to
establish a link.

Conversely, a caller with 2400 bps capability transmits a CNG tone
and then listens first for an ID sequence at 300 bps and then at 2400
bps before repeating the CNG.  It is obviously better if we can avoid
having to exchange the initial NSF, CSI and DIS answering sequence
and the corresponding NSS, TSI and DCS frames at 300 bps, but there
is no way of forcing the establishment of a 2400 bps negotiating link
without compromising the ability to talk to a machine at the usual
speed of 300 bps.

Whatever happens, the use of bit 25 for agreeing a common negotiating
speed is something that can always be used as a fallback in the case
of two machines that have missed a 2400 bps initial ID and have
started 300 bps negotiations instead.  While virtually all fax
machines are capable of 2400 bps communications, it is actually quite
rare to see one that implements the option to use this speed for
negotiating session parameters and exchanging commands and responses
in phases B and D.  The reason for this is that the benefits of this
option are outweighed by the disadvantages.  It is generally not
worth the effort that goes into making it work.  To see the sorts of
time savings that this option offers, consider the sample dump of the
HDLC frames used for a single page fax message.

Ŀ
CSI ff 03 40 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
DIS ff 13 80 00 00 0e c8 00                                             
TSI ff 03 43 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
DCS ff 13 83 00 06 48                                                   
CFR ff 13 84                                                            
MPS ff 13 4f                                                            
MCF ff 13 8c                                                            
DCN ff 13 fb                                                            


These 8 frames consist of 72 octets, to which we have to add 4 octets
per frame for the FCS and opening and closing flags, giving a total
of 108 octets or 864 bits.  At 300 bps, this represents an overhead
of almost 2.9 seconds.  Negotiating at a speed of 2400 bits per
second reduces this overhead to under 0.4 seconds, resulting in a
saving of around 2.5 seconds on the transmission time.

The major saving in time - which is under three seconds anyway - can
only be realised at the start of a session, as 60 of the 72 octets
occur in the initial phase B exchange.  However, there is an even
chance that the high rate won't be used at this point as the 300 bps
carrier may well be the one that is recognised first.  Once a session
is under way, a typical exchange such as a phase D MPS-MCF uses only
14 octets or 112 bits.  Sending the data involved takes 46 ms at 2400
bps, and 373 ms at 300 bps.  This saving of under a third of a second
in a page that takes around 30 seconds to send is not really
significant.  The clinching argument against this option is that
using 300 bps for handshaking is far more reliable than using 2400
bps, and there is consequently much less chance of the messages being
corrupted.  So the only reason for using 2400 bps for T.30
negotiating is to save a little bit of time, which can generally be
no more than two seconds at the start of a fax and half a second
between pages.  Compromising the integrity of the whole session for
the sake of a little time that often doesn't even show up in a
telephone bill is a false economy.  As we pointed out at the
beginning of this chapter, it would not be true to say that all ITU
recommendations are made on the basis of technical merit, and the
fact that an option exists in the T.30 recommendation isn't always a
good reason for implementing it.

It has been said that the 2400 bps option was added to the T.30
recommendation on the insistence of the French delegation to the ITU,
who had originally developed it and reckoned it would give them a
competitive edge over the Americans and Japanese.  This story may be
apocryphal, but is corroborated to some extent by the reported use of
2400 bps handshaking on French-manufactured fax machines.

(2)  Extended note on ECM and the ISO reference model

We have already observed that are some areas where the separation
of the fax standards into the two recommendations T.4 and T.30
appears to be somewhat arbitrary.  Nowhere is this more true than in
the way that the optional error correction mode (ECM) has been
added.  The details of the implementation are split into two parts,
with one half appearing as Annex A to Recommendation T.4 and the other
half appearing as Annex A to Recommendation T.30.  My own view is
that dividing the specification for error corrected fax into two
parts doesn't make a lot of sense, especially when the two
recommendations seem to disagree on particular points.  In particular,
I defy anyone who isn't familiar with the original version of T.30 to
make sense of Annex A to T.4. The distinction between those portions
of ECM which appear in T.4 and those which are part of T.30 will not
be adhered to in this chapter.

This doesn't mean to say that there is no sensible way of dividing up
the various parts of the facsimile process.  It just means that
separating the various elements involved and grouping them back
together on the basis of what standards document happens to define
their workings doesn't lead to greater clarity.  However, there is a
standard way of describing the various parts of any communication
process, and we'll use it to examine fax in a different context
altogether.

The ISO reference model

It seems that no book about any sort of computer communications
technology is complete these days without an account of the ISO
Reference Model for Open Systems Interconnection.  This
conceptualises communications as being subdivided into a number of
different layers.  While peer layers (the term for those on the same
level) see themselves as communicating with each other, what really
happens in any communication session is that messages get passed down
to progressively lower levels.  It is only at the bottom level that
there is some physically connection between two communicating
entities.

There are a number of slightly differing outlines of the sorts of
things to which each of these seven layers ought to applied.  Readers
especially interested in this subject should look at one of the
numerous textbooks that attempt comprehensive coverage, as the very
short account given here is given simply to allow facsimile
communications to be looked at in the light of the ISO model.

Most authorities are in broad agreement that the lowest three levels
are the ones that vary with the type of connection or network.  The
Physical layer is the lowest, and includes items such as cable
characteristics like EIA-RS232C, and modem modulation schemes such as
V.17. The Data Link layer includes basic framing, error correction
and formatting protocols such as standard asynchronous byte-oriented
and bit-oriented HDLC communications (you may recall this actually
stands for High-level Data Link Control). The Network layer covers
addressing, routing, call set-up and clearing.

The Transport layer aims to insulate the higher levels from any
knowledge of what the lower levels may be doing.  For instance,
whether the physical layer is a fibre-optic cable or a wet string has
ramifications for the way that the Data Link and Network layers
operate, but should make no difference to the higher levels.  One of
the tasks of the Transport layer is to ensure that this independence
of the higher and lower levels is assured.  It is also common for the
Transport layer to handle end-to-end flow control and error handling
for items such as frames which are in themselves correct but may be
inappropriately addressed or arrive out of sequence.  The highest
three layers are the ones that offer the most scope for variations
between systems and implementations.  The Session layer ensures
synchronization between two communicating entities, making sure that
messages and data passing between them are valid for any particular
context.  The Presentation layer concerns itself with the syntax of
the data passing between them, and is responsible for things like
encryption and data compression and decompression, and any other
things needed to ensure that each can process the other's
information.  The Application layer is responsible for interacting
with the user.

The seven layers in the ISO Reference Model are usually portrayed
diagrammatically as follows.

Ŀ            Ŀ
Application            Application
            
Ŀ          Ŀ
Presentation          Presentation
          
Ŀ                    Ŀ
Session                    Session
                    
                                 
Ŀ                Ŀ
Transport                Transport
                
                                 
Ŀ                    Ŀ
Network                    Network
                    
Ŀ                Ŀ
Data Link                Data Link
                
Ŀ                  Ŀ
PhysicalĴPhysical
                  


It is a common exercise for computer science students to be asked to
apply this model to various real-world communications situations.  It
is equally common for all concerned in such exercises to conclude
that, with the exception of computer networks specifically designed
to conform with the ISO model, there isn't usually a clear and
unambiguous correspondence between the model and the identifiable
levels of any example that might be chosen.  While this is also true
of fax protocols, it is still a useful exercise for fax modem
programmers struggling make some sense of all the different parts of
the EIA and ITU standards to attempt to fit sending or receiving a
fax into the ISO model.

The modem firmware clearly takes responsibility for the Physical layer
as it handles all the modulation schemes.  It also implements the
Data Link layer in its handling of all HDLC framing and checking as
well as synchronous to asynchronous conversions.  Lastly, the Network
layer is always handles by a modem when it dials the telephone number
and detects the fax or modem at the other end, and also when it clears
the call and hangs up the phone.  All the three lower levels of the
ISO Reference model are therefore taken care of entirely by the fax
modem and (with a few minor exceptions) anyone writing applications
software doesn't need to concern themselves any further with them.

We have seen that the Transport layer aims to insulate the higher
levels of the ISO model from the need to know what is happening at
the lower levels.  The EIA TR.29 committee recommendations discussed
in chapters 6-9 offer fax software a consistent method of talking
with the fax modem no matter what modulation scheme is being used,
what fax is being dialled and what type of data is being exchanged. 
Therefore the command set used by fax modem firmware is one of the
clearest examples of a Transport layer function that one could wish
for.

It is equally apparent that the T.30 recommendation defines a protocol
for the Session layer, as it is almost entirely concerned with the
sequencing of the events that are necessary for a fax to be sent or
received.  For simplicity we pass over the use of HDLC as the
underlying data link protocol, even though the definition of the HDLC
FCF octets to be used is as much a part of T.30 as anything else - as
noted previously, it is rare to find something that the ISO model
fits perfectly.  If an EIA Class 1 fax modem is used, then the
Session layer and the T.30 protocol are included at a low level in
the application software.  If an EIA Class 2 fax modem is used, then
the T.30 protocol and the session layer are almost entirely the
responsibility of the modem firmware.  Whatever the class of modem
that is being used, the coding of T.4 compliant data is handled by
applications software and is clearly a function of the Presentation
layer, as it ensures that two faxes can understand each others data.

As well as handling portions of the Presentation layer, the
applications software also operates at the level of the Application
layer, as it is responsible for obtaining from the user the location
of a document to be faxed and the phone number to which it will be
sent.

The obvious place for the optional facsimile error correcting mode in
an ISO compliant universe is as part of the T.30 session level
protocol.  This is because whether ECM is used or not, a fax file is
always encoded according to the normal T.4 procedures.  It can be
encoded used any available option, including either normal or fine
resolution, one-dimensional or two-dimensional coding, and any
recognised page dimensions.  Sending faxes with error correction is
performed by dividing the T.4 data up and sending the portions in
discrete chunks along with error checking.  By definition this means
that the error correction mode operates on the level below the one
that generates the data it deals with.

The utility of regarding T.30 as part of the session level is most
obvious when the five phases it defines for a fax session are seen as
the type of synchronization points between two communicating entities
that any session level protocol needs to maintain.  Adherence to the
rules ensures that gross errors like sending fax data to a calling
station when it hasn't requested polling don't occur.

(3)  Short note on packet sizes

It is true of all error correcting schemes that shorter packets
are more efficient under adverse conditions, while longer packets
perform better under good conditions.

(4)  Short note on frame sequence octets, for pedants

Notice that automatic bit stuffing means that frame number 126, which
has the same 01111110 bit pattern as an HDLC flag, would be sent with
bit stuffing as nine bits. This zero bit insertion is also applied to
the data in the frame, which means that neither the actual length of
the frame nor the time it takes to be sent can be specified with
certainty. This phenomenon is something that is the concern of the
data link layer responsible for the HDLC frame composition, and is
transparent as far as the error correcting protocol is concerned.

(5)  Short note on worst-case need for flow control in ECM

Let us assume that the transmitter has sent a PPS-MPS and is waiting
for an MCF frame. The receiver has the data, but shouldn't really
confirm receipt of the page until it has been printed. After all, the
page might be received by an unattended fax machine about to run out
of paper in the middle of night. So the receiver has to print out the
data before sending a confirmation. The problem now is that assuming
the default line printing time of 20 ms, a full A4 page takes
something over 22 seconds to print, and the standard T.30 timeouts
would result in the transmitter disconnecting after 9 seconds and
three unsuccessful attempts at sending the phase D command frame.

(6)  Short note on SUB

An equally appropriate use would be with a PABX having multiple
fax machines on its extensions. It would be fairly easy to engineer a
small router able to inspect the SUB frame in an incoming fax and
forward the initial identification frames to the required destination
before switching the remainder of call directly through to a fax
machine on an extension. However, I don't know of anyone who has
either built or is marketing such a device. Its development is
unlikely given recent developments in other areas of
telecommunications, notably direct dialling inwards (DDI or DID),
which can provide the same functionality for calling fax machines
which implement only the basic 24-bit DCS frame.

(7)  Extended note on DTM

A summary of DTM and the codes it uses can be found in Annex C to the
3/93 and any subsequent version of ITU T.4.  This specification is
actually quite badly worded, and reads a little like a bad
translation. Please bear in mind my earlier statement that it hasn't
been possible to verify the workings of any of these non-fax transfer
modes.  For instance, one reference to the file description for DTM
in T.4/C.5.2 indicates that the first line begins with a CR FF
sequence rather than a CR LF sequence.  Another reference in note 3
to the same section just as clearly indicates that the first line,
like all the others, begins with a CR LF pair.  Other parts of the
T.4 recommendation refer to the CR FF sequence as being a "page
initiator", so there is really no way of telling which interpretation
is correct.  It is certainly true that two items of software which
the same interpretation will be able to use DTM successfully, and
also any item of software that ignores the character following the CR
will work under either interpretation.  However, the balance of
probability is that whatever interpretation is a typographical error
and no matter which is really correct, someone somewhere will one day
implement the feature basing their code on a misprint.

The most basic file description for DTM is follows :

Either

Ŀ
 CR FF 6.1 :ADDITIONAL INFORMATION:         
 CR LF 1   :FILE NAME:                      
 CR LF        [up to 72 character file name]
 CR LF                                      
 CR LF                                      


or alternatively -

Ŀ
 CR LF 6.1 :ADDITIONAL INFORMATION:         
 CR LF 1   :FILE NAME:                      
 CR LF        [up to 72 character file name]
 CR LF                                      
 CR LF                                      


This is a clearly a minimum implementation, with many more fields
being both possible and desirable.  The field number 6.1 with which
the description begins is in fact a sort of magic number serving to
define the description as applying to a data file received via the
fax DTM mechanism.  A little more detail on the thinking behind this
can be found in ITU Recommendation F.551, which outlines file transfer
procedures for group 3 and group 4 fax, Teletex, and all ITU message
handling services.

The additional optional fields also precede lines of up to 72
characters each, with the exception of field 10, which is always
followed by 8 lines of up to 72 characters each.  Readers should note
that the textual labels of these field are supposed to be
self-documenting, and the is no further guidance given as to their
suggested content.

Ŀ
 CR LF 2 :APPLICATION REFERENCE:            
 CR LF       [up to 72 characters]          
 CR LF 3 :TYPE:                             
 CR LF       [up to 72 characters]          
 CR LF 4 :ENVIRONMENT:                      
 CR LF       [up to 72 characters]          
 CR LF 4.1 :MACHINE:                        
 CR LF       [up to 72 characters]          
 CR LF 4.2 :OPERATING SYSTEM:               
 CR LF       [up to 72 characters]          
 CR LF 4.3 :PROGRAM:                        
 CR LF       [up to 72 characters]          
 CR LF 4.4 :CHARACTER SET:                  
 CR LF       [up to 72 characters]          
 CR LF 5 :LAST REVISION:                    
 CR LF       [up to 72 characters]          
 CR LF 6 :LENGTH:                           
 CR LF       [up to 72 characters]          
 CR LF 7 :PATH:                             
 CR LF       [up to 72 characters]          
 CR LF 8 :RESERVED:                         
 CR LF       [up to 72 characters]          
 CR LF 9 :AUTHOR'S NAME:                    
 CR LF       [up to 72 characters]          
 CR LF 10 :USER VISIBLE STRING:             
 CR LF       [line 1 up to 72 characters]   
 CR LF       [line 2 up to 72 characters]   
 CR LF       [line 3 up to 72 characters]   
 CR LF       [line 4 up to 72 characters]   
 CR LF       [line 5 up to 72 characters]   
 CR LF       [line 6 up to 72 characters]   
 CR LF       [line 7 up to 72 characters]   
 CR LF       [line 8 up to 72 characters]   
 CR LF 11 :FUTURE FILE LENGTH:              
 CR LF       [up to 72 characters]          
 CR LF 12 :STRUCTURE:                       
 CR LF       [up to 72 characters]          
 CR LF 13 :PERMITTED ACTIONS:               
 CR LF       [up to 72 characters]          
 CR LF 14 :LEGAL QUALIFICATIONS:            
 CR LF       [up to 72 characters]          
 CR LF 15 :CREATION:                        
 CR LF       [up to 72 characters]          
 CR LF 16 :LAST READ ACCESS:                
 CR LF       [up to 72 characters]          
 CR LF 17 :IDENTITY OF LAST MODIFIER:       
 CR LF       [up to 72 characters]          
 CR LF 18 :IDENTITY OF LAST READER:         
 CR LF       [up to 72 characters]          
 CR LF 19 :RECIPIENT:                       
 CR LF       [up to 72 characters]          
 CR LF 20 :TFT VERSION:                     
 CR LF       [up to 72 characters]          
 CR LF 21 :COMPRESSED:                      
 CR LF       [up to 72 characters]          


Because the DTM file description is basically an ASCII header, it is
suitable for user processing as well as automatic handling.  Given
the fact that the file description is easily readable ASCII text
which includes both numeric field IDs and ID descriptors, a
non-technical human reader could easily read a DTM file description
and have a fair idea of what ought to be done with the file that has
just arrived.

The only implementation of DTM that I know of occurs in the EIA Class
2 implementation present on the National Semiconductor TyIn PC Fax
board.  It has a minimal header formatted as follows :

Ŀ
CR LF   :ADDITIONAL INFORMATION:            
CR LF   :FILE NAME:                         
CR LF   [file name] (72 characters maximum) 
CR LF                                       
CR LF                                       
CR LF                                       


Note that there is no initial CR FF page initiator code, that numeric
prefixes for each field are omitted, and that an extra CR LF pair
precedes the file content.

(8)  Extended note on BFT

Possibly the main problem with BFT is the fact that the ITU decided
to align the standard with similar ones in the OSI (Open Systems
Interconnection) network world.  A file transferred via BFT becomes
what in OSI terms is called an abstract object.  The universe of OSI
abstract objects is infinitely large, and in order to work out
exactly what an object really is, it must be described in a sort of
code called ASN.1. This stands for Abstract Syntax Notation Number
One, and is specified in ITU recommendation X.208, with the ASN.1
encoding rules described in X.209.  If you want to refer back to the
OSI seven-layer Reference Model, ASN.1 is defined as part of layer 6,
the Presentation Layer, and is also used directly by the Application
layer.  Trying to implement a protocol from a description of the
ASN.1 fields is like trying to learn a computer language solely from
a description written in BNF (Backus-Naur Format).  In other words,
it can't be done by normal mortals.  However, there seems to be more
interest in BFT than in any of the other data file transfer portions
of T.30. Possibly this is due to the fact that BFT capability has for
a long time now been defined as an option in the EIA service class 2
documents.  Despite this, no class 2 modems with true BFT capability
have (to my knowledge) ever been manufactured for sale.  I would be
inclined to regard that as an endorsement by modem manufacturers of
the view presented earlier ; there is little point in spending time
and money implementing BFT protocols in a fax modem when the file
transfer can be handled quicker and more easily using the data
communications facilities in the same device.

Despite this, the limited information given here ought to be enough to
help anyone work out what a particular ASN.1 header received over a
BFT connection means, and in particular, how the filename and the
file length can be extracted.  However, a textbook with more
information on ASN.1 than we give here ought to be consulted if you
want to write mission-critical BFT software.  Like other complex
standards that aren't widely implemented, it is very easy to get
something wrong, and we mentioned earlier that there is no simple way
to test an implementation of any of the T.30 data file capabilities
against a known benchmark.  We'll see shortly that the only software
implementations of BFT that I've come across have different
interpretations of the specification.  Both are also different to the
way that I would interpret T.434.

The description that follows does not use exactly the same terminology
as the relevant ITU documents.  The reason for this is that the
wording and the grammar of the relevant specifications are unusually
dense.  For example, section 25.3 of X.209 states that

"Where an application specification defines an abstract syntax type as
a set of presentation data values, each of which is a value of some
specifically named ASN.1 type, usually (but not necessarily) a choice
type, then the object identifier value specified in $25.2 may be used
with the abstract syntax name to identify that transfer syntax which
results from the application of the encoding rules specified in this
Recommendation to the specifically named ASN.1 type used in defining
the abstract syntax."

This sentence is quite unintelligible on first reading.  Adhering to
the terminology of the original will probably result in a more
accurate but less accessible account of the binary file transfer.
Since this whole section is essentially an introduction intended to
give the reader an idea of what data file handling in fax modes is
like, I've made accessibility and intelligibility more of a priority
than duplicating the vocabulary of the original.  Even so, I would
recommend that the notes that follow be read in conjunction with the
worked example in section 0.

              Short introduction to ASN.1 as used in BFT

In the same way that a DTM file description has fields, an OSI
abstract object has attributes.  A BFT file contains many attributes
which have a direct correspondence with similarly named fields in a
DTM header.  However, there are two major differences.  The first is
that while in DTM the header precedes the actual file, BFT regards
the contents of the file as being one of the attributes of an object.

The same sort of field identifier that DTM conveys in a whole line,
using both a numeric code and a colon delimited text string, can take
up just 8 bits when coded as a BFT attribute identifier.  However,
the basic encoding rules of ASN.1 are not intuitive and do need some
explanation.  

An attribute when encoded under ASN.1 rules has at least three
parts.  The attribute identifier is the first part, the attribute
length is the second, and the attribute contents themselves are the
third.  However, the length can be indefinite, in which case a fourth
part, to mark the end of the attribute contents, can be added.  This
optional end-of- contents marker (which we don't use in our examples)
consists of two zero bytes and when present is tagged on to the end
of the attribute contents.  The whole encoding looks as follows :


Ŀ
Attribute Identifier OctetLengthContentstwo optional NULL bytes



                         Attribute Identifier


The attribute identifier is strictly speaking an octet, as it
consists of three bit fields.  The two most significant bits contain
the class of the attribute, the third bit indicates its structure,
and the five least significant bits contain a numeric code.  This
final code (which can range from 0 to 31) contains a tag value for
either an attribute number or a contents type.  The figure below
shows the way the attribute identifier is built up, together with the
meaning of the bitfields.


Ŀ
Class              Structure    contents type/attribute number
Ĵ
00 Universal       0 Primitive  00001  1  Boolean             
01 Application     1 Constructed00010  2  Integer             
10 Context specificĴ00011  3  Bit string          
11 Private                      00100  4  Octet string        
             00101  5  Null                
                                  10000  16 Sequences           
                                  10001  17 Sets                
                                  10010  18 Numeric string      
                                  10011  19 Printable string    
                                  10110  22 ASCII (IA5) string  
                                  10111  23 Universal Time      
                                  11000  24 Generalized Time    
                                  11001  25 GraphicString       
                                   BFT-specific file attributes 
                                   (0-31 - see table below)     
                                  


Though the bit indicating the structure of the attribute isn't the
first, it is the most sensible one to start with.  A primitive
attribute is one where whose contents directly contain the attribute
value.  However, a constructed attribute is one where the contents
contains other attributes.  This means that the type of a constructed
attribute must be either a sequence or a set of other attributes.  
The difference between a sequence and a set is that as sequence is an
ordered collection while a set is an unordered collection.

Turning now to the class, if it is specified as universal then the
attribute is one that should be recognized by every ASN.1 decoder. 
The attributes defined in the table above all apply when the classs
is universal.  For instance, an attribute identifier of 00000010 is
always recognized as an integer.  This isn't so if the class isn't
universal.  If the class of an attribute is application-specific,
then the attribute number contained in the last 5 bits has a meaning
specific to that application.  A different application could use the
same attribute with a different meaning.  Similarly, if the class is
context-specific then this defines an attribute whose meaning depends
on the constructed type in which it occurs.  For example, a BFT
filename is an attribute that only has meaning in the context of a
file transfer.  Finally, a private attribute has meaning only to the
user who defined it.

The attributes defined by the BFT recommendation T.434 are all
specific to BFT, which is itself defined as being a sequence of
attributes together comprising application number 23.  A sequence of
attributes is of course itself a constructed attribute, which means
that the attributes defined in T.434 are all context-specific.  There
is no reason why BFT should be defined as application sequence 23 ;
this is a case of a magic number, just like the definition of the DTM
header as complex attribute 6.1.  The fact that all the attributes
are context-specific means that their tags contained in the least
significant five bits of the identifier convey the type of the tag
implicitly - in other words, the type doesn't have to be spelt out in
the ASN.1 encoding as it is already part of the context-specific
definition.

The only explicit tags that an BFT ASN.1 decoder should come across
are those which are needed to specify the members of sequences. 
Since the only sequences defined are sequences of GraphicStrings, the
only explicit tags that should ever be met is the tag for
GraphicString, which is universal tag 25.  However, for the sake of
completeness, a number of other universal tags were also given in the
above table.

The various types of strings can be confusing and the differences are
more technical than practical.  The simplest is an octet string,
which can contain any 8-bit value, whose individual meanings are
essentially arbitrary.  The meanings of the individual bits in a
bitstring are also undefined.  On the other hand, the bytes
comprising an ASCII string (international alphabet no. 5) have a
fixed meaning, as ASCII strings contains valid bytes from the 7-bit
ASCII code.  The set characters possible in a GraphicString is fewer
that those that occur in ASCII, as the type specifically excludes
control codes and deletes.  A printable string is restricted even
further, with many of the non-alphanumeric characters such as braces
and asterisks disallowed.  For full information, readers should refer
to recommendations X.208 and T.61.  You won't go far wrong if you
consider all strings to be restricted to valid printable 7-bit
alphanumeric characters (except, obviously, for type 18, which can
only contain numbers).

The first attribute in a BFT object is the defining one for the
object as a whole : it serves to identify what follows as being a
complete sequence of attributes belonging to application type 23. The
attribute identifier is made up as follows :


Ŀ
      01              1           10111          
Application ClassConstructedApplication number 23



and the resulting octet has the hexadecimal value 77 and the decimal
value 119.  Arguably, this attribute could be left out of PSTN BFT
transfers on the grounds that it can be assumed from the external
context, but this is something that I wouldn't recommend at all.


                                Length


The length of the attribute follows the identification byte.  This
should be a number equivalent to the total number of bytes in the
attribute contents.  There is an obvious problem in a straightforward
use of a single byte to hold the length, as it would restrict the
maximum length of an attribute to 255.  However, if the length is to
be encoded using multiple bytes, we need a mechanism for indicating
when the length ends and the actual contents begin.  The hexadecimal
sequence 01h,23h, which represents the decimal value 291, could
otherwise be taken to indicate a length of only 1 with the contents
being whatever the type of the attribute interpreted the value 23 as
being.  For example, an integer would make the contents the number
35, a bitstring would make the contents the bit sequence 00100011 and
an ASCII string would make the contents the # character.

The solution to this problem adopted by ASN.1 is quite
straightforward.  If the length of the contents is less than 128,
then the length can be coded as a single byte.  This is known as the
short form of the length.  However, if the contents are more than
128, then the length must be coded using a long form.  The most
significant bit of the first byte is set, with the remaining bits
holding the number of additional length bytes with the most
significant digits first. (This is what is known as big-endian, or
Motorola, format).  So a length of 291 could be coded as the three
byte sequence 82h,01h,23h with no ambiguity.

Note that the long form of the length can be used for values less
than 128.  This may be an inefficient waste of space, but can make
the writing of an ASN.1 encoder simpler as no decision on which
representation to use needs to be taken in cases (such as a filesize)
where a length could be greater than 127, but might not be.  A long
form of the length can also be padded out ; the sequence 84h,
00h,00h,00h,01h could be used to encode a length of 1 as 4 bytes.

A length byte of exactly 128, or 80h 10000000 binary, is a special
case, which we referred to earlier.  It indicates that the attribute
contents have an indefinite length and that the end of contents is
marked by two consecutive 0 bytes.  Clearly, the use of the
indefinite form of the length is restricted to plain text files.  The
default for BFT is that the file transferred is unstructured binary.
While this could be altered by explicitly including the document-type
attribute in the BFT encoding, there isn't a lot of point in doing
this and it can't be recommended.

There is a slight modification made to this scheme in the case of
bitstrings.  The first of the contents octets is used to hold the
number of unused bits in the final octet of the bitstring.  For
example, the encoding of a T.4 EOL code as a bitstring could look
like this :


03 03 = universal primitive bitstring, 3 bytes
   04 00 16 = 00000100 = first byte is the number of unused bits in last octet
              00000000 = first real contents octet
              00010000 = second and last contents octet


Of course, a value of 31 (00011111) for the last octet would yield
exactly the same bitstring, as the last four bits are ignored.


                         Types defined in BFT


Up to 31 different type tags can be identified using a five-bit code.
These will always be numbered from 0 to 30, and a value of 31 is
reserved for extensions, and indicates that the number defined by the
following octets contains the type tag.  This provision caters for
applications that require more than 31 attributes.  However, BFT
doesn't require this extension as it defines the full set of the 31
allowable context-specific attributes as follows :


Ŀ
TAGNAME                                        TYPE                           
Ĵ
23 BINARY-DATA-Message                         sequence of sequences          
                                                                              
0  filename                                    sequence of GraphicStrings     
1  permitted-actions                           bitstring                      
2  contents-type                               defaults to UNSTRUCTURED BINARY
3  storage-account                             GraphicString                  
4  data-and-time-of-creation                   GeneralizedTime                
5  data-and-time-of-last-modification          GeneralizedTime                
6  data-and-time-of-last-read-access           GeneralizedTime                
7  data-and-time-of-last-attribute-modificationGeneralizedTime                
8  identity-of-creator                         GraphicString                  
9  identity-of-last-modifier                   GraphicString                  
10 identity-of-last-reader                     GraphicString                  
11 identity-of-last-attribute-modifier         GraphicString                  
12 file-availability                           currently undefined            
13 filesize                                    integer                        
14 future-filesize                             integer                        
15 access-control                              constructed                    
16 legal-qualifications                        GraphicString                  
17 private-use                                 constructed                    
18 structure                                   object identifier              
19 application-reference                       sequence of GraphicStrings     
20 machine                                     sequence of GraphicStrings     
21 operating-system                            object identifier              
22 recipient                                   sequence of GraphicStrings     
23 character-set                               object identifier              
24 compression                                 sequence of GraphicStrings     
25 environment                                 sequence of GraphicStrings     
26 pathname                                    sequence of GraphicStrings     
27 unused                                                                     
28 protocol-version                            bitstring - defaults to 1      
29 user-visible-string                         sequence of GraphicStrings     
30 data-file-content                           EXTERNAL                       



All the above attributes are optional.  The types of the attributes
are defined implicitly as part of the BFT specification.  Most of
them are GraphicString types (7-bit ASCII without delete or control
codes). Notable exceptions are as follows :

All the above attributes are optional.  The types of the attributes
are defined implicitly as part of the BFT specification.  Most of
them are GraphicString types (7-bit ASCII without delete or control
codes).  Notable exceptions are are follows :

i. The date and time fields (4,5,6,7), which are strings of a
specified form such YYMMDDhhmmss ; so noon on January 1st 1995 would
usually be coded as "950101120000".  The differences between
Generalized and Universal time types are technical, and the initial
YYMMDDhhmmss coding is common to all types of time.

ii. The filesize fields (13,14) are integers.

iii. Attributes 1,2,15,17, and 28 are attributes that are too
complicated to outline here ; interested readers should refer to
T.434.  The same consideration applies to attributes 18,21,23 which
are defined as object identifiers.  An object identifier is an
attribute whose contents are an ordered list of subidentifiers, each
of which is formatted in the same way as the length ; that is, all
but the last byte have the most significant bit set to 1.  Interested
readers may find more enlightenment in X.209.

iv. Attributes 0,19,20,24,25,26,29 are defined as being sequences of
strings.  In other words, a series of GraphicString primitives ought
to follows with the total length of all the attributes in the
sequence (including lengths and identifiers as well as contents)
appearing in the length part of this attribute.

v. Attribute 30 (the file contents) are defined as having only an
EXTERNAL meaning.  While an EXTERNAL type can be defined using ASN.1,
the interpretation here is that the meaning of the contents is
something that is subject to a different set of rules.

A minimal BFT object (along the lines of a minimal DTM transfer)
should include the filename and the file contents.  These are the
first and the last of the above attributes.  Both these attributes
are context-specific (since they only have meaning within a BFT
structure).

                           Implementing BFT

Given the fact that T.434 is still a relatively new standard, it's
worth looking at what one commercial implementation of BFT does with
a short two-line text file call TMP.TXT which looks like this :

This is the document content!  End

The program in question is Winfax Pro 4 from Delrina Inc.  (Thanks are
due to Hans (aka Johann) Deutinger for e-mailing me a dump of a
Delrina BFT session and putting me in touch with their technical
people.) A hex dump of the data sent is as follows :

00:  77 84 00 00 00 82 bc 04 03 02 07 80 a0 0e 19 0c   w...............
10:  54 4d 50 2e 54 58 54 00 00 00 00 00 a4 0c 18 0a   TMP.TXT.........
20:  39 34 30 36 32 30 31 35 31 34 b1 16 19 14 44 45   9406201514....DE
30:  4c 52 49 4e 41 20 57 49 4e 46 41 58 20 34 2e 30   LRINA WINFAX 4.0
40:  30 00 b8 16 19 14 75 6e 63 6f 6d 70 72 65 73 73   0.....uncompress
50:  65 64 00 00 00 00 00 00 00 00 9e 84 00 00 00 24   ed.............$
60:  54 68 69 73 20 69 73 20 74 68 65 20 64 6f 63 75   This is the docu
70:  6d 65 6e 74 20 63 6f 6e 74 65 6e 74 21 0d 0a 45   ment content!..E
80:  6e 64 0d 0a                                       nd..

The ASN.1 coding was debugged by hand as follows :


77 84 00 00 00 82                                       BFT ID
   bc 04                                                protocol ID
      03 02                                             2-byte bitstring
        07                                              7 unused bits
        80                                              binary 1
   a0 0e                                                filename
      19 0c                                             12-byte string
         54 4d 50 2e 54 58 54 00 00 00 00 00            TMP.TXT
   a4 0c                                                timestamp
      18 0a                                             10-byte time
         39 34 30 36 32 30 31 35 31 34                  94 06 20 15 14
   b1 16                                                manufacturer ID
      19 14                                             20-byte string
         44 45 4c 52 49 4e 41 20 57 49 4e 46 41 58 ..   DELRINA WINFAX
      .. 20 34 2e 30 30 00                              4.00
   b8 16                                                compression
      19 14                                             20-byte string
         75 6e 63 6f 6d 70 72 65 73 73 65 64 ..         uncompressed
      .. 00 00 00 00 00 00 00 00
   9e 84 00 00 00 24                                    file contents
      54 68 69 73 20 69 73 20 74 68 65 20 64 6f 63 75 ..
      .. 6d 65 6e 74 20 63 6f 6e 74 65 6e 74 21 0d 0a ..
      .. 45 6e 64 0d 0a


An annotated version of the above runs as follows :


77  = 01 1 10111 = application constructed tag 23 = BFT session
84  = long four byte length = 00 00 00 82 = 130 bytes
      BFT = IMPLICIT sequence of (the following) sequence
                {
                protocol-version
                other optional attributes
                }

bc  = 10 1 11100 = context specific constructed tag 28 = protocol-version
04  = length 4 bytes
      protocol-version = IMPLICIT bit string

    03 = 00 0 00011 = universal primitive type 3 = bitstring
    02 = length 2 bytes
    contents = 07 = unused bits in last byte
               80 = 1xxxxxxx = binary 1

    This field is supposed to be an IMPLICIT bitfield with the
    value 0.  Instead it is encoded as being constructed.

    The content of 0 is supposed to be the version number-1,
    with T.434 09/92 being version 1, hence a default of 0.

    I would have coded this as 9c,07,00.

a0  = 10 1 00000 = context specific constructed tag 0 = filename
0e  = length 14 bytes
      filename = IMPLICIT sequence of GraphicString

    19 = 00 0 11001 = universal primitive type 25 = GraphicString
    0c = length = 12 bytes
    contents = 54 4d 50 2e 54 58 54 00 00 00 00 00
             = TMP.TXT padded out with zeros

a4  = 10 1 00100 = context specific constructed tag 4 = date-and-time-of-creation
0c  = length 12 bytes
      date-and-time-of-creation= IMPLICIT GeneralizedTime

    18 = 00 0 11000 = universal primitive type 24 = GeneralizedTime
    0a = length 10 bytes
    contents = 39 34 30 36 32 30 31 35 31 34 = 9406201514 (YYMMDDHHMM)
             = 15:14 hrs 20th June 1994

    This field is supposed to be an IMPLICIT GeneralizedTime.
    Instead it is coded as if it were constructed, e.g.  as a sequence
    of GeneralizedTime.

b1  = 10 1 10001 = context specific constructed tag 17 = Private-Use-Attribute
16  = length 22 bytes
      Private-Use-Attribute = externally defined sequence of

    19 = 00 0 11001 = universal primitive type 25 = GraphicString
    14 = length = 20 bytes
    contents = 44 45 4c 52 49 4e 41 20 57 49 4e 46 41 58 20 34 2e 30 30 00
             = "DELRINA WINFAX 4.00" padded with one zero

b8  = 10 1 11000 = context specific constructed tag 24 = compression
16  = length 22 bytes
      compression = IMPLICIT sequence of GraphicString

    19 = 00 0 11001 = universal primitive type 25 = GraphicString
    14 = length = 20 bytes
    contents = 75 6e 63 6f 6d 70 72 65 73 73 65 64 00 00 00 00 00 00 00 00
             = "uncompressed" padded with 8 zeros

9e  10 0 11110 = context specified primitive tag 30 = file contents
84  = long four byte length 00 00 00 24 = length = 36 bytes
    file contents = externally defined

    contents = 54 68 69 73 20 69 73 20 74 68 65 20 64 6f 63 75
               6d 65 6e 74 20 63 6f 6e 74 65 6e 74 21 0d 0a 45
               6e 64 0d 0a

             = "This is the document content!<cr><lf>End<cr>LF>"

It must be stressed that this is only one possible interpretation of
what is a fairly complex specification, for which the official
documentation gives no examples.  As a matter of fact, there may well
be certain problems with this encoding. The main one seems to be that
the IMPLICIT typing of all attributes in BFT is ignored.  All
attributes are defined as constructed, no matter how the attribute is
defined.  I'm fairly sure that typing all implicitly defined BFT tags
as constructed is incorrect.  The type of an implicit tag should be
the same as the type of the base tag and should not need to be
specified.

This affects the following fields, which the Delrina implementation
defines as constructed, but which T.434 defines using the IMPLICIT
keyword as follows :

1.  Protocol-Version ::=   IMPLICIT bit string
{version-1(0)}

 protocol-version  [28] Protocol-Version
DEFAULT {version-1}

2. GeneralizedTime ::=          [UNIVERSAL 24]
IMPLICIT IA5String

 date-and-time-of-creation [4] IMPLICIT
GeneralizedTime


The ASN.1 references showing the proper coding for these tags states
the following :

"Implicit tagging indicates that .... the explicit identification of
the tag of the 'Type' in the 'Tagged Type' is not needed during
transfer" (X.208/26.9) "If the 'IMPLICIT' keyword was used in the
definition of the type, then ... the encoding shall be constructed if
the base encoding is constructed and shall be primitive otherwise"
(X.209/20.3a)

There are three examples in X.209/20.3 for encoding the value "Jones".
The first is a primitive type, the second is an application-wide
tagged type (like date-and-time-of- creation in T.434) and the third
is a tag derived from another tag (like protocol- version in T.434).
Because the base encoding for all of them is primitive, all the ASN.1
coding is primitive too.

The examples in X.209 are as follows :

Type1 ::=VisibleString   ->
1ah,05h,4ah,6fh,6eh,65h,73h

Type2 ::=[Application3] IMPLICIT Type1 ->
43h,05h,4ah,6fh,6eh,65h,73h

Type5 ::=[2] IMPLICIT Type2         ->
82h,05h,4ah,6fh,6eh,65h,73h


The Delrina coding of both protocol-version and
date-and-time-of-creation as constructed types is, on this
interpretation, probably incorrect. Though their interpretation of
the date-and-time field would seem to be supported by T.434/5.5,
which says that the time 8201020700 can be encoded as 18h 08h 38h 32h
30h 31h 30h 32h 30h 37h 30h 30h, I'd be inclined to treat this as a
piece of sloppy ITU documentation.  In general, where T.434 clashes
with X.208/X.209, it is likely to be the BFT recommendation that
should be disregarded. T.434 doesn't make it clear that, just as
GeneralizedTime doesn't need to spell out that it's an IA5String, so
also date-and-time-of-creation doesn't need to spell out that it's a
GeneralizedTime.  The sloppy documentation theory is backed up by the
fact the in the above example, T.434 gets the length of the field
wrong.  (The date-and-time field is 10 bytes long, not 8).

A second possible problem is that the T.434 definition of the protocol
version just quoted seems to indicate that version 1 of BFT should be
encoded as 0 (version-1).  If this is correct, the Delrina encoding
of single bit with a value of 1 is probably wrong.  Arguably, T.434
could be seen as stating that the 9/92 version is version 0, in which
case the encoding should be 9c,01,00,ff rather than 9c,01,07,80.  as
described above.

It is worth asking if differing interpretations matter.  The answer
must be that if connections between similar applications are
unaffected, it probably doesn't.  It also probably doesn't matter if
the interpretation of the ASN.1 specification allows for
flexibility.  However, the above examples show that BFT is not that
straightforward to implement.

The differences between two interpretations may be small but can also
be significant.  As I pointed out earlier, checking against a known
version of the specification is generally impossible.  The confusion
is compounded by the fact that two software packages, A and B, which
each adopted differing interpretations would be able to exchange
files between packages but not across them.  A would talk with A, B
would talk with B, but A and B would be unable to communicate.  The
situation gets even worse if a third package C comes along which can
cope with either interpretation.  It isn't difficult to do this once
you realise that conflicting views exist.  A and B would both be able
to talk with C but not with each other.   It is this sort of
maddening complication that tend to drive users potty, with two
differing manufacturers each claiming the other is at fault, while a
third tries to use the confusion as a way of increasing market share.

Delrina have recently published their implementation of T.434. Apart
from a short header consisting of the 5 bytes 00h,14h,83h,32h,00h
(which are stored in the disk file but not transmitted), all their
BFT transmissions contain the same 96 byte ASN.1 header, with the
file name and file size in identical positions to those in the
example above.  Regrettably, I couldn't get permission to reproduce
their BFT document here.  As it was produced in co-operation with an
informal group called the BFT Conformance Committee which meets at
the same time as the TR-29 committee, it is quite likely to become
something of a standard, whether it is formally correct or not.

                        BFT ECM considerations

We should assume that the restrictions prohibiting EOR signals apply
to BFT just as they do to other data file transfers.  For some reason
the BFT documentation omits the instructions given for the other file
transfer modes regarding the transmitter having either to send a CTC
and drop to a lower modem speed, or else abort the transfer by
sending a DCN frame and disconnecting.

The rules that were given for BTM, DTM and EDT transfers regarding the
concatenation of multiple files in one session clearly don't apply to
BFT, since the protocol contains its own means of including more than
one separate file in a single transfer.  All that is required for
files subsequent to the first one is that they are sent with a
separate file name attribute, a separate file size attribute, and a
separate data file contents attribute.  A BFT transfer can span
multiple ECM pages, or multiple files can be included in one block. 
T.30 recommends that one binary file per ECM page is the preferred
format.

The BFT sender can issue a PPS post-message command at any time, and
the receiver can optionally respond with a diagnostic message.  After
this exchange the file transfer continues with the next page, which
begins with the next unsent octet.  In other words, a PPS command is
not an abort but an enquiry.

                       File Diagnostic Messages

According to Annex B.1 to T.30, the File Diagnostic Message (FDM) is
described in Recommendation T.434.  This doesn't appear to be correct
as the term is nowhere mentioned in T.434, which is exclusively
concerned with the format of a BFT transmission and not with any
responses.  However, T.30 does tell use that there are three types of
FDM.

Informative messages don't require recovery and don't affect the state
of the session.

Transient messages are error messages and require recovery - at the
very least, a portion of the block must be retransmitted.

Permanent messages are also error messages, but indicate that recovery
is not possible, that any retransmission will simply generate the
same error, and that the BFT should be cancelled.  The sender should
continue as if four PPRs have been received and send a CTC command.

Diagnostic messages can be sent instead of MCF frames, and they all
have FCFs of X0111111.  Unlike MCFs, a diagnostic message can span
multiple frames.  More information on BFT diagnostics appears to be
missing.  In particular, any information regarding the contents of
FDMs is missing, and there seems no way of distinguishing the three
types of message.  It seems unlikely that the designers of the BFT
intended features such as this to be specific to particular
implementations, so in the absence of further details, I would
suggest that FDM frames should not be used.  Existing MCF and DCN
frames should be used respectively to continue or abort sessions by
BFT receivers, while BFT transmitters should ignore all diagnostic
messages when the meaning is unknown. I did locate an old unapproved
draft of the T.30 which included an Annex B.2 which covered BFT
diagnostic messages in a little more detail.  I'm not sure of the
status of this Annex, as it was certainly omitted from the latest
(03/93) version of T.30.  Possibly Annex B.2 was omitted in error. 
Possible it was omitted deliberately and was due for inclusion in the
next version of T.434.  And possible it was withdrawn and I'm wrong
to resurrect it.  Therefore, its provisions are recounted here for
information only ; I would not say that the specification is adequate
for unambiguous interpretation and use.

In fact, the description of FDM frames is fairly skeletal.  No
examples are given of their construction, or how the frame is
structured in detail.  In principle, we are told that file diagnostic
messages have FIFs with three distinct portions :

1. An error type coded as one of the following values (as described
earlier) :

Ŀ
0informative
1transient  
2permanent  


2. "An error identifier categorising errors in terms of concepts
defined in the virtual filestore definition or in terms of ITU
recommendation X.200."

3. "Optionally, a text message in natural language giving further
details of the cause of the error"

The means by which the type, identifier and message are included in
the frame is not made clear.  Whether the type is coded as a
bitfield, or a binary number, or as a series of ASCII digits is
unclear.  The same applies to the identifier.  The text message is
defined as being of type GraphicString, but the format is unclear. 
It seems clear that the FDM is structured according to ASN.1 rules,
but the ASN.1 definitions are nowhere spelled out.

The following table shows the unapproved list from T.30/Annex B.2
giving all the possible error messages with their type and unique
identifiers.  Some errors appear to be able to take a choice of
types.  I find some of these options a little odd.  For example,
error 5029, caused by "local failure - filespace exhausted" seems to
be equivalent to a disk full error.  How this error can be considered
non-fatal under any circumstances escapes me, yet it is listed as
being either informative, transient or permanent.

BFT Diagnostic Messages

Ŀ
Type  IdentifierReason                                  
Ĵ
1 2 0           no reason                               
0 1 2 1         responder error (unspecific)            
1 2   2         system shutdown                         
0 1 2 3         BFT management problem (unspecific)     
0   2 4         BFT management bad account              
0   2 5         BFT management security not passed      
0     6         delay may be encountered                
0 1 2 7         initiator error (unspecific)            
0 1 2 8         subsequent error                        
0 1 2 9         temporal insufficiency of resources     
1 2   10        access request violates VFS security    
1 2   11        access request violates locale security 
Ĵ
  2   1000      conflicting parameter values            
  2   1001      unsupported parameter values            
  2   1002      mandatory parameter not set             
  2   1003      unsupported parameter                   
  2   1004      duplicated parameter                    
  2   1005      illegal parameter type                  
  2   1006      unsupported parameter type              
  2   1007      BFT protocol error (unspecific)         
  2   1008      BFT protocol error procedure error      
  2   1009      BFT protocol error functional unit error
  2   1010      BFT protocol error corruption error     
  2   1011      lower layer failure                     
1 2   1013      timeout                                 
1 2   1014      system shutdown                         
Ĵ
0 2   2007      bad account                             
  2   2020      invalid filestore password              
Ĵ
  1 2 3000      filename not found                      
    2 3002      initial attributes not possible         
    2 3003      bad attribute name                      
  1 2 3004      non-existent file                       
  1 2 3005      file already exists                     
  1 2 3006      file cannot be created                  
  1 2 3012      file busy                               
  1 2 3013      file not available                      
0     3017      filename truncated                      
0     3018      initial attributes altered              
  1 2 3019      bad account                             
  1 2 3024      ambiguous file specification            
    2 3027      bad attribute value                     
Ĵ
0 1 2 4000      attribute non-existent                  
  1 2 4003      attribute not supported                 
    2 4004      bad attribute name                      
    2 4005      bad attribute value                     
0     4006      attribute partially supported           
Ĵ
    2 5014      bad data element type                   
  1 2 5015      operation not available                 
  1 2 5016      operation not supported                 
0   2 5017      operation inconsistent                  
  1 2 5026      bad write (unspecific)                  
  1 2 5027      bad read (unspecific)                   
0 1 2 5028      local failure (unspecific)              
0 1 2 5029      local failure - filespace exhausted     
0 1 2 5030      local failure - data corrupted          
0 1 2 5031      local failure - device failure          
    2 5032      future filesize exceeded                
0     5034      future filesize increased               


(9)  Short note on the character set used in character mode

The character set to be used is specified as being based on the
Latin Alphabet No.  5 of ISO 8859-1 with the addition of a number of
box drawing characters from ISO 72.  However, the characters are
coded using the rules laid out in CCITT/ITU-T recommendation T.51.

(10)  Short note on the box-drawing character in character mode

The double-line box characters are actually shown in T.51 as being
bold-line box characters, but emboldened box characters are seldom
found on computer equipment.  We have therefore opted for double-line
box characters instead.  In view of the fact that the character modes
lend themselves to adaptation for computer use this adaptation is in
my view quite sensible.

(11)  Short note on the top margin of a fax in mixed mode

This is stated to be six blank character lines, but it is apparent
that the arithmetic doesn't work out here. The guaranteed
reproducible area for a fax is shown as starting 4 mm from the top of
the page in I.3/T.4, which somehow becomes 130 scan lines in D.9/T.4,
which in turn becomes 6 character lines in E.8.2/T.4. I'm only
repeating what the specification says; T.4 isn't ever ashamed of
inconsistency.  Another instance of this inconsistency is where
E.8.3/T.4 states that the total number of scan lines per page in
mixed mode should not exceed 1024, and that the no character slice
should exceed 64 lines.  Why a page consisting of one single
character slice in mixed mode should allow 64 lines per page when the
character mode format is fixed at 55 lines per page is never made
clear.

No doubt the true capabilities of mixed mode fax machines will become
clearer as and when they begin to appear.
