[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
INTERNET DRAFT                                          Richard Shockey
November 12, 1998                                       Shockey Consulting LLC
Expires April 1999
draft-shockey-ipp2ifax-01.txt


The Use of the Internet Print Protocol [IPP] as a
Facsimile Service [FAX]


STATUS OF THIS MEMO

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups.  Note that other groups may also
distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time.  It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."

To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe),
unnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).

Copyright Notice

Copyright (C) The Internet Society (1998).  All Rights Reserved.

ABSTRACT

This memorandum discusses the use of the Internet Print Protocol
[IPP] as a facsimile service. IPP has most of the functional
attributes necessary to be a successful real time facsimile
service on the Internet with little or no modification to the
core IPP V 1.0 protocols [IPP-MOD] [IPP-PRO].

IPP compliance with the legal and general custom and practice
surrounding General Switched Telephone Network [FAX] will require
some modification to the behavior of IPP clients and the common
usage of time/date stamping on local IPP device transactions and logs.





SHOCKEY                 Expires April 1999              [Page  1]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998


1.0 INTRODUCTION

Facsimile [FAX] has a long and successful tradition as a
telephony application for sending a document from one
client/terminal device to another. At a sufficient level of
abstraction, the concept of FAX could be considered a "remote
printing" technology. Therefore, it is worth reviewing the
various aspects of what work has been done to date to define
service objectives for facsimile over IP networks and
specifically identify those elements of IPP that match those
needs.

2.0 OVERVIEW OF FACSIMILE SERVICES

2.1 TRADITIONAL FAX

Traditional facsimile as defined by the ITU [T.30] is a
connection oriented technology between two client/terminal
devices over the GSTN (Global Switched Telephone Network). It is
specifically a "point to point" service where the end point is an
address defined by an ITU [E.164] telephone number. The content
types specified by T.30 are highly restricted due to the lack of
available bandwidth available on the analog GSTN, typically
limited to 14.4Kpbs, but standards do exist to support up to
28.8Kpbs.

2.2 IETF FAX SERVICE

For Information on IETF-FAX work group:

http://www.imc.org/ietf-fax

The Internet Fax service [IFAX][RFC 2305] has developed within
the IETF as using SMTP. With SMTP there are two functional
elements, a Message Transfer Agent (MTA) and a Message User Agent
(MUA). The MTA's and MUA's are operating in a Client-Server /
Store and Forward.

IFAX adds significant functionality to facsimile services by
integrating with other SMTP services, such as the Voice Profile
for Internet Mail [VPIM2], in a concept often referred to as
"Universal Messaging". [RFC 2301] introduces several advanced
content types, including higher resolution Black & White and
several types of color files that, for practical reasons, would
be impossible to transmit over the GSTN. Current work within the
IETF-FAX work group [EIFAX] defines some essential features for


SHOCKEY                 Expires April 1999              [Page  2]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998


reporting and receipt notification using Disposition Service
Notification - Message Disposition Notification [DSN-MDN], as
well as some outlines for client/device capabilities negotiation.

2.3 ITU FAX

The ITU (International Telecommunications Union) has taken two
approaches to defining an Internet Fax service.

2.3.1 ITU STORE-AND-FORWARD FAX

In the first instance it has adopted the body of IETF
IFAX work [RFC 2301-2306 inclusive] and defined it as [T.37].

2.3.2 ITU REALTIME FAX

The ITU has also defined a "real time" Internet fax standard as
well, now documented as [T.38].  T.38 tunnels under [H.323] to
establish capabilities exchange and reporting, then uses RTP
(Real Time Protocol) to deliver the content payload.  Though a
discussion of the merits of H.323 is beyond the scope of this
document, H.323 was originally designed for real time voice and
video and could be considered overkill for a relatively simple
application such as real time confirmed document transmission
(facsimile).

In addition T.38 does not define a destination addressing scheme
for transactions, such as a phone number or a URL. The scope of
T.38 is limited only to the transport of supported fax content
over IP networks.

T.38 is gaining acceptance specifically in the IP Telephony
Gateway market oriented towards carriers. The requirements for
H.323 in the Voice over IP market allows T.38 to be easily
implemented as an "add on" to VoIP at very little incremental
cost.

3.0 END USER REQUIREMENTS FOR A FACSIMILIE SERVICE

