IPP Mail Archive: IPP> Mapping Between IPP and IFAX

IPP Mail Archive: IPP> Mapping Between IPP and IFAX

IPP> Mapping Between IPP and IFAX

Ron Bergman (rbergma@dpc.com)
Wed, 26 Aug 1998 08:39:20 -0700 (Pacific Daylight Time)

Attached is the presentation from the IPP meeting last Thursday in
Toronto. I have included some revisions to reflect the comments provided
in the meeting. Carl-Uno plans to discuss this item with the IFax group
at the IETF meeting this week in Chicago.

This work is still very incomplete and comments from both IPP and IFax
participants are welcome. Also, this reflects only a portion of the
mapping effort that I have identified.

1. Scenarios - A brief discussion is included.

2. Addresing - TBD

3. Job Processing Parameters - Partially included. I have only
reviewed RFC 1314 and RFC 2306. (A quick review of RFC 2301 did not
reveal any additional tags that were applicable to IPP.)

4. Notifications - TBD

5. Capabilities Discovery - TBD

6. Printer Discovery - Will not be covered, not a part of IPP.

Ron Bergman
Dataproducts Corp.

MAPPING BETWEEN IPP AND IFAX - PRESENTATION

1. SCENARIOS

This document provides detailed mapping information for parameter
conversion between the Internet Printing Protocol (IPP) and Internet
Facsimile (IFAX). Although there are many possible conversion scenarios
that could benefit from this mapping, they can be logically categorized
into two groups.

1.1 IFAX document enbedded within IPP.

In this category, a facsimile document is transmitted on a network, which
may be the Internet or an Intranet, to an IPP server where it is then
transferred to the requested output device.

The facsimile document may be created by any one of several different
type devices, such as a legacy fax machine or a computer with fax
generation software. The electronic document created may also be
transferred to the device which provides the transport service by any
possible means. Some possibilities include telephone, network, direct
attachment, or the transport software document generator may reside on
the same system. In all scenarios, the mapping to create the IPP
document is independent of the method of generation and transmission of
the fax to the IPP transport software.

Upon receiving the facsimile within IPP, there are several possible
methods for the IPP server to process the result. This includes sending
the document to a fax machine via a telephone link, sending the document
to an Internet Fax offramp via a network connection, or sending the
document to a printer with the capability to process a TIFF
encoded document.

In summary, the mapping procedure only concerns the sending transport
software module and the receiving IPP server. The method of creating the
original facsimile, transmission of the facsimile to the transport
software, and disposition of the document received by the IPP server is
beyond the scope of this document.

1.2 IPP/fax Conversion.

This scenario is practical only in the situation where either the
transmitting or the receiving side can only process and/or print a
facsimile document and the opposite side can only process IPP. The IPP
to Ifax or Ifax to IPP conversion may be performed at any point in the
transmission link. There are many factors which may dictate the point of
the conversion and these factors are beyond the scope of this document.

1.3 Some examples:

1.3.1 An IPP client creates a print file and sends the file over the
internet to a remote IPP server. This server determines that the
destination is a fax machine, so the file is converted to a TIFF fax
format and transmitted over a local phone line to the device.

1.3.2 A fax machine, that communicates with an internal fax server,
sends a document to the server that is destined for an IPP printer. The
fax server has the ability to convert a fax format to IPP and transmits
the converted document to the IPP printer over the network.

1.3.3 AN IPP client creates a print file and determines that the
destination site is a fax without any internet access. The client
software has access to a local IPP server that has IPP to Ifax conversion
software. The converted file is then transferred to the destination over
a phone line.

The mapping of TIFF, currently defined in this document, is based upon
RFC 1314 and RFC 2306. Although both of these documents claim to define
the version of TIFF currently used for fax, there any many discrepancies
between the two specifications. In general the information in RFC 2306
has been used when a conflict existed. However, RFC 1314 does define
seven Tag types that do not appear in RFC 3206, and these have been
considered in the mapping to IPP. It is assumed that these Tag types
were not included in RFC 2306 because they are not commonly supported in
fax implementations. They have been included for those very few
implementations that may have provided the support and can be ignored by
all the rest.

2. MAPPING

2.1 PRINT RESOLUTION:

The IPP Job Template Attribute "printer-resolution" defines the
resolution to be used for the print job. The attribute contains three
parts as follows:

