INTEGRATING for peripherals

by Dave Droman and Gila Jones

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 applications—everything 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 vendor’s solution; there is no standard way to pass content from an application to a fax server.

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 Wide Web.

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 side—not 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 messages.

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

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 server-side reference.

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 industry’s aggressive growth will be eliminated.

Dave Droman is CEO and Gila Jones is the product manager at V-Systems, Inc. (San Juan Capistrano, CA).