3.1 IETF-FAX GOALS

The document "Terminology and Goals for Internet Fax" [GOALS]
describes the general system functional requirements for an
Internet Fax service.

To Quote directly from GOALS:


SHOCKEY                 Expires April 1999              [Page  3]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998


{Begin Quote}

Traditional facsimile has a simple user operational model;
the user

  1) inserts paper into a device
  2) dials a number corresponding to the destination
  3) presses the 'start' button on the device
  4) the sending device connects to the receiving device
     using the telephone network
  5) the sending device scans the paper and transmits the
image of the paper
  6) simultaneously, the remote device receives the
transmission and prints the image on paper
  7) upon completion of transmission and successful
processing by the recipient, the sending user is notified
of success

Although not usually visible to the user, the operation (5)
of transmission consists of

 5a) negotiation: the capabilities of the sender and
recipient are exchanged, and suitable mutually acceptable
parameters for the communication are selected
 5b) scanning: creating digitized images of pages of a
document
 5c) compression: the image data is encoded using a data
compression method
 5d) transmission: the data is sent from one terminal to
the other

In addition, the termination of operations (5d) and (6) may
be characterized as consisting of:

 6a) completed delivery: the message has completed
transmission
 6b) completed receipt:  the message has been accepted by
the recipient
 6c) processing and disposition: the message has been
processed

{End Quote}






SHOCKEY                 Expires April 1999              [Page  4]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998


3.1 GENERAL REQUIREMENTS FOR FAX

In addition to the above specifications there are additional
requirements for Sender/Recipient Identification Exchange,
time/date stamping, and optional "watermarking" of each page of
the FAX transmission required by law in the United States
and several other countries (see LEGAL ISSUES below).

Of these specifications, there is a substantial body of market survey
research (Pitney-Bowes/Gallup) that indicates that
Confirmation/Receipt is considered the most useful feature of
traditional fax.

3.1.1 CONFIRMATION REQUIREMENTS FOR FAX

The end user requirements for confirmation and receipt must
contain the information you typically find in the transaction
report from a conventional fax machine or fax server.

This includes, but is not limited to:

1. MUST record status of transaction
        (success, failure, cause of failure)
2. MUST record date and time of all attempts
        (log files recorded at each end by client and server locally)
3. MAY record Duration of call(s)
4. MAY record number of pages transferred
5. MUST exchange and record client or server identification

As a general rule, end user expectations for an Internet
Facsimile service are driven by the perceptions of, if not
necessarily the reality of, traditional GSTN FAX.

3.2 IPP GOALS

 For Information on the IETF-IPP work group:

 http://www.pwg.org/ipp

The document "Design Goals for an Internet Printing Protocol",
draft-ietf-ipp-req-02.txt, June, 1998 [IPP-REQ] outlines the
design goals for IPP and identifies some specific end user
requirements.

{quote}

        END-USER

SHOCKEY                 Expires April 1999              [Page  5]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998

An end-user of a printer accepting jobs through the
Internet is one of the roles in which humans act.  The end-
user is the person that will submit a job to be printed on
the printer.

The wants and needs of the end-user are broken down into
six categories: finding/locating a printer, creating a
local instance of a printer, viewing printer status,
viewing printer capabilities, submitting a print job,
viewing print job status,

{end quote}

3.3 IPP - FAX - IFAX

Based on the requirements of both an Internet Fax Service and the
Internet Print Protocol it seems that on the most basic level
their are significant similarities from the perspective of the
end user.

FAX/IFAX Message Addressing = IPP Finding/Locating
        a printer [URL Addressing]
FAX/IFAX Message Creation = IPP Creating the Print File
        [Supported MIME Content Type or "Payload"]
FAX/IFAX Message Transmission = IPP Submitting a Print-Job
FAX/IFAX Message Confirmation (Receipt) = IPP Client Poll
        for Print-Job Status

4.0 OBSERVATIONS ON THE DIFFERENCES BETWEEN IPP and FAX/IFAX SERVICES

4.1 INTEROPERABILITY

IPP has developed interoperability mappings to
other print services, such as TLS, but it currently
has no explicit methodology to allow  supported IPP
MIME Content-Types to interoperate with different fax
services, such as SMTP or GSTN FAX. It is assumed that URL's
could be devised to facilitate interoperability between these
services. (see IPP TO GSTN GATEWAY CONCEPTS).

