Browse Prior Art Database

Implementation of Binary File Transfer Via Facsimile Machines

IP.com Disclosure Number: IPCOM000119800D
Original Publication Date: 1991-Mar-01
Included in the Prior Art Database: 2005-Apr-02
Document File: 2 page(s) / 80K

Publishing Venue

IBM

Related People

Cook, RL: AUTHOR [+2]

Abstract

Facsimile communications are designed primarily for the transmission and reception of images using the telephone network. Binary File Transfer (BFT) is the idea of allowing the transmission of any type of file or document between Personal Computers connected to facsimile devices. The ability to send non-image files would eliminate the need for a data modem to perform the same job.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Implementation of Binary File Transfer Via Facsimile Machines

      Facsimile communications are designed primarily for the
transmission and reception of images using the telephone network.
Binary File Transfer (BFT) is the idea of allowing the transmission
of any type of file or document between Personal Computers connected
to facsimile devices.  The ability to send non-image files would
eliminate the need for a data modem to perform the same job.

      What is disclosed here is our prototype implementation of
Binary File Transfer as defined by the EIA TR 29.1 draft proposal.
Starting with a system that implemented Group 3 communications as
defined by CCITT Recommendations T.4 and T.30, we added the
capability to send and receive non-image files following the
guidelines of the EIA TR 29.1 BFT proposal.  The initial
implementation consisted of a system that was dedicated to sending
and receiving binary files. The data required for this implementation
included four of the defined records from the BFT draft.  These
records were: 1) the filename record; 2) the permitted actions
record; 3) the contents type record; and 4) the data record.  These
records were chosen because at one time these records were identified
as the four required record types for a BFT transmission.  This may
no longer be true.  It was proposed later that no record types be
required and that all records were optional.

      The filename record takes the form:
      TAG LENGTH CONTENTS where
      TAG = 0x80 this identifies the record
      LENGTH = the number of bytes in CONTENTS less than 256
      CONTENTS = the actual name in ASCII
       For example, the filename "testfile.1st" would be sent
       as 80 0c 74 65 73 74 66 69 6c 65 2e 6c 73 74

      The permitted actions record identifies the types of actions
that can be performed upon the file being transferred.  The record is
of the same form as above where:
      TAG = 0x81
      LENGTH = 0x01 the number of bytes to follow
      CONTENTS = 8 bits identifying the permitted actions as follows:
           Bit 0 (LSB) = Read
           Bit 1 = Insert
           Bit 2 = Replace
           Bit 3 = Extend
  ...