Janaury '99 Article
INTEGRATING for peripherals
Fax Integration Using XML Technology
by Dave Droman and Gila Jones
advancements that have been made in communications software, some people find it difficult
to understand why anyone would want to talk about fax within the network as a technically
advanced communication medium. Since email, paging, voice, and the Web have transformed
the way businesses communicate as we approach the 21st century, why talk about fax? Four
simple reasons: fax is ubiquitous; fax is reliable; fax is immediate, and fax is the
dominant form of written business communications today.
International Data Corporation has predicted that the network fax industry will grow to
over $1 billion in sales in the year 2000 with a compound annual growth rate of 44
percent. This impressive projection can be easily justified based on the compelling
benefits of network fax, from extending fax capability from the desktop to fax-automating
business-critical applications to utilizing least-cost routing methods to avoid high
long-distance telecommunications charges.
The Fax Problem
In order for the network fax to be truly effective, it needs to be integrated
into end users applicationseverything from word processing to ERP, sales force
automation to purchasing. As it stands today, there is no standard means of communicating
between (1) fax servers and the applications that need faxing services and (2) among
various fax servers or fax service providers across a network, including the Internet. The
problem arises from the custom integration of each application to a particular fax
vendors solution; there is no standard way to pass content from an application to a
This problem has significant side effects. It results in application-to-fax
integrations, which are (1) not supported by the application vendor; (2) difficult to
support by the fax vendor; and (3) vary from one fax server to the next. The same set of
issues applies to fax server interfaces with fax service providers or with fax servers
from another vendor. Interfaces are custom-developed, and built in a way that minimize the
chances of interoperability.
The Solution: XML-F
To solve these problems, VSI has created a common faxing interface using XML,
called XML-F. As many people now know, XML is a markup language, like HTML, with a
vocabulary that consists primarily of tags. HTML was specifically designed for
marking up documents to communicate how they should be formatted for display on the World
The purpose of XML is far more open-ended, but in general it is a
meta-language intended to be used to define other standard markup languages
(known as Document Type Definitions or DTDs) that can be used to allow different systems
to exchange information in a standard, process-readable format. Businesses can define
their own vocabulary of XML tags and rules that are embedded within the DTD inside the XML
document or made publicly available to any program that wants to comply with the
agreed-upon information exchange format. The use of XML-specific parsers eliminate the
burden of parsing and validating XML interchange documents, reducing the work and support
required to implement an application reading XML.
The benefits of developing such a common interface for network fax are numerous:
1. A leveraging of the efforts of application vendors, integrators, and fax server
vendors to make fax services ubiquitous in the world.
2. Fax interoperability, resulting in decreased pain/friction for customers and
expanded opportunities for the fax server industry.
3. Faster adoption of the Internet for fax toll bypass.
4. Reduction of the work required for fax integration, thereby permitting the customer
and fax vendor to use additional engineering and support resources on more beneficial
projects (like customer training or product testing).
5. The possibilities of making network fax a more attractive communications alternative
to integrators looking for a ubiquitous messaging delivery system.
6. Increases in likelihood of rapid network fax take-up because the same ease of access
provided with fax machines would become available for network fax servers.
The set of DTDs for network fax transactions called XML-F is a simple,
powerful interface for passing fax transactions to and from fax servers. It is based on
three simple structures that allow any conforming application to send a fax, get the
status of a sent fax, and cancel a fax (Fig 1).
XML-F Application Domain
Most applications create a document in some standard printable format (either
text, PCL, or PostScript) and then create a separate list of fax-sending parameters, which
identify who the fax is going to, what their fax number is, who is sending it, and some
other standard cover sheet information.
This information is transported to the fax server (either through an API, or by
dropping the file into a specific network location polled by the fax server) and the fax
server is responsible for transporting the fax being sent to the designated fax machine.
If something goes wrong with the fax transmission, the fax server will respond to the user
via email or to the sending application through the API.
There are other integrations that require tighter response and additional capability by
the application; that is, the application itself needs to know and record the completion
and status of the sent fax and update some internal database of that event. With XML-F,
the application requests status from the fax server on the particular fax-submittal and
the fax server responds in kind with a short or detailed fax status report (also delivered
as an XML document).
In some cases, the application can provide the user with the ability to cancel an
in-process transaction, and this capability is also frequently provided in an
application-to-fax integration. Fig 2 outlines the six transfers that occur in a fully
implemented XML-F system XML-F is transport-independent. In the same way that HTML files
can be retrieved over HTTP or emailed over SMTP/MIME or shared across file systems, so too
is XML-F. The structure of XML-F lends itself to either synchronous or asynchronous
transport models, although a synchronous model is assumed.
The Fax-Submit Document
The fax-submit document describes the elements necessary to send a fax on an
XML-F compliant system.
The fax-submit entity provides attributes for response-format, resolution, priority,
and coversheet. The response-format attribute specifies the format of the response to this
request. A response is sent to indicate the outcome of the fax submit. The coversheet
attribute specifies that a coversheet is to be included on the service sidenot a
selection of a particular coversheet.
The account contains the information necessary to identify the user of the service.
Authentication is left to the transport and implementation, the account structure contains
an id intended to identify the billing entity and a sub-id to be used for grouping of
departments or users within the billing entity. The account also requires a mail address,
which is an email channel available for the fax service to use for error or mandatory
The recipient defines one or more people for whom this fax transmission is ultimately
intended. A fax submission must have at least one recipient; however, the recipient need
only have a fax-number defined. The sender is a required entity with at least the
personal-name defined for the sender. The subject is an optional entity.
The content element contains one or more body elements. Body elements may specify
associated content-type (RFC 2046) and content-transfer-encoding (base64 or none). An
application-reference tag is defined to permit the submitting application to provide an
arbitrary application-specific reference to this fax request. This reference tag may be
used to request status information on this fax submission.
All XML-F requests may carry a command-reference, which is intended for the sending
system to uniquely identify this particular request. This is useful for debugging and
matching up particular responses with particular requests when the system is used
Upon successful receipt of a valid fax-submit, a fax-submit-response will be returned.
This process is explained in the next section.
The Fax-Submit-Response Document
Upon receipt of a fax-submit request, an XML-F service should respond by
providing a fax-submit-response. This response is used to acknowledge receipt of the fax
submission upon parsing and validation of the request. The response is used to provide a
The service-reference is the unique reference assigned to this particular fax
submission by the service provider. This is the best reference for the user application to
use when requesting status or when canceling this request. The application-reference is
the optional (but recommended!) reference that the submitting application applied to the
fax request precipitating this response. This reference may be used to get status or to
cancel the request if the application has not received a fax-submit-response (and
therefore no service-reference is known). The request-results provide information on the
results of the fax-submit. Request-results contain attributes to indicate the status of
the request (normal, warning, or failed) and the reason for the status. The data attached
to the request-results entity provides an ad hoc message back to the application.
The Fax-Status Document
The fax-status document is used by an application to request status on a service
about a particular fax request. The fax-status request can be used to request short and
detailed status reports in either XML or text-formatted form. In addition, the fax-status
request can ask the service to mail the resulting report to an email address.
The application can use either the application-reference or the service-reference when
referring to this request. This permits the submitting application to issue status
requests without having to wait or process a fax-submit-response document prior to asking
for status. Indeed, in the event the fax-submit-response is never received, the
application must use the application-reference to get information on the request.
The Fax-Status-Response Document
The fax-status-response document provides the detailed information about what
happened (or is happening) to a fax request on an XML-F service.
The Fax-Cancel Document
The fax-cancel document is used by a sending application to cancel a previously
submitted fax request. The application can use either the application-reference or the
service-reference when referring to this request. This permits the submitting application
to issue cancel requests without having to wait or process a fax-submit-response document
prior to canceling a fax.
The Fax-Cancel-Response Document
The fax-cancel-response document is generated by the service upon receipt and
processing of a fax-cancel request. This response is used to provide feedback on the
results of the fax-cancel request.
The request-results provide information on the results of the fax-cancel.
Request-results contain attributes to indicate the status of the request (normal, warning,
or failed) and the reason for the status. The data attached to the request-results entity
provides an ad-hoc message back to the application.
XML-F And Other Standards Efforts
Other worthwhile efforts have been made to unify network fax transactions. Here
is how XML-F differs or is compatible with some of those efforts.
First, in keeping with the philosophy of simplicity, XML-F does not specify a transport
but a format for data. Therefore, the whole issue of whether XML-F is exchanged via SMTP,
HTTP, FTP, or a file system is left up to the implementation. The advantages of having a
common file format exchange for fax transactions is in and of itself of significant
benefit to integrators. Since XML-F implies no transport, it might easily be used in
addition to certain fax-over-the Internet schemes as merely a different and more
extensible way of representing the data of a fax transaction.
Second, XML-F is the first proposed implementation of a fax interchange method to be
based on XML. This permits all implementers of XML-F to utilize freely available parsers
and other tools in pursuit of implementing this methodology. Other efforts require custom
parsing or require network fax to use only the namespace or functionality available in the
existing messaging model.
Third, XML-F may be extended to support additional needs of applications and additional
capabilities of fax servers, since XML-F does not rely upon an existing messaging
structure for communicating the necessary service parameters. Therefore, it is possible
that XML-F could be expanded to support configuration parameters or least-cost-routing
schemes in advanced implementations.
Will the fax industry be able to overcome some major obstacles and achieve the growth
that has been predicted by industry experts? With the use of a common interface like XML-F
for application-to-fax-server interoperability and for fax-server-to-fax-server
communication, one major threat to the industrys aggressive growth will be
Dave Droman is CEO and Gila Jones is the product manager at
V-Systems, Inc. (San Juan Capistrano, CA).