An IPP transaction destined for a GSTN gateway might be addressed
as:

http://domain.com/ipp/FAX=13149189015

Where the number is a fully qualified ITU E.164 number conforming
to the IFAX gateway specifications outlined in [RFC2304] and
[RFC2305].


SHOCKEY                 Expires April 1999              [Page  6]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998


Further study will be necessary to investigate proper schemes for
the addressing of gateways in an IPP environment.

4.2 DATA FORMATS (CONTENT PAYLOAD)

IPP and FAX/IFAX take two fundamentally different approaches to
the content payload of a message. FAX limits its content to the
image files specified by the [T.30] protocol. IFAX limits its
Content-Type to a highly defined set of TIFF images specified in
RFC2301 and specifically limits Content-Type to a subset of TIFF
defined in RFC2306 in the event that the capabilities of the
recipient is not known in advance.

The rational for this has been that TIFF has historically been
used in the GSTN-FAX and that by defining a similar type of
content for IFAX, the goal of service interoperability is
advanced.

IPP has none of these restrictions. IPP is limited only
to Registered MIME Content-Types supported by of the output
device or service preformed by the IPP server for the
recipient. This is facilitated by content negotiation
during the IPP session setup.

IPP may wish to consider the mandated support of RFC2306
by both clients and servers as a Least Common Denominator
to facilitate interoperability in a Facsimile Service Mode.

4.3 ADDRESSING

Both IPP and IFAX use commonly understood addressing schemes well
known among Internet users.

IFAX uses SMTP addressing.

IPP uses URL's.

IPP has the ability to allow multiple URL's to access a single
output resource such as:

http://domain.com/ipp/rshockey
http://domain.com/ipp/mickey_mouse
http://domain.com/ipp/printer42

These separate addresses might output to a single printer in much
the same way a single FAX number is available to several
individuals. This capability is purely dependent on the
implementation of the IPP server.

SHOCKEY                 Expires April 1999              [Page  7]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998


4.5 CAPABILITIES EXCHANGE

FAX devices negotiate and exchange capabilities during the call
setup of T.30. Information is passed between devices through the
use of highly defined "frames" of data. Such data exchange
includes such attributes as page size, resolution, speed of
transmission and identity of terminal devices (T.30-CSID).

A severe limitation of the current IFAX service is the lack of
any method by which Message User Agents can exchange capabilities
in advance of sending a message. In such circumstances, the use
of Least Common Denominators [RFC 2306] has been recommended in
RFC 2305. Further work [EIFAX] is addressing those issues.

IPP Protocols for reliable negotiation and download of
unavailable printer drivers in IPP are currently out of scope for
IPP V1.0, but it is assumed that subsequent versions of IPP will
address this problem.

The IETF and World Wide Web Consortium [www.w3.org] are looking
at a variety of schemes to permit clients and servers to exchange
data on capabilities. Work in the IETF is continuing in the
CONNEG WG.

4.6 IDENTITY EXCHANGE

The identity of senders and recipients in traditional FAX are
achieved through the legal requirements for fax (see LEGAL ISSUES
below) and the exchange of T.30 CSID frames between terminal
devices "on the wire" during T.30 session negotiation.

IFAX uses E-Mail header information to identify the sender to the
recipient. The recipient has no requirement to exchange data.

IPP has no formal capability to exchange identity data between
sender and recipient, beyond the IPP URL.

The use of [vCARD] in IPP to facilitate this should be considered.

4.7 TRACKING AND CONFIRMATION

Traditional FAX uses In-Band monitoring to signal the sender when
a document transmission has completed or report on any errors
encountered.




SHOCKEY                 Expires April 1999              [Page  8]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998



Both FAX sender and receiver have internal clocks that monitor
the progress of that transaction and log the data in an
appropriate manner.

IFAX is currently developing a variety of options for tracking
the progress and delivery of a document using standard Internet
Mail methodologies such as Message Disposition Notification [MDN-
RFC2289] and Disposition Service Notification [DSN-RFC 1891,
RFC1894]

IPP offers a comprehensive suite of attribute options for
monitoring the success or failure of a Job-Submission.