SIGNED-INTEGER (32-bits) The first part defines the number of
addressable marking positions across the direction of feed, per units
of measure. This attribute is similar to the object
prtMarkerAddressabilityXFeedDir from the Printer MIB.

SIGNED-INTEGER (32-bits) The second part defines the number of
addressable marking positions in the direction of feed, per units of
measure. This attribute is similar to the object
prtMarkerAddressabilityFeedDir from the Printer MIB.

SIGNED-BYTE (8-bits) The last part defines the units of measure for
the previous two values. The defined enumerations are 3 (for dots per
inch) and 4 (for dots per centimeter).

The IFAX TIFF specification defines three separate Tag types with similar
definitions as in the three parts of the IPP attribute:

XResolution (Tag = 0x011A) The value field contains two 32-bit integers
which are the numerator and denominator of a fraction that represents
the resolution in the X direction, in pixels per ResolutionUnit.

YResolution (Tag = 0x011B) The value field contains two 32-bit integers
which are the numerator and denominator of a fraction that represents
the resolution in the Y direction, in pixels per ResolutionUnit.

ResolutionUnit (Tag = 0x128) The value field contains a 16-bit integer
which is an enumeration that defines the units used to specify the
resolution. The value 2 defines inches and the value 3 defines
centimeters.

Conversion Notes: The resolution parameters for IFAX specify the X and Y
directions of the resulting output in a portrait orientation. Whereas,
the IPP attribute defines the resolutions relative to the form as it
passes through the marker unit, which may be either long-edge or
short-edge feed. If the output device is an IPP printer rather than a
fax machine, the resolutions required are not symmetrical. In this case
the mapping can only be performed if the IFAX X and Y directions can be
defined relative to the feed direction as defined by IPP.

2.2 COMPRESSION

The IPP Operation Attribute "compression" defines the algorithm used for
compressed document data. The keywords currently defined for
"compression" do not support the IFAX compression methods. The following
new keywords will be required for IPP/IFAX mapping.

modified-huffman (1-dimensional Modified Huffman)
modified-read (2-dimensional Modified RelativeElementAddressDesignate)
modified-modified-read (2-dimensional Modified Modified READ)

The IFAX TIFF specification requires two of the following three Tag types
to be present to define the compression
encoding used.

Compression (Tag = 0x0103) The value field is a 16-bit enumeration that
defines the compression method used. Valid values are 3 (Modified
Huffman or Modified READ) and 4 (Modified Modified READ).

T4Options (Tag = 0x0124) The value field is a 32-bit integer containing
flag bits which must be included if the "Compression" Tag value is
equal to 3. Bit 0 of the integer is the least significant bit.

Bit 0 defines which compression method is actually used. 0 indicates
Modified Huffman and 1 indicates Modified READ.
Bit 1 must be zero to indicate compression is used.
Bit 2 is set if fill bits have been added to keep EOLs byte aligned.

T6Options (Tag = 0x0125) The value field is a 32-bit integer containing
flag bits which must be included if the "Compression" Tag value is
equal to 4. Bit 0 of the integer is the least significant bit.

Bit 0 must be zero to indicate Modified Modified READ compression.
Bit 1 must be zero to indicate compression is used.

2.3 PAGE COUNTS

The IPP Job Description Attribute "job-impressions" defines the total
number of impressions required for the print job and the Job Description
Attribute "job-impressions-completed" defines the total number of
impressions currently completed for the job.

The IFAX TIFF specification defines a Tag type PageNumber (Tag = 0x0129)
that contains two 16-bit values. The first value defines the number of
the current page and the second defines the total number of pages. The
first page number is zero and the last page number equals the total
number of pages minus one.

Conversion Notes: For a Fax document, each page consists of one
impression or one media sheet side.

2.4 DOCUMENT NAME

The IPP Operation Attribute "document-name" is equivalent to the IFAX
TIFF optional Tag type DocumentName (Tag = 0x010D).

2.5 USER NAME

The IPP Job Description Attribute "job-originating-user-name" is
considered to be equivalent to the IFAX TIFF optional Tag type Artist
(Tag = 0x013B).

2.6 DOCUMENT FORMAT

For an IFAX document transmitted within IPP, the IPP Operation Attribute
"document-format" shall contain the IFAX MIME Content-Type: image/tiff;
application=faxbw.