INTERNET DRAFT                                  Richard Shockey
October 26, 1998                                Shockey Consulting LLC
Expires April 1999
draft-shockey-ipp2ifax-00.txt


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


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 IPP transactions and logs.

1.0 INTRODUCTION


SHOCKEY                 Expires April 1999              [Page  1]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998


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
reporting and receipt notification using Disposition Service
Notification – Message Disposition Notification [DSN-MDN], as
well as some outlines for client/device capabilities negotiation.


SHOCKEY                 Expires April 1999              [Page  2]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998


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 essentially 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).

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:

{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


SHOCKEY                 Expires April 1999              [Page  3]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998


  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}

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 transmission currently 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


SHOCKEY                 Expires April 1999              [Page  4]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998


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 should
contain, at a minimum, the information you find in the
transaction report from a conventional fax machine or fax server.
This includes, but is not limited to:

1. Status (SUCCESS, FAILURE, CAUSE OF FAILURE)
2. Date and time of all attempts
3. Duration of call(s)
4. Number of pages transferred
5. Remote 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

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}


SHOCKEY                 Expires April 1999              [Page  5]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998


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
FAX/IFAX Message Creation = IPP Creating a Instance for a Printer
FAX/IFAX Message Transmission = IPP Submitting a Print-Job
FAX/IFAX Message Confirmation (Receipt) = IPP Viewing Print-Job
Status

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

4.1 INTEROPERABILITY

What is lacking in IPP are clear and explicit methodologies that
would allow the content payloads to interoperate with different
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].

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
RFC 2301 and specifically limits Content-Type to a subset of TIFF
defined in RFC 2306 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


SHOCKEY                 Expires April 1999              [Page  6]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998


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 by the
capabilities 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.

4.4 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.

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 has been recommended in RFC 2305.
Further work [EIFAX] is addressing those issues.

IPP Protocols for reliable negotiation and download of


SHOCKEY                 Expires April 1999              [Page  7]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998


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.

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.

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.

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 document transaction
submission or job. Included is the ability to cancel or modify
the job at any point.

The IPP work group is proceeding on a more advanced suite of
Notification Attributes [IPP-NOT] to permit notification on
either the success or failure of any IPP job submitted.


SHOCKEY                 Expires April 1999              [Page  8]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998


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 recieves documents and logs those transactions appropriately.

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.

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”.

Some study and discussion on the behavior of IPP servers is
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



SHOCKEY                 Expires April 1999              [Page  9]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998


attributes. Among the attributes that will need to be mapped:

Architecture
Data Formats (Content Payload)
Document Format:
Print Resolution:
Compression:
Page Counts:
Tracking Confirmation:
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 mapping:

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

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


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.

There is no functional limitation on the quality of 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


SHOCKEY                 Expires April 1999              [Page  10]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998


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.

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.

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, 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 IPP GATEWAY CONCEPTS

IPP does not currently specify any form or function that might
allow it to be used as a gateway to either the IFAX or GSTN FAX
service.

7.1.1 The concepts for gateways in IFAX are quite simple as GOALS
describes:

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


SHOCKEY                 Expires April 1999              [Page  11]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998


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.

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 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]

7.2 LOGS – RECIEPT – ACKNOLEDGEMENT

Requirements for detailed receipt and acknowledgement logs needs
to be explored and the means and methodology by which those
protocol acknowledgements are time/date stamped.





SHOCKEY                 Expires April 1999              [Page  12]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998



The necessity for maintaining such accurate records by IPP
senders and recipients is heightened since there will be no 3rd
party telephone records available to confirm the transaction.

7.3 TIME/DATE RECORDING

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

This issue must be resolved if IPP is to be used as a facsimile
service.

7.4 IPP AUTOMATIC DRIVER DISTRIBUTION

Currently there is lack of support for automatic printer driver
distribution during an IPP transaction. It is assumed that this
will be an IPP V.2 issue.

Though no minimum printer driver format is specified in IPP, it
would not be unreasonable for implementers to consider or the
development of a standard RFC 2301 or RFC 2306 printer driver as
a feature should there be a need for IPP to act as a gateway to
GSTN FAX or redirect job output to the SMTP IFAX service.

7.5 INSTALLATION AND CONFIGURATION ISSUES

The installation and configuration of an IPP service will require
significant knowledge and expertise on the part of system
administrators. Of particular difficulty will be the
configuration of IPP devices through network firewalls.

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.


SHOCKEY                 Expires April 1999              [Page  13]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998



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 the 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.

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


SHOCKEY                 Expires April 1999              [Page  14]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998


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.

8.3 FUTURE OPTIONS - IDENTIFICATION

Though not a specific legal requirement, future IPP work might
consider extensions to the protocol for the transmission of
Advanced Sender Identification to the recipient such as a
[VCARD].

9.0  COVER PAGES

Closely associated with the legal issues are the formats and
requirements for cover pages and the time date stamping of
transactions in a facsimile service.

9.1 TYPICIAL DATA

Cover pages on facsimile transmissions typically contain the
following data:

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


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.


SHOCKEY                 Expires April 1999              [Page  15]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998


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
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


SHOCKEY                 Expires April 1999              [Page  16]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998

 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.

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 simple
additions of time/date stamping of sender/recipient transaction
logs, 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



SHOCKEY                 Expires April 1999              [Page  17]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998


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 attribute enhancements necessary
to support time/date stamping of all transactions.

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

D. Document IPP to FAX URL gateway syntax.

E. Continue established work in IPP Notification enhancements.

14.0    ACKNOLEDGEMENTS

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.



SHOCKEY                 Expires April 1999              [Page  18]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998


[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

[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

SHOCKEY                 Expires April 1999              [Page  19]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998


[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.

[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]+ [VCALENDAR]: 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

SHOCKEY                 Expires April 1999              [Page  20]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998


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
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  21]


INTERNET DRAFT          IPP as a Facsimile Service      October 1998