My assumption is that if we are granted a BOF in Minneapolis on IPP2IFAX we
could discuss this draft, the proposed charter, and any other things that might
come up.
If you have any comments .. please cut and paste the sections you want to
discuss from the whole document.
#########################
INTERNET DRAFT Richard Shockey
February 10, 1999 Shockey Consulting LLC
Expires August 10, 1999
draft-shockey-ipp2ifax-goals-00.txt
Goals and Requirements for the use of the Internet Print
Protocol [IPP] as a Facsimile Service
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026.
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 list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
A discussion list is available on topics related to this
draft.
To subscribe to the mailing list, send a message to
majordomo@pwg.org with the line "ifx subscribe
yourname@address.com" in the body of the message.
The subject line should be left blank.
Archives are available from http://www.pwg.org/hypermail/ifx
ABSTRACT
This document discusses the use of the Internet Print
Protocol [IPP] as a Facsimile Service on the Internet.
A variety of goals and requirements are outlined to
facilitate the use of IPP in compliance with the legal as
well as general custom and practice surrounding General
Switched Telephone Network Facsimile Services [FAX].
1.0 INTRODUCTION
Facsimile [FAX] has a long and successful tradition as a
telephony application for sending and printing a document
from one device to another.
The Internet Print Protocol has developed within the IETF as
an application level protocol that can be used for
distributed printing over the Internet using HTTP as the
transport protocol. [IPP-RAT]
As document distribution technologies IPP and FAX share a
number of common elements including:
A. Document Creation
B. Addressing for the Delivery of Documents
C. Capabilities Negotiation between Sender and Recipient
D. Receipt and Confirmation of Transactions
E. Security
At a sufficient level of abstraction, the concept of FAX
could be considered a "remote printing" technology.
Therefore, a comparison of IPP to other facsimile services
is useful.
1.1 DEFINITION OF TERMS
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in [RFC2119].
Facsimile Service Mode shall be defined as the Internet
Print Protocol transmission of non-alterable documents
across Internet domains or the use of IPP to gateway to
other Internet Fax or GSTN Facsimile Services.
Throughout this document "PDL" shall refer to the IPP Page
Description Language Content-Types defined in [IPP-MOD]
IPP introduces objects described as "Job" and "Printer" to
describe functions normally associated with printing.
The concept of an IPP "Job" encapsulates transaction
requests and responses that create and deliver a document to
a "Printer". The actual nature of the IPP "Printer" could be
a device capable of creating impressions on paper, but it is
not a requirement.
2.0 OVERVIEW OF EXISTING FACSIMILIE SERVICES
2.1 TRADITIONAL FAX
Traditional facsimile as defined by the ITU [T.30] is a
connection oriented technology between two terminal devices
over the GSTN (Global Switched Telephone Network). It is
specifically a "point to point" service where the end point
is identified by an ITU [E.164] telephone number. The
content types specified by T.30 are highly restricted due to
the lack of bandwidth on the analog GSTN, typically limited
to 14.4Kpbs, but standards do exist to support up to
28.8Kpbs.
2.2 IETF FAX SERVICE
The Internet Fax service [IFAX][RFC2301-RFC2306 inclusive]
has developed within the IETF 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 mode.
IFAX adds additional functionality by integrating with other
SMTP services, such as the Voice Profile for Internet Mail
[VPIM2], in a concept often referred to as "Universal
Messaging".
2.3 ITU FAX
The ITU-T (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 designated the body of IETF
IFAX work, [RFC2301-RFC2306 inclusive] and defined it as
[T.37].
2.3.2 ITU REALTIME FAX
The ITU has also defined a "real time" Internet fax
standard, 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.
No addressing scheme is defined for T.38. The standard
describes only a transport protocol.
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 a facsimile 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
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 processed
{End Quote}
3.2 OTHER GOALS OF A FACSIMILE SERVICE
In addition to the above specifications there are additional
requirements for Sender/Recipient Identification Exchange,
time/date stamping, and sender identification requirements
such as page marking currently required by law in the United
States and several other countries (see LEGAL ISSUES).
3.2.1 CONFIRMATION REQUIREMENTS FOR A FACSIMILIE SERVICE
Detailed progress reports and transaction logs have become
standard end user requirements for a facsimile service in
order to document the receipt and confirmation of facsimile
delivery.
Any facsimile service report or log:
1. MUST note status (SUCCESS, FAILURE, CAUSE OF FAILURE)
2. MUST note date and time of all attempts (log files
recorded at each end by client and server locally)
3. MAY note duration of transaction
4. MAY note number of pages transferred
5. SHOULD mutually exchange and document the identity of
both sender and recipient.
4.0 REQUIREMENTS FOR THE USE OF IPP AS A FACSIMILIE SERVICE
IPP clients and server operating in a facsimile service mode
MUST comply with all IPP protocol requirements specified in
[IPP-MOD] [IPP-PRO] [IPP-REQ] and [IPP-SCHEME]. In addition
IPP implementation recommendations are contained in separate
document [IPP-IMPLEMENTER].
4.1 REQUIREMENTS FOR DATA FORMAT SUPPORT
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 [Profile S] in the event
that the capabilities of the recipient are not known in
advance.
The rationale 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 does not specify any specific form of PDL for use by IPP
Printer Objects. This is negotiated between IPP clients and
servers during an IPP Job transaction.
In order to facilitate interoperability between IPP and
other facsimile services, all IPP clients and servers SHOULD
support file formats for Internet Fax specified by RFC2301
to be defined in IPP as IANA registered "mimeMediaTypes".
IPP transactions that gateway to other services MUST support
the creation or acceptance of the minimum file format
recommendation of RFC2301 known as Profile S.
4.2 REQUIREMENTS FOR ADDRESSING
Both IPP and IFAX use commonly understood addressing schemes
well known among Internet users.
IFAX uses e-mail addressing.
IPP uses Universal Resource Locators as specified by the
[IPP-SCHEME].
IPP has the ability to allow multiple URL's to access a
single IPP Output resource such as:
ipp://domain.com/daffy_duck
ipp://domain.com/canada_goose
ipp://domain.com/color_printer
These separate addresses might output to a single printer in
much the same way a single FAX number is available to
several individuals.
In order for IPP to interoperate with other facsimile
services and gateway between them it will be necessary to
develop new IPP Job Template attributes that will permit IPP
clients the ability to pass [E.164] FAX numbers, e-mail
addresses, e-mail notification requirements, e-mail security
or encryption requirements to IPP servers.
4.3 REQUIREMENTS FOR 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).
IPP has a reliable methodology for the exchange of
Capabilities between IPP client and server. For example an
IPP client could request the capabilities of the server
through the IPP query "get-printer-attributes" which would
return "operations-supported" values to the client that
would include the supported PDL's and specific PDL
attributes.
IPP Protocols for reliable negotiation and download of
unavailable PDL drivers in IPP are currently out of scope
for IPP , but it is assumed that subsequent versions of IPP
will address this problem.
Work is underway within the IETF to document such
capabilities in a format that may be useful to IPP [CONNEG-
FEATURE-SYNTAX] [FAX-SCHEMA]
Implementations of IPP capability exchange in a facsimile
service mode may vary. Many IPP clients may not be able to
support the creation of RFC2301 or GSTN fax file formats but
IPP servers may have the capability of converting a variety
of PDL's to such formats before forwarding to another
facsimile service.
If the IPP client operating in a facsimile service mode is
unable to send a RFC2301 or appropriate GSTN fax file format
but wishes to gateway to another facsimile service then the
IPP server MUST be able to convert the PDL to the
appropriate file required by the facsimile service.
4.4 REQUIREMENTS FOR IDENTITY EXCHANGE
The identity of senders and recipients in traditional FAX
are achieved through the legal requirements for fax (see
LEGAL ISSUES) 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 identification data.
Though not a specific legal requirement, it is RECOMENDED
that IPP Job Attribute extensions for the transmission and
exchange of Advanced Sender Identification be developed,
such as a [VCARD], when operating in a facsimile service
mode.
4.5 REQUIERMENTS FOR RECIEPT, 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.
Advanced IFAX service proposals [EIFAX] have recommended the
use of [DSN] and [MDN] for receipt and confirmation.
IPP offers a comprehensive suite of options for monitoring
the success or failure of a document submission or Job. IPP
clients can listen for a response to the HTTP POST from an
IPP Printer object or may poll the IPP Printer Object for
Job Status information at any time during processing.
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.
4.6 REQUIREMENTS FOR IPP TRANSACTION TIME/DATE INFORMATION
Closely associated with the need for transaction receipt and
notification is the legal requirement [see LEGAL ISSUES]
that at least the first page of a facsimile contain the time
and date of transmission and that information be included in
any facsimile service log or record.
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 appropriately.
All IFAX transactions note time/date information in the e-
mail header information.
IPP clients and servers in a facsimile service mode MUST
implement clocks in their systems or consider the use of the
Time Protocol or Daytime Protocol [RFC 867/868] to implement
time/date transaction logging.
Examples of IPP transaction information that may be useful
to record include:
time of transmission as claimed by sender
time of reception by IPP server
IPP Printer Attribute "time-at-creation"
time print job was commenced by IPP printer
IPP Printer Attribute "time-at-processing"
time print job completed by IPP printer
IPP Printer Attribute "time-at-completion"
4.7 GOALS FOR SECURITY
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.
IPP offers several types of security to enable transaction
authorization [RFC2069 - Digest Authorization] or
transaction encryption [RFC2246 - Transport Layer Security]
5.0 GATEWAY CONCEPTS FOR IPP
IPP can be used to gateway to other facsimile services.
IPP will need to develop a variety of new status codes to
indicate how IPP servers interoperate with these services.
Gateways between messaging services consist of On-Ramps,
which accept transactions and Off-Ramps, which deliver the
transaction to its ultimate destination.
5.1 IPP TO GSTN FAX
IPP servers may accept transactions ultimately bound for a
GSTN FAX machine if appropriate IPP attributes are developed
to pass E.164 destination information along with the PDL.
IPP servers should be able to monitor the T.30 Off-Ramp
transaction in real time and be able to offer the senders
IPP client accurate transaction reports when polled.
5.2 IPP TO IFAX
Should IPP servers be used to gateway to the IFAX service
IPP servers MUST comply with all requirements of RFC2305 and
its successors [EIFAX].
5.3 REDIRECTION GATEWAY SERVER
A redirection gateway is defined as an IPP server capable of
accepting documents and submitting them to other facsimile
services such as GSTN FAX or IFAX where the final delivery
address is known to the server by administrative or
recipient configuration.
This class of gateway might be used by individuals to permit
the forwarding of transactions to e-mail addresses while on
the road. A user has configured an IPP gateway server with a
IPP address that is distributed on his business card or
stationary such as.
ipp://domain.com/donald_duck
Normally all facsimile documents would be directed to the
Output device configured for this address. If Mr. Duck is
traveling on the road, then the server could be configured
to automatically forward all of Mr. Ducks IPP transactions
to his E-Mail address at donald_duck@bigducks.com as IFAX
transactions or, perhaps delivered to a trusted colleague or
as a GSTN fax.
Server authorization to send by only by selected individuals
or TLS transaction security might be optional server
configuration options.
5.4 RELAY GATEWAY SERVER
A relay gateway is defined as a IPP server capable of
accepting documents and submitting them to other facsimile
services where the address is submitted to server by sender
during an IPP Job submission through the use of IPP
attribute extensions.
This class of IPP server might be operated by
telecommunications carriers who are using IPP to onramp to
GSTN fax services, thus eliminating the need for an analog
fax point of presence for the sender.
A customer of such a fax service might be given a special
IPP URI such as:
ipp://domain.com/fax_onramp
Once the document was created and the appropriate
destination fax number recorded for IPP attribute
submission, the IPP client and server could authenticate the
transaction through the use of Digest Authorization or some
other means.
Once the GSTN transaction was completed IPP Job records
could be created and requested by the sender's IPP client.
The IPP relay gateway could require submission of an
appropriate fax file format or be configured to accept a
variety of PDL's and conversion done at the server.
6.0 LEGAL ISSUES
The use of IPP as an Internet Facsimile Service SHOULD
attempt to accommodate the legal requirements for GSTN
facsimile.
6.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.
6.2 LEGAL REQUIREMENTS IN OTHER NATIONS
Many nations have legal requirements for FAX similar to
those in the United States.
6.3 "WATERMARKING" OF PAGES
The marking of pages in FAX is commonly referred to as
"watermarking" of the transmission. These marks are
typically placed at the top of each page by the sender's FAX
terminal device or software application. The information
inserted into page may 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.
IPP Clients SHOULD, when operating in a facsimile service
mode, insert such data into the PDL before connection to a
IPP server irrespective or whether the transaction will
gateway to the GSTN or IFAX service.
6.4 COVER PAGES
Closely associated with the legal issues are the formats and
requirements for cover pages.
IPP has facilities for the generation of cover pages defined
as Job-Separation pages generated by the recipient IPP
Output device. The format of the IPP Job-Separation pages
are implementation specific and may not satisfy the legal or
general custom and practice involved in facsimile services.
6.4.1 TYPICIAL COVER PAGE DATA
To satisfy legal requirements for Facsimile transmission
cover pages:
MUST contain identification of Sender:
SHOULD contain identification of Recipient:
MUST contain time/Date of Transmission:
MAY contain number of pages in Transmission:
MAY contain an area for short comments:
IPP Client workstation software, when operating in a
facsimile service mode, SHOULD offer Cover Page generation
options to be inserted into the PDL and MAY offer other
features, as deemed appropriate.
7.0 SCENERIOS OF IPP BEHAIVOR IN A FACSIMILE SERVICE MODE
The following are several scenarios illustrating how IPP
could be used in a facsimile service mode. Some parts of
these scenarios may include functions or capabilities that
are outside the current scope and capabilities of either IPP
or IFAX.
Legend:
C. = IPP Client
S. = IPP Server
O. = Operator
7.1 IPP WORKSTATION TO IPP OUTPUT DEVICE
In this example an individual at a workstation or personal
computer has created a document using some form of document
editor and wishes to transmit that document in a facsimile
service mode to an IPP Output device.
O. Creates Document on Workstation
O. Select IPP Output Driver from list of available printers
O. Selects Facsimile Service Mode from IPP client
application options menu
O. Enters Cover Page Data into IPP client application
O. Enters IPP URI address of server
C. Begins IPP transaction
S. Negotiation of PDL requirements
C. Renders output of Cover Page Data and "watermarks" pages
into Document PDL stream.
S. Accepts data and Outputs transaction
C. Logs successful transaction
S. Logs successful transaction
NOTE: No attempt is made to negotiate support for RFC2301 or
file formats or GSTN FAX. It is not necessary since there is
no attempt to gateway to GSTN FAX or IFAX services.
7.2 IPP NETWORK SCANNING DEVICE TO IPP OUTPUT DEVICE
A sender is using a network scanner device to imput an
existing document for submission by IPP to an Output Device.
O. Manually create or organize documents for transmission
O. Manually fill out predeveloped cover page form and add to
the documents to be transmitted
O. Insert documents into network scanner device
O. Select IPP facsimile service mode
O. Enter IPP URI address of Output server
C. Scan documents inserting "watermark" on pages into PDL
stream
S. Accepts data and Outputs transaction
C. Logs successful transaction
S. Logs successful transaction
NOTE: No attempt is made to negotiate support for RFC2301
file formats or GSTN FAX. It is not necessary since there is
no attempt to gateway to GSTN FAX or IFAX services.
7.3 IPP NETWORK SCANNING DEVICE TO GATEWAY FOR ULTIMATE
DELIVERY BY GSTN FAX
A sender is using a network scanning device to imput a
document using IPP to onramp to a fax service bureau which
will ultimately deliver the document to a existing GSTN FAX
machine designated by the operator.
O. Manually create or organize documents for transmission
O. Manually fill out predeveloped cover page form and add to
the documents to be transmitted
O. Insert documents into network scanner device
O. Select IPP facsimile service mode
O. Enter IPP URI of onramp service bureau
O. Enter E.164 address of ultimate destination
O. Begin IPP transaction
S. Request authorization of IPP client via RFC2069 [Digest
Auth]
C. Submit user ID and passcode
C. IPP request to gateway to GSTN FAX at specified E.164
number
C. Negotiate acceptance of PDL
S. PCL5 or TIFF Profile S presented as options
C. Renders documents into PCL5 and submits
S. Converts PCL5 data stream to appropriate format for GSTN
FAX transmission.
S. Completes GSTN transmission
S. Logs successful transaction
C. Polls IPP gateway for transaction record
C. Logs successful transaction
7.4 IPP WORKSTATION TO GATEWAY FOR ULTIMATE DELIVERY BY E-
MAIL
A recipient desires that all inbound IPP transactions to his
personal IPP address be converted to a IFAX message.
O. Sender creates Document on Workstation
O. Select IPP Output Driver from list of available printers
O. Selects Facsimile Service Mode from IPP client
application options menu
O. Enters Cover Page Data into IPP client application
O. Enters IPP URI address of server
C. Begins IPP transaction
S. Negotiation of PDL requirements
C. Renders output of Cover Page Data and "watermarks" pages
into Document PDL stream.
S. Accepts PDL data
C. Logs successful transaction
S. Converts PDL stream to appropriate RFC2301 file format
specified by recipient and submits IFAX message to E-Mail
address specified by recipient.
S. Logs successful transaction
NOTE: It is assumed that the IPP redirection server has
access to some form of internal table or directory service
that has the recipients preferences for reception.
8.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: Dan Wing, Graham Klyne, Carl-
Uno Manros, Larry Masinter
9.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-xx.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
[RFC1894] [DSN] K. Moore, G. Vaudreuil, "An Extensible
Message Format for Delivery Status Notifications", RFC 1894,
January 1996.
[RFC2119] S. Bradner, "Key words for use in RFC's to
Indicate Requirement Levels", RFC2119, March 1997
[RFC2246] T. Dirks, C. Allen, "The TLS Protocol Version
1.0", RFC2246, January 1999
[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) - 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] G. Vaudreuil, and G. Parsons, "Voice Profile for
Internet Mail - version 2", RFC 2421, September 1998.
[IPP-MOD] S. Isaacson, R. deBry, T. Hastings, R. Herriot,
P. Powell, "Internet Printing Protocol/1.0: Model and
Semantics" draft-ietf-ipp-mod-xx.txt, Work In Progress,
June, 1998.
[IPP-PRO] R. Herriot, S. Butler, P. Moore, R. Tuner,
"Internet Printing Protocol/1.0: Encoding and Transport",
Work In Progress draft-ietf-ipp-protocol-xx.txt.
[IPP-REQ] D. Wright, "Design Goals for an Internet Printing
Protocol", Work In Progress draft-ietf-ipp-req-xx.txt.
[IPP-RAT] S. Zilles, "Rationale for the Structure of the
Model and Protocol for the Internet Printing Protocol", Work
In Progress, draft-ietf-ipp-rat-xx.txt.
[IPP-NOT] R. deBry, "Requirements for IPP Notifications",
Work in Progress, draft-ietf-ipp-not-xx.txt.
[IPP-SCHEME] R. Herriot, C. Manros, "Internet Printing
Protocol/NV : IPP URL Scheme", Work in Progress, draft-ietf-
ipp-scheme-xx.txt
[IPP-IMPLEMENTER] T. Hastings, C. Manros, "Internet Printing
Protocol/1.0: Implementers's Guide", Work in Progress,
draft-ietf-ipp-implementers-guide-xx.txt
[VCARD] M. Smith, F. Dawson, T. Howes, "A MIME Content-Type
for Directory Information", RFC2425, September 1998.
F. Dawson, T. Howes, - "vCard MIME Directory Profile",
RFC2426, September 1998.
Additional information at : http://www.imc.org/pdi/
10.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
11.0 COPYRIGHT NOTICE
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
Fax 314.918.9015
INTERNET Mail & IFAX : rshockey@ix.netcom.com
eFAX 815.333.1237
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<