IPP Clients track and confirm the success or failure of
Job-Submission by polling the IPP server for the status
of a transaction, however polling the server for status
by the IPP client is not mandated.

The IPP work group is proceeding on a more advanced suite of
Notification Attributes [IPP-NOT] to permit notification by a
variety of means, such as E-Mail, on success or failure of Output
of IPP Job after successful submission.

4.8 TIME/DATE INFORMATION

FAX terminal devices all have internal clock devices for
recording the time/date of transactions. Actual time information
is not exchanged "on the wire". Each device notes when it sends
and receives documents and logs those transactions locally.

All E-Mail transactions have time/date information located in the
E-Mail headers.

IPP does suffer from the lack of an explicit requirement for
time/date stamping of transactions by either client or server.
This will severely limit its use as a facsimile service and
transmissions will not meet the legal requirement [see LEGAL
ISSUES below] for a "fax". It will be necessary for IPP
implementers to consider the installation of real time clocks in
their devices or use of Time Protocol or Daytime Protocol [RFC
867/868] to implement time/date stamping.

4.9 SECURITY, AUTHORIZATION AND AUTHENTICATION

On the surface, it would seem that no one would want to make his
or her printer available on the Internet.


SHOCKEY                 Expires April 1999              [Page  9]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998


It should be noted, however, that we have globally accessible
printers available now. They are just called fax machines.

The use of IPP as both a Remote Printer application and as a
Facsimile Delivery Service, may cause some confusion in the mind
of end users on what is and what is not "acceptable use".

IPP can use the security service available in Digest
Authorization within in HTTP 1.1 [RFC2069] to authorize
a client log in to a IPP server.

Additional study on the behavior of IPP clients/servers
is may be needed on what types of IPP transactions should
be available to all outside users vs authorized users only.

5.0     IPP and FAX/IFAX PROTOCOL MAPPINGS NECESSARY FOR GATEWAY
INTEROPERABILITY

Though IPP has the functional attributes to be a facsimile
service it may be necessary to consider interoperating with
the existing GSTN FAX or IFAX service in the future.

Detailed mapping of the various attributes and structures will be
necessary. Fortunately considerable groundwork is being
undertaken in the IETF FAX WG to describe and detail those
attributes. Among the attributes that will need to be mapped:

Architecture
Data Formats (MIME Content-Types): Such as RFC 2301-RFC2306
Print Resolution: 100x200, 200x200, 400x400 etc
Compression: MH, MR, MMR, JBIG, JPEG
Page Counts
Capabilities Discovery
Error Codes

The following documents describe ongoing work in the IETF-FAX
work group that should be of considerable assistance in FAX/IPP
attribute and syntax mapping:

[CONNEG-FEATURE-SYNTAX] draft-ietf-conneg-feature-syntax-XX.txt.

[FAX-SCHEMA] draft-ietf-fax-feature-schema-XX.txt.




SHOCKEY                 Expires April 1999              [Page  10]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998


6.0 IPP ADVANTAGES AS A FACSIMILE SERVICE

6.1 CONTENT

IPP offers the end user a rich set of options for the creation
and delivery of documents. Essentially any Page Description
Language [Printer Driver] supported by the recipients' server
could process the transaction and output the document.

Though there is no mandated Least Common Denominator for
IPP Clients and Servers , there is also no functional limitation
on IPP output.

Were future versions of IPP to support the legal requirements for
identification and time/date marking [see LEGAL ISSUES below] IPP
would be perceived a facsimile service by end users. Once end
users transmit documents across domains, the obvious similarity
to traditional FAX should become self-evident.

6.2 NOTIFICATION AND RECIEPT

[IPP-MOD] and [IPP-PRO] contain the basic facilities to be able
to monitor the submission of an IPP-Job in real time.

The current state of IPP Notification is not dissimilar to the
function of [DSN] and [MDN]. Currently IPP V1.0 can monitor the
submission of an IPP Job but it cannot notify the sender whether
the job was actually processed. This is similar to the function
of DSN in the SMTP service where notification takes place when
the message reaches the "last hop" server but cannot notify the
sender if or when the recipient picks up their mail via a MUA.

MDN does provide actual notification when a message was viewed by
the recipient and could be considered similar to current IPP work
on notification of output status.

IPP V.1 does not mandate the client polling of the server for
status, however since notification and receipt are central
requirements of any facsimile service, such polling would be a
requirement for IPP when used in a Facsimile Service Mode.

6.3 POINT TO POINT ORIENTATION

IPP has the advantage of being an "end to end" protocol. The end
user experience, as well as the real time nature of IPP, is very
similar to GSTN-FAX.



SHOCKEY                 Expires April 1999              [Page  11]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998


6.4 ECONOMIC CONSIDERATIONS

The use of IPP as a facsimile service offers end users
significant economic advantages. Though GSTN Long Distance
charges are continuing to drop, one of the most significant costs
in FAX is the necessity to maintain dedicated and often expensive
local lines. These charges, which average nearly US $30.00 per
month [$360.00 yearly], and are significantly higher in Europe
and Asia for business customers. These costs now represent one of
the highest factors in calculating the Total Cost of Ownership of
Fax. The attraction of IPP is that once the fixed cost of an IP Network
have been implemented within an enterprise the incremental cost
of adding additional IP application services to the Network is
marginal.

7.0 IPP SHORTCOMINGS AS A FACSIMILIE SERVICE

7.1.1 IFAX GATEWAY CONCEPTS

The concepts for gateways in IFAX are described in GOALS:

a)Fax onramp gateway
A device that can accept a facsimile telephone call and
automatically forward it via the Internet

b)Fax offramp gateway
A device that can accept a transmission from the
Internet and forward it to a traditional fax terminal

[sender]-IPP->[offramp]-PSTNFax->[fax-term]

With these concepts in mind, there is a potential role for IPP as
a Gateway protocol to transport the documents across the Internet
to multiple services.

a)IPP onramp gateway
A device or server that can accept an IPP document
transaction from either a facsimile telephone call or an
IFAX SMTP transaction.

b)IPP offramp gateway
A device or server than can accept an IPP transaction and
forward it to either a GSTN FAX device or an IFAX SMTP
transaction.



SHOCKEY                 Expires April 1999              [Page  12]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998


c)IPP disconnected gateway
A device or server that can accept an IPP transaction and
forward it to an IPP output device that is periodically
disconnected from the Internet

7.1.2 IPP GATEWAY SCENERIOS

There could be several scenarios for the role of IPP in
Gateways.

[fax-term]-PSTNfax->[onramp]-IPP->[recipient]

[fax-term]-PSTNfax->[onramp]-IPP->[offramp]-PSTNFax->[fax-
term]

[POP3Client]-SMTP-IPP_onramp->recipient

[sender]-IPP_offramp->SMTP-[POP3Client]

[sender]-IPP>IPP server>SMTP_offramp>[recipient]

[sender]-IPP>IPP server>PSTN_offramp>[recipient]


7.2 TIME/DATE RECORDING

IPP does not have explicit requirements or attributes
to express time/date information within transactions
or transaction logs.

The time/date of FAX transactions are locally recorded
 by each FAX client/terminal.

IPP clients and servers will have to begin recording such
transactions.


7.3 IPP AUTOMATIC DRIVER DISTRIBUTION

Currently there is lack of support for automatic printer driver
distribution during an IPP transaction.

Though no minimum printer driver format is specified in IPP, it
would not be unreasonable for implementers to consider mandating
support of standard RFC 2301 or RFC 2306 MIME Content-Types to
facilitate universal interoperability as well as facilitate
the use of IPP as a gateway to GSTN FAX or redirect job output
to the SMTP IFAX service.



SHOCKEY                 Expires April 1999              [Page  13]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998


7.4 INSTALLATION AND CONFIGURATION ISSUES

The installation and configuration of an IPP service will require
significant knowledge and expertise on the part of system
administrators. It will be necessary to configure figure network
firewalls to support the standard IPP port of 631.

8.0 LEGAL ISSUES

The use of IPP as an Internet Facsimile Service must attempt to
accommodate the legal requirements for GSTN facsimile.

The legal use of FAX for document transmission and receipt is
well understood in US Case Law.

There is some evidence to suggest that Courts in the United
States view the transmission of information and documents
independently of the protocols and methodology used to achieve
those means. The US Courts recognize that new technology is
introduced very rapidly and that in many cases procedural rules
have not kept pace. There is every reason to believe that if
IPP is used in the context of a facsimile service and "best efforts"
are taken to duplicate the "look and feel" of GSTN FAX and
satisfy the legal requirements customary in FAX, IPP
transactions will be accorded the full support and protection
of law.

8.1 UNITED STATES LAW

The United States Federal Communication Commission regulations
and US Federal Law (47 USC 227) state:

{quote}

   "Identification Required on Fax Messages

    The FCC's rules require that any message sent to a fax
machine must clearly mark on the first page or on each page
of the message:
-  the date and time the transmission is sent;
-  the identity of the sender; and
-  the telephone number of the sender or of the
sending fax machine.





SHOCKEY                 Expires April 1999              [Page  14]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998


All fax machines manufactured on or after December 20, 1992
and all facsimile modem boards manufactured on or after
December 13,1995 must have the capability to clearly mark
such identifying Information on the first page or on each
page of the Transmission."

{end quote}

Of particular note is that there is no requirement that the marks
for identifying information be placed on every page. The legal
requirement is only for the first page, though it has become
custom and practice among all FAX device manufacturers to include
the "watermark" on each page transmitted.

8.2 WATERMARKING OF PAGES

This marking of the pages in FAX is commonly referred to as
"watermarking" of the transmission. These marks are typically
placed at the top of each page of the fax transmission and
contain time/date information, sender identification [typically
T.30 CSID frame data] and page number information. The sender's
device creates this data at the moment the transaction begins.
The recipient output device does not modify the document once it
is received.

Though this requirement, and similar ones in many countries,
applies only when the transmission occurs over the GSTN, it seems
reasonable to assume that various national authorities will
extend this requirement to the Internet as facsimile traffic is
taken off the GSTN.

IPP Facsimile Mode implementations will have to insert
these watermarks into the supported PDL MIME Content-Type.

9.0  COVER PAGES

Closely associated with the legal issues are the formats and
requirements for cover pages.

9.1 TYPICIAL DATA

Cover pages on facsimile transmissions typically contain the
following data:





SHOCKEY                 Expires April 1999              [Page  15]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998


Identification of Sender:
Identification of Recipient:
Time/Date of Transmission:
Number of pages in Transmission:
Comment Field:

9.2 IPP JOB SEPERATOR SHEETS

IPP currently has a facility for the automatic generation of
pages by the IPP server to separate  Job-Submissions, however
there are currently no IPP attributes that would permit IPP
client definitions of the Job-Seperator sheets to conform to
 either the legal or general custom and practice of facsimile
cover sheets.


10.0 COMMON FACSIMILIE CLIENT INTERFACE MODELS

Most end user FAX interfaces fall within two categories. A client
workstation device, typically a personal computer with a modem or
attached to a LAN Fax server and appropriate software, or a
client terminal device with some form of scanner imput. These
terminal devices would be the typical fax machine or
multifunction peripheral.However, the options available on
these client interfaces have evolved in different ways because
of the unique nature of the facsimile service.

10.1 CLASSIC FAX DEVICES

Classic FAX terminal devices offer only a limited number of
options for end users. Typically, these functions are for higher
or lower resolution, gray scaling etc. It is assumed that the
document to be faxed is already in paper form. In addition, they
usually offer no options for automatic cover page generation
since it is assumed that the end user will manually fill out some
form of fax cover page and simply add it to the pages to be
transmitted.

The Classic FAX terminal device adds the legal "watermarks" to
the top of each of the pages transmitted but in no other way
alters the document.

10.2 FAX SOFTWARE

Fax software has evolved differently. In addition to the usual
options provided for resolution and gray scaling and the


SHOCKEY                 Expires April 1999              [Page  16]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998


watermarking of pages, workstation fax software has traditionally
offered options for automatic cover page generation, document
management, alternate transmission times and a variety of other
useful functions. The document transmitted is directly converted
to fax form by the workstation application through the use of a
special printer driver in much the same manner as IPP.
It should be noted that there has been a substantial and active
Computer Fax Industry for nearly 10 years. Market survey research
has consistently shown that only 15% of total pages transmitted
in North America are generated by workstations, and an even
smaller percentage of faxes are received by workstations or LAN
Fax Servers.

11.0 IPP CLIENT BEHAIVOR IN A FACSIMILE SERVICE MODE

11.1 IPP CLIENT BEHAIVOR

IPP clients, in a facsimile service mode, need only duplicate the
essential "look and feel" of GSTN FAX client/devices . IPP
terminal devices with scanner input options could offer the
option of watermarking each page of the document as is currently
customary in FAX.  IPP Client software could optionally offer
Cover Page Generation and other features, as the market deems
appropriate.  No additional protocol requirement or burdens are
necessary in IPP [IPP-MOD/IPP-PRO] itself.

11.2 IPP SERVER BEHAVIOR

IPP attributes for time/date should be developed in order to
permit IPP servers to properly log transactions in a facsimile
service mode. Time/date recording is an essential part of
notification.

12.0 CONCLUSIONS

IPP has all of the functional elements to be a superior facsimile
service over the Internet. It is superior to IFAX fax-over-SMTP
[RFC2505] and superior to fax-over-H.323 [T.38] for both the end
user and for the device implementor.

It is a better FAX than GSTN FAX.

It is my judgement that IPP transactions, once they cross
domains, will be perceived by end users as a "facsimile service"
irrespective of what the goals and objectives of the IPP protocol
designers were.


SHOCKEY                 Expires April 1999              [Page  17]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998



Getting a document from "here to there" over the wire will be
perceived as "fax". It will not make any difference whether the
transaction is GSTN FAX, SMTP, or IPP protocols.

IPP can achieve the "look and feel" of FAX with the
additions of time/date stamping of sender/recipient transaction
logs by each local IPP device, IPP Client watermarking of each
page of the transmission in the customary manner of FAX and cover
page creation options in future IPP Client software or firmware.

IPP has most of the functional specifications, as well as
attributes necessary to successfully map to the existing RFC 2305
Internet Fax service through, at the very least support of RFC
2306 and optionally RFC 2301 Content-Types.

13.0 ACTION RECOMMENDATIONS

Based on the concepts and conclusions discussed in this
memorandum, work could commence to define IPP as a facsimile
service and outline protocols for interoperability between IPP
and GSTN FAX, as well as RFC2305 and its successors [EIFAX].

Several work items are recommended.

A. Document Goals and Objective for the use of Internet Print
Protocol as a facsimile service.

B. Document IPP Client/Server Profile when used in a Facsimile
Service Mode especially IPP enhancements necessary to support
time/date stamping of all transactions.

C. Document Gateway Protocol Mapping between IPP and FAX/IFAX
for Onramps and Offramps.

D. Document IPP to FAX/IFAX URL gateway syntax.

E. Investigate possible requirement to support RFC2306
as a Least Common Denominator by IPP clients and servers
when operating in a Facsimile Service Mode.

F. Continue established work in IPP Notification enhancements.






SHOCKEY                 Expires April 1999              [Page  18]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998


14.0 ACKNOWLEDGEMENTS

The author would like to acknowledge the assistance of members of
both the IETF FAX and IETF IPP work groups who have provided
invaluable assistance and imput during the development of this
document: Larry Masinter, Dan Wing, Carl-Uno Manros, Graham
Klyne, Ron Bergman, and Brian Stafford.

15.0    REFERENCES

[CONNEG-FEATURE-SYNTAX] G. Klyne, "A syntax for describing media
feature sets", Internet Draft, Work in Progress,
draft-ietf-conneg-feature-syntax-XX.txt.

[FAX-SCHEMA] L. McIntyre, G. Klyne, "Content feature schema for
Internet fax", Internet Draft, Work in Progress,
draft-ietf-fax-feature-schema-XX.txt.

[GOALS] L. Masinter, "Terminology and Goals for Internet Fax",
Internet Draft, Work in Progress, draft-ietf-fax-goals-XX.txt.

[EIFAX] L.Masinter, D.Wing, "Extended Facsimile Using Internet
Mail" Work in Progress draft-ietf-fax-eifax-0X.txt October 1998

[FAX] [T.30] ITU-T, "Procedures for Document Facsimile
Transmission in the General Switched Telephone Network", ITU-T,
Recommendation T.30, July, 1996.

[T.38] ITU-T, "Procedures for real time Group 3 facsimile
communications over IP networks"" ITU-T Recommendation T.38, July
1998

[T.37] ITU-T, "Procedures for the transfer of facsimile data via
store and forward on the internet", ITU-T Recommendation T.37,
July 1998

[H.323] ITU-T, "Visual Telephone systems and equipment for local
area networks which provide a non guaranteed quality of service",
Recommendation H.323, November 1996

[E.164] ITU-T, "The international public telecommunications
numbering plan"" Recommendation E.164/I.331, June 1997

[RFC 867/868] J. Postel, K. Harrenstien,  "Daytime Protocol"
RFC867, "Time Protocol" RF868, May 1983



SHOCKEY                 Expires April 1999              [Page  19]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998



[RFC1891] [DSN] K. Moore, "SMTP Service Extensions for Delivery
Status Notifications", RFC 1891, January 1996.

[RFC1893bis] [DSN] G. Vaudreuil, "Enhanced Mail System Status
Codes",Internet Draft, Work in Progress, (update to RFC 1893).

[RFC1894] [DSN] K. Moore, G. Vaudreuil, "An Extensible Message
Format for Delivery Status Notifications", RFC 1894, January
1996.

[RFC2298] [MDN] R. Fajman, "An Extensible Message Format for
Message Disposition Notifications", RFC 2298, March 1998.

[RFC2301] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G.
Parsons, J.  Rafferty, "File Format for Internet Fax", RFC 2301,
March 1998.

[RFC2303] C. Allocchio, "Minimal PSTN address format in Internet
Mail", RFC 3203, March 1998

[RFC2304] C. Allocchio, "Minimal FAX address format in Internet
Mail", RFC 2304, March 1998

[IFAX] [RFC2305] K.Toyoda, H. Ohno, J. Murai, D. Wing, "A Simple
Mode of Facsimile Using Internet Mail", RFC 2305, March 1998.

[RFC2306] G. Parsons, J. Rafferty "Tag Image File Format (TIFF) -
F Profile for Facsimile", RFC 2306 Status: Informational, March
1998

[RFC2069]  J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach,
A.Luotonen, E.  Sink, L. Stewart, "An Extension to HTTP: Digest Access
Authentication", RFC-2069, Jan 1997.

[VPIM2] Vaudreuil, G., and G. Parsons, "Voice Profile for
Internet Mail - version 2", RFC 2421, September 1998.

[IPP-MOD] Isaacson, S., deBry, R., Hastings, T., Herriot, R.,
Powell, P. "Internet Printing Protocol/1.0: Model and Semantics"
draft-ietf-ipp-mod-10.txt, Work In Progress, June, 1998.

[IPP-PRO] Herriot, R., Butler, S., Moore, P., Tuner, R.,
"Internet Printing Protocol/1.0: Encoding and Transport", draft-
ietf-ipp-pro-06.txt, Work In Progress, June, 1998.




SHOCKEY                 Expires April 1999              [Page  20]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998


[IPP-REQ] Wright, D., "Design Goals for an Internet Printing
Protocol", draft-ietf-ipp-req-02.txt, Work In Progress, June,
1998.

[IPP-RAT] Zilles, S., "Rationale for the Structure of the Model
and Protocol for the Internet Printing Protocol", Work In
Progress, draft-ietf-ipp-rat-03.txt, June, 1998

[IPP-NOT] deBry, R., "Requirements for IPP Notifications", Work
in Progress, draft-ietf-ipp-not-01.txt, March 1998

[VCARD]  M. Smith, F. Dawson, T. Howes, "A MIME Content-Type
for Directory Information", RFC2425, September 1998. F. Dawson,
T. Howes, rfc2426.txt - "vCard MIME Directory Profile", RFC2426,
September 1998. Additional information at : http://www.imc.org/pdi/


16.0  AUTHOR'S ADDRESS

Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd
Suite 100
St. Louis, MO 63119

Voice:  314.918.9020
Fax:  314.918.9015
Email/IFAX : rshockey@ix.netcom.com


17.0 COPYRIGHT

Copyright (C) The Internet Society 1998.  All Rights Reserved.

This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works.  However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to
the Internet Society or other Internet organizations, except as
needed for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet



SHOCKEY                 Expires April 1999              [Page  21]


INTERNET DRAFT          IPP as a Facsimile Service      November 1998


Standards process must be followed, or as required to translate
it into languages other than English.

The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.


SHOCKEY                 Expires April 1999              [Page  22]