Chapter 29

Fulfillment

CONTENTS

• FAX
• E-Mail and FTP
• EDI

After the visitor has found your site, examined the merchandise, and made a selection after the customer has put items in the shopping cart, selected a payment mechanism, and ordered the products…after the Web site has done its job, it's time for you to go to work.

The Web technology described in the preceding four chapters culminates in getting the order to the site owner, either in e-mail form or in a file. If the site owner is also the manufacturer of the products, or if the products consist of information stored in files that can be sent to the customer, then filling the order is straightforward. If the site owner is a retailer responsible for sending the order to a manufacturer or fulfillment warehouse, then one more step is required to complete the purchase-coordinating the order with the fulfillment center.

Some fulfillment centers are operated by manufacturers; other centers are operated as a business in their own right. Regardless of who operates it, a warehouse somewhere contains the material your customers want. Once the site owner has established a business relationship with the fulfillment center, it's often possible to send a message to the center for each order, specifying the ship-to address and particular products to ship. The fulfillment center then picks the order and sends it out via a delivery service. Fulfillment centers often use computer-directed picking. The picking may be automated (as with an automated storage and retrieval system, or AS/RS), directed (using computer terminals linked by radio that tell the picker where to go and what to get), or paper-based (with a printed pick list given to each worker)-in any of these methods, the picking is driven by the fulfillment center's computer.

The interface between the Web site and the fulfillment center has the potential to be labor-intensive. If a human operator has to read e-mail from the Web site and phone it in to the fulfillment center-or fill out an order form-some of the profit from the order might be wiped out. The smart site owner finds a way to link the order from the Web site directly to software at the fulfillment center.

FAX

The "least common denominator" for communicating with a fulfillment center is the FAX machine. While some centers are able to accept orders electronically, practically all businesses today have FAX machines. If the site owner can get the order to the fulfillment center's FAX machine, she may be able to transfer the data-entry cost to the fulfillment center. As long as the volume is modest, FAXing may be an acceptable solution.

There are two ways to send a FAX from a Web site. The first, shown in Figure 29.1, is to send e-mail to a gateway site that then sends the same message by FAX. The second, shown in Figure 29.2, is to locally operate a FAX server that converts the file to FAX format. Both solutions are available for purchase from commercial sources, or as a service from free or very-low-cost providers.

Figure 29.1 : An e-mail-to-FAX gateway typically serves a limited geographical area.

Figure 29.2 : A FAX server sends out FAXes to any destination for local clients.

E-Mail-to-FAX Gateways

Unlike many Internet services, FAX gateways care about where they're located. A FAX gateway in Boston might be able to deliver FAXes in that city at little or no cost, but might refuse FAXes for destinations outside its local calling area. For this reason, many gateway services offer preferential (sometimes even free) rates for FAXes destined for their local area.

A relatively current list of gateways is available by anonymous FTP at ftp://rtfm.mit.edu/pub/usenet/news.answers/internet-services/fax-faq. The same list is on the Web at http://www.northcoast.com/savetz/fax-faq.html.

Free Services

The leading free FAX gateway service, TPC.INT, was experimental and has been discontinued. The results of the experiment are archived and can be obtained by sending e-mail to tcpfaq@info.tpc.int. The TPC approach allowed a user to send a message to, for instance, remote-printer.Arlo_Cats/Room_123@12025551234.iddd.tpc.int. The TPC.INT service pulled out the phone number (in this case 1-202-555-1234) and then looked up the area code and exchange in a coverage list. If it found a cooperating cell serving that area, it sent the message to that cell. Once at the cell, the remote-printer service used the message information to build a cover sheet-in this case, the following:

Arlo_Cats
Room 123

The TPC software is still available; many universities and a few companies offer the service for their local areas. A recent copy of the fax-faq file cited above lists free services in the following locations:

• Sweden
• The Netherlands
• The Philippines (Iligan City, metro Cebu, and metro Manila)
• Kuwait
• New Zealand
• California's north coast
• Sacramento, California
• Portions of Minnesota
• Phoenix, Arizona
• Calgary, Alberta, Canada
• Vancouver, British Columbia, Canada
• Winnipeg City, Manitoba, Canada
• Quebec, Quebec, Canada

Commercial Services

Commercial services have an obvious disadvantage (they cost something), but they're more likely to actually deliver your message and far less likely to "go dark" without
warning.

A recent release of the aforementioned fax-faq file listed commercial services serving the following areas:

• Moscow and the former USSR
• India
• Western Europe
• Israel
• Latvia
• Metro Washington DC
• The entire world (through FAXiNet and InterFax)

Some of these services have information available on the Web. For example, visit http://www.awa.com/faxinet/. Prices vary widely, depending upon your FAX volume and the service's monthly maintenance fees. One company, Interpage, offers a gateway service that bills the recipient. This approach is useful if the fulfillment house agrees to pay the FAX bill. For more information, visit http://www.interpage.net/.

Some services offer a free "test drive." To test Faxaway, potentially one of the least
expensive services, visit http://www.faxaway.com/testdrive/. General information is available at http://www.faxaway.com/. More detailed information is available at http://www.flexquarters.com/main/faxout.htm.

FAX Servers

Depending upon many factors (not the least of which is where the FAX gateway is with respect to the destination FAX), a single-page FAX costs anywhere from below a dollar to three dollars or more (U.S.). For many site owners, these costs are well above what they would pay to place a long-distance call from their site to the fulfillment house. As volume grows, these site owners often decide to add a FAX modem to their server and send the FAX directly.

FAX 101

Before exploring the variety of FAX software solutions, it's useful to review how FAXes work.

FAXes send information by an entirely different set of protocols than data modems. This fact is sometimes lost on the user, since modern modems usually have the capability to send and receive both data and FAX. Technical details on FAXes are available at http://www.faximum.com/faqs/fax/ or by anonymous FTP at http://www.cis.ohio -state.edu/hypertext/faq/usenet/fax-faq/part1/faq.html and http://math-www.uio.no/faq/fax-faq/part2.html. Table 29.1 highlights the differences between the data modulation standards and the FAX modulation standards.

Most people know that FAX machines have a "Group" standard. Group I and Group II machines are virtually obsolete. Group IV is a 64 Kbps standard that runs over the Integrated Services Digital Network (ISDN), an emerging standard. For now, nearly all FAX communications are Group III. This standard is set by the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T), a United Nations agency made up in part of the old CCITT. Group III is made up of several ITU-T standards, including T.4 and T.30.

These standards allow for a variety of options on each end of the conversation. The called machine can send Called Subscriber Information (a CSI frame) with the international phone number of the called machine. Similarly, the calling machine can send Transmitting Subscriber Information (a TSI frame).

A DIS frame contains feature information such as resolution, page size, and receiving speed. The two machines exchange DIS frames, then set the conversation to use a compatible subset of their individual capabilities.

The ITU-T standard for image transmission is T.4. This standard covers page size, resolution, transmission time, and coding schemes. The standard resolution is 3.85 scan lines per millimeter (about 98 dots per vertical inch) and 1,728 pixels across a scan line of 215 millimeters (about 204 dots per horizontal inch). "Fine" resolution changes the vertical resolution to 7.7 scan lines per millimeter (about 196 dpi) while leaving the horizontal resolution unchanged.

You can readily find print engines designed for computer printers that print at 300¥300 dpi and up, and many FAX modems support this higher resolution, but manufacturers differ on how this resolution is invoked. Consequently, even if two modems from different manufacturers have compatible resolutions, the caller might be unable to tell the called machine about that capability. In such cases, the machines fall back to standard resolution and an A4 page size.

T.30 specifies that a FAX call proceeds through five phases:

• Phase A: Call Setup-The call is placed over the Public Switched Telephone Network. The calling station emits a distinctive tone called the 1100 Hz CNG (Calling Tone) to announce that it's a FAX. The called station acknowledges with a similar tone, called CED, at 2100 Hz.
• Phase B: Pre-Message Procedure for Identifying and Selecting Facilities-The two machines negotiate various features. The called machine optionally sends a CSI frame. The calling machine sends a DIS frame and, optionally, a TSI frame. The calling machine sends a Digital Command Signal, or DCS frame, which specifies the transmit parameters. Finally, the two machines exchange training and phase data to determine the fastest speed the link can support.
• Phase C: Message Transmission-The image is sent in accordance with ITU-T standard T.4.
• Phase D: Post-Message Procedure including End-of-Message, Confirmation, and Multi-Page Procedures-The calling machine can ask to send another page, terminate the call, or ask the called machine to signal for a human operator. The called machine indicates its response by a series of codes including OK, OK but Retrain, and not OK.
• Depending upon the messages exchanged in Phase D, the call proceeds to Phase B, C, or E.
• Phase E: Call Release-The two machines hang up.

FAX calls made by computer are also governed by EIA/TIA-578 (Class 1) and either
SP-2388 or ANSI-592 (Class 2 and Class 2.0, respectively). This is where the concepts become complicated.

The Class 1 standard gives the computer low-level control over the FAX call. Most of the protocol (T.30) and image generation (rasterizing and T.4 compression) is done in software. A Class 1 implementation has the advantage that a protocol change can be implemented by distributing new software, rather than waiting for the modem manufacturer to ship a new modem. The disadvantage of Class 1 is that T.30 is a complex protocol with tight timing requirements. Multitasking operating systems such as UNIX might have difficulty meeting the timing constraints.

Class 2 modems implement most of the T.30 protocol in the modem, while the computer is responsible for rasterizing the image and compressing it into a T.4-compliant bitstream. Most modern modems try to implement Class 2. Unfortunately, Class 2 took an unusually long time to make it through the approval process, and once the technical specifications had settled down, many manufacturers used the draft standard as the basis for building modems. Many modems adhere to the first draft of the TR29.2 committee (known as document SP-2388 and dated March 21, 1990), denoted in text as "Class 2."

The official standard was finally released as EIA/TIA/ANSI-592 and is denoted in text as "Class 2.0" to keep it separate from the draft standard. Many modem manufacturers are moving to adopt Class 2.0 while preserving compatibility with Class 2.

To make matters even more complex, the Rockwell chip that serves as the basis for most Class 2 modems differs from SP-2388 in several ways, and manufacturers brought out many DOS programs that support the Rockwell implementation. Consequently, some modem manufacturers offer a "Rockwell-compatibility mode" that supports some (but not necessarily all) of the Rockwell differences.

The bottom line is that a Webmaster who wants to install a FAX server must carefully match the FAX modem and FAX software. Most FAX software comes with a list of "tested and approved" modems, but modem technology is one of the fastest-changing branches of electronics. The fact that a FAX server and FAX modem work together today does not mean that the next version of the software will work with the next version of the hardware.

Some modems support Class 1 as well as one or more of Class 2, Class 2.0, or Class 2-Rockwell. Which command set is actually used depends upon the FAX server software. For example, HylaFAX (described later in the "Free Software" section) works with the FAX modems shown in Table 29.2. The HylaFAX FAQ reports that HylaFAX should work with any Class 1, Class 2, or Class 2.0 FAX modem.

Legend:

Free Software

One of the most popular free FAX servers is HylaFAX, previously known as FlexFAX. Written by Sam Leffler at Silicon Graphics, HylaFAX provides a seamless service accessible over a LAN. It produces a cover sheet, converts the document to image format, and makes the call. It can support advanced options such as remote FAX machine polling and automatic notification of FAX status. Figure 29.3 shows how a FAX server such as HylaFAX works over a LAN.

Figure 29.3 : Many clients can share a single FAX modem using a client/server architecture.

For a low price, Ready-to-Run Software (RTR) offers a compiled version of FlexFAX, bundled with cover sheets and other utilities, as FAXPak. For more information, visit http://www.rtr.com/. RTR reports good results with most Class 2 modems, and specifically recommends the ZyXEL line and the MultiModemZDX from Multi-Tech Systems. RTR sells both of these modem types.

Webmasters interested in compiling their own copy (or obtaining a pre-compiled version of HylaFAX for certain machines) should visit the overview, http://info-sys.home.vix.com/flexfax/overview.html, and the FAQ, http://info-sys.home.vix.com/flexfax/FAQ/index.html. Question 4 of the FAQ lists the requirements that a UNIX system must meet to support HylaFAX:

• FIFO special files
• BSD-style sockets and TCP/IP communications protocols
• BSD-style file locking (flock) or equivalent functionality
• POSIX 1003.1-style interfaces, including termios

Table 29.3 lists the systems known to support these features, and shows whether or not a pre-compiled binary is available.

HylaFAX also can be configured as an e-mail-to-FAX gateway. Figure 29.4 shows how this configuration works.

Figure 29.4 : Remote users can access the FAX server through an e-mail gateway.

You can FAX graphics by converting them to TIFF Class F documents. You also can send graphics and text using PostScript. sendfax, the portion of HylaFAX that manages the submission process, passes PostScript and TIFF Class F files directly to the HylaFAX server. To handle other formats (such as ASCII text), any machine where imaging is to be done must have a PostScript-to-FAX imaging utility. RTR supplies Ghostscript; there are links to the GNU source for this utility at the HylaFAX site.

To set up Ghostscript, perform the following steps:

1. Follow the Ghostscript documentation to set up the makefile.
2. Add tiffg3.dev to the list of Ghostscript devices.
3. Build the gs executable.
4. Use the -h option to ensure that the tiffg3 driver is present:
   

   gs -h
   Available devices:
        x11     tiffg3     tiffg4

   
   
5. Run make install to install gs.
6. Install Ghostscript fonts as necessary.

Another off-the-Net piece of software that simplifies faxing is tiffmerge. This software allows the installer to save the form separately from the data. Then only the data has to be rasterized-the data can be merged with the existing form before it's sent. tiffmerge is available on the RTR FAXPak mentioned earlier.

Commercial Software

Several commercial products are available to address this niche. For example, Faximum (http://www.faximum.com/) has been well-received by reviewers at various UNIX publications. Its site includes a review that ran in the November 1992 issue of UNIX Review. For sites that prefer (or require) corporate support, Faximum is a good choice.

E-Mail and FTP

As fulfillment houses have become more sophisticated, they have begun moving toward Electronic Commerce, which includes the specialized area of Electronic Data Interchange (EDI). True EDI, which adheres to rigorous standards and often is delivered over special networks, is discussed later in the "EDI" section. This section addresses ways to deal with fulfillment houses that are ready to connect their computers to the Internet but aren't ready to invest in full EDI.

You Know It's EDI When…

A site owner can send e-mail to a wholesaler ordering merchandise at any time, but that doesn't make the exchange EDI. EDI is characterized by four factors:

• Accepted standard messages, such as EDIFACT or X12, are used.
• There's direct processing of most messages by the receiving computer system.
• A prior relationship between the trading partners is unnecessary.
• Security is a factor in the communications.

The third factor might seem a bit odd. For many purchases, there's little need for a sales representative to contact a buyer personally. For commodity items, such personal contact prior to the sale represents an added expense for the seller that must be passed on to the buyer. The value added by such salespeople has traditionally been to make the buyer aware of their company as a supplier.

True EDI is conducted mostly over specialized value-added networks (VANs). These VANs serve to "introduce" trading partners who have no prior business relationship. Although each VAN is different, here's how EDI generally works:

1. Sellers register their businesses on one of the VANs, using standardized codes to identify what goods or services they sell.
2. Buyers post Requests for Quotations (RFQs) to the VANs in a standardized format.
3. The VAN delivers RFQs to the appropriate sellers by e-mail.
4. A seller analyzes each RFQ and prepares a bid, which is posted on the VAN.
5. The VAN delivers the RFQ back to the buyer.

If the seller wins the bid, the buyer sends a PO message back through the VAN. A contract award message is posted, and in many cases (for example, if the buyer is the U.S. Government), the winning price is announced.

There are two major sets of standards used in EDI. The international standard, promulgated by the United Nations, is called EDIFACT. The U.S. standard is called X12. The ISO adopted EDIFACT in 1987 as its standard. The U.N. and ANSI have announced that, as of 1997, EDIFACT and X12 will be merged.

Much of the impetus behind EDI has come from the U.S. Government. On October 26, 1993, President Clinton signed an Executive Memorandum requiring federal agencies to implement the use of electronic commerce in federal purchases as quickly as possible. The order specified that by the end of fiscal year 1997, most U.S. Federal purchases under $100,000 must be made by EDI.

The President's order formed the Federal Electronic Commerce Acquisition Team (ECAT) that generated the guidelines for the federal EDI initiative. ECAT has since been reorganized into the Federal Electronic Commerce Acquisition Program Office (ECA-PMO); its documents (and those of ECAT) are available on the Net at ftp://ds.internic.net/pub/ecat.library/. Many of the documents are distributed in PDF or PostScript form. See Chapter 33, "How to Add High-End Graphics." The ECA-PMO also operates a Web site at http://snad.ncsl.nist.gov/dartg/edi/fededi.html courtesy of the National Institute of Standards and Technology (NIST).

The federal implementation guidelines for purchase orders (in ftp://ds.internic.net/pub/ecat.library/fed.ic/ascii/part-22.txt) provide over 100 pages of details on how the U.S. Government interprets X12 transaction set 850 (described later in more detail in the "ASC X12" section).

RFC 1865, dated January 1996 and titled "EDI Meets the Internet," was written by a small team led by Walter Houser of the U.S. Department of Veterans Affairs, and reflects part of the federal focus and enthusiasm for EDI. Although much of EDI is conducted through VANs, Houser et al. points out that the EDI standards allow almost any means of transfer and that the Internet is well-suited for most EDI functions. The RFC quotes the ECAT as saying, "The Internet network may be used for EDI transactions when it is capable of providing the essential reliability, security, and privacy needed for business transactions."

Although the largest portion of federal EDI is conducted over the VANs, Houser et al. makes a strong case that tools are available on the Internet today to provide this essential reliability, security, and privacy.

UN/EDIFACT

The United Nations promulgates a set of rules "for Electronic Data Interchange For Administration, Commerce and Transport" (UN/EDIFACT). The full standards are available online at http://www.premenos.com/. Each document type (known in EDI circles as a transaction set) is quite robust. For example, a purchase order can specify multiple items or services, from more than one delivery schedule, with full details for transport and destination as well as delivery patterns.

To send a purchase order using UN/EDIFACT, the buyer sends an ORDERS message, which has three sections-Header, Detail, and Summary-as shown in Table 29.4.

Additional complexity is concealed within these segments. For example, the structure of UNH (message header) is shown in Table 29.5.

Some of these components themselves are structured. Table 29.6 shows the structure of component S009 (message identifier), and Table 29.7 shows the structure of component S010 (status of the transfer).

Components whose names start with "C" are coded. For example, one of the components of BGM (beginning of message) is C002 (document/message name). Table 29.8 shows the structure of C002.

Component 1001, in turn, is chosen from a code list; for example, 105 is a purchase order. Component 1131 is a qualifier; for example, 158 means "terms of delivery." Component 3055 is a list of agencies-for example, Dun & Bradstreet is 16, Israeli Customs is 149, and the U.S. Automotive Industry Action Group is 167.

The full UN/EDIFACT standard is available online via gopher at gopher://infi.itu.ch. Go to Entry 11 (UN and international organizations). Choose Entry 1 (UN EDITRANS, US/EDIFACT), then Entry 3 (UN-EDIFACT standards database), then Entry 1 (Publications). The actual standards are at Option 1, "Drafts." Draft D93A becomes standard S94a, D94a becomes the following year's standard, and so on.

As an alternative to gopher, you can get the standards by e-mail. Send a message to itudoc@itu.ch containing the following body:

START
GET ITU-1900
END

ASC X12

The U.S. standards accrediting body is the American National Standards Institute (ANSI). ANSI defines EDI through its Accredited Standards Committee X12, and the EDI standard has taken on the name of that committee.

To send a purchase order using X12, the buyer uses transaction set 850. Table 29.9 shows the segments of transaction set 850.

Not every element is required. Table 29.10 shows the details of some commonly used fields.

Element 143 (Transaction Set Identifier Code) takes on one of the X12 code values; for example, the value for a purchase order is 850.
Element 329 (Transaction Set Control Number) is a unique number within the transaction set functional group.
Element 353 (Transaction Set Purpose Code) is another code value; for example, 00 means "original."
Element 92 (Purchase Order Type Code) is another code value; for example, NE means "new order."
Element 355 (Unit or Basis for Measurement Code) is another code value; for example, EA means "each."

The Grand Unification

UN/EDIFACT and X12 are due to be merged, and many firms already are using one of these two standards as the basis for their in-house standard. For example, Table 29.11 shows the segment hierarchy used by Staples Office Supplies for a purchase order.

The resemblance of the Staples system to X12 is apparent.

Secure E-Mail

EDI is associated with real money and is a natural target of thieves. Here are a few ways that a thief can take advantage of unsecured EDI:

• Placing false purchase orders and stealing the merchandise
• Changing the ship-to address of a legitimate purchase order to divert merchandise
• Intercepting a seller's bid and undercutting the price
• Monitoring how often a seller reports that it's out of stock in response to an order, to gauge production capacity

To combat these problems, EDI needs two kinds of security:

• Digital signatures, including non-repudiation
• Encryption

Both needs can be met using the public key encryption systems that were introduced in Chapter 17, "How to Keep Portions of the Site Private."

PGP

PGP (Pretty Good Privacy) is a private implementation of public key cryptography by Phil Zimmerman. His software is widely available in the U.S. and overseas, and a commercial version also is available.

PGP can provide encryption and digital signatures, as well as encryption of local files using a secret key algorithm.

The PGP code is open for inspection, and has been vetted thoroughly. It's not based on open standards (Internet RFCs), however, so it's not often named as part of an EDI or near-EDI communications standard.

PEM

Privacy-Enhanced Mail (PEM) is defined in RFCs 1421 through 1424. PEM provides three major sets of features:

• Digital signatures, including non-repudiation
• Encryption
• Certification

Certification deals with the issue of trust. For example, suppose that Bob sends a signed, encrypted message to Alice. He has to have Alice's public key-if someone can slip in the wrong key and convince Bob that it's Alice's key, then that person subsequently can read Bob's message (see Fig. 29.6).

Figure 29.5 : Anyone who can trick Bob into using the wrong key can read the message that Bob intended for Alice.

Figure 29.6 : Anyone who can trick Alice into accepting the wrong key can forge a message from Bob to Alice.

Alice needs to know Bob's public key so that she can verify the signature. If someone can convince her to accept a forged key, then that person can send messages to her that appear to be from Bob (see Fig. 29.6). The potential for abuse in EDI is obvious.

To reduce the likelihood of such forgeries, various certification hierarchies have been devised. If Bob and Alice know each other, they can exchange public keys through a private channel (for example, they can hand floppy disks to each other). If Bob and Alice are prospective trading partners, however, they probably have had no prior contact.

When Bob sends his first message to Alice using PEM, he can include a certificate from someone else saying that this public component really belongs to Bob. If Alice trusts the third party who has digitally signed the certificate, then Alice presumably can trust that the key presented as Bob's really belongs to Bob. We say "presumably" because the real strength of the certification lies in the certification policy of the third party. If he or she issues certificates to anyone who asks, then his or her certificates aren't worth much. If, on the other hand, he or she requires three forms of personal ID, then his or her certificates have a higher value.

There are legitimate needs for certification authorities at different levels of assurance. A commercial authority preparing certificates that will be used to sign contracts requires a higher level of assurance than a low-assurance authority whose certificates are used for non-commercial purposes. This discussion ultimately leads to the question of who certifies the certifiers.

The Internet PCA Registration Authority (IPRA) described in RFC 1422 has been designated to certify certification authorities (CAs). The "PCA" refers to Policy Certification Authority.A PCA is responsible for defining a certification policy and enforcing it among the CAs that it certifies.

Initially, IPRA is being operated by MIT on behalf of the Internet Society (ISOC). The plan is to transition IPRA to the Internet Society as soon as the Society is ready.

A hierarchy of PCAs and CAs is set up through IPRA, which intends to certify PCAs offering a range of levels of assurance. CAs then apply to PCAs for certification. Many CAs at the company or university level will certify users in much the same way as they now issue ID cards. Some CAs will require much higher (that is, commercial-grade) certification. Many CAs will want to certify under more than one PCA. For example, a company might issue a low- or medium-assurance certificate to all employees who are on the Internet, but a high-assurance certificate to buyers who are authorized to legally commit the company to a transaction (such as a purchase).

A portion of a certification path is shown in Figure 29.7.

Figure 29.7 : Each certificate is dependent upon the one above it in the hierarchy-when one certificate expires, the path expires.

For more information on the IPRA, read RFC 1422, visit http://bs.mit.edu:8001/ipra.html, or send e-mail to IPRA at ipra-info@isoc.org.

Mark Riordan has released a non-commercial program that implements much of PEM. It's called Riordan's Implementation of PEM (RIPEM) and is available to U.S. and Canadian citizens (or permanent immigrants to either country); information on getting access to the software is available at ftp://ripem.msu.edu/pub/crypt/GETTING_ACCESS.

Trusted Information Systems has released a non-commercial reference implementation of PEM named TIS/PEM. TIS/PEM has since been superseded by TIS/MOSS, the TIS MIME Object Security Services. TIS/MOSS extends TIS/PEM in that TIS/MOSS provides digital signature and encryption for Multi-purpose Internet Mail Extensions (MIME) objects. Thus, many types of files-documents in many formats, graphics, video, and even sound-can be signed and encrypted. TIS/MOSS supports the certification structures described earlier.

X.400

X.400 is the Open System Interconnect (OSI) mail standard that competes with various Internet standards. The Internet standards are developed using a fairly streamlined process based on circulation of Requests for Comments (RFCs) and voting by the Internet Engineering Task Force (IETF). X.400 is promulgated by the CCITT (now part of the ITU-T), so it has the force of international standardization behind it. The way international standards are set, various telephone companies play a significant role in the process, which some observers believe leads to unnecessarily complex standards. It's certainly true that few readers would describe the international standards as well organized or clearly written. Incompatible or non-conforming software often can be traced to differing interpretations of the standards documents.

The formal standards are spelled out in two sets of recommendations:

• Recommendations X.400, CCITT SG 5/VII, Message Handling Systems: System Model-Service Elements, dated October 1984
• Recommendations X.400/ISO 10021, CCITT SG 5/VII ISO/IEC JTC1, Message Handling: System and Service Overview, dated April 1988

Internet purists argue that X.400 has all the elegance of a standard designed by committee. X.400 fans argue back that the Internet was developed piecemeal, and that newfeatures must be grafted in-these features can't be a natural part of the design. For a detailed analysis of these arguments, see The Internet Message: Closing the Book with Electronic Mail by Marshall T. Rose (Prentice-Hall, 1993).

The U.S. Government has been a strong supporter of OSI, so X.400 is likely to play an important part in the continuing federal EDI initiative. On the other hand, the Internet is growing far more quickly than X.400 and is likely to overtake anything that might be done in X.400.

File Transfer Protocol

Once two trading partners have "found" each other (possibly through e-mail or a VAN), they might decide to exchange documents using the Internet File Transfer Protocol (FTP). They agree on whether to use X12 or EDIFACT, and then they establish FTP directories and give each other the password to their EDI directories.

Security

For sensitive documents, two trading partners might agree also to use a public key encryption system such as PGP or PEM. They then set up a blind "drop-box" for incoming documents, and an anonymous FTP "pickup center." Documents intended to be world-readable, such as RFQs, are placed in the FTP directory unencrypted, but with a digital signature from the originator. Sensitive documents such as quotes are signed by the seller and then encrypted using the buyer's public key; finally, they're placed in the drop-box. If anyone breaks the receiving system's security (or steals the message from the Internet), that person is unable to read the message or change its contents.

FTP Macros

The FTP macro capability documented in Chapter 12, "Forms for Batching Processes," can be used in FTP directories to cause certain programs to run on the FTP host. These scripts can be used to extract data from the firm's business software on demand, rather than storing all documents in an FTP directory.

FTP Programming

If an application requires tighter integration than that provided by the FTP macros, a developer can write a program that obeys the FTP protocol but provides custom back-end processing. In his 1990 Prentice-Hall book UNIX Network Programming, W. Richard Stevens shows how to implement Trivial File Transfer Protocol (TFTP), a simpler relative of FTP. Stevens' example requires over 2,000 lines of C code to provide a client and a server. Although some of this code consists of comments, the real FTP is more complex than TFTP. By the time your firm is ready to modify FTP, you're ready to start considering commercial EDI solutions.

EDI

While something resembling EDI can be done by sending X12 or EDIFACT messages over the Internet (by e-mail or through FTP), true EDI is based on the assumption that the application at one end is talking to the application at the other end. If humans have to format and send-or receive and reformat-the messages, much of the benefit of EDI is lost.

Mapping Software

A number of firms, including Premenos (at http://www.premenos.com/) and TSI International (at http://www.tsisoft.com/), provide software that integrates with the client's business system on one side and the EDI standards on the other. Figure 29.8 illustrates this software.

Figure 29.8 : Commercial EDI software maps from the client's business system to the EDI standards.

Some of this software, such as Templar from Premenos (http://www.templar.com/), offers confidentiality, integrity, authentication, and non-repudiation of origin as well as receipt. These companies also offer "shrink-wrapped" EDI that is set up for dealing with a specific major trading partner or industry.

Versions of EDI software are available for all machines from desktop models to mid-range UNIX boxes to MVS mainframes.

VANs

VANs once offered the only secure, reliable interface between trading partners. Surveys conducted during that time showed that most users were unhappy with their VAN, citing poor performance and high costs as reasons for dissatisfaction.

With the booming popularity of the Internet, more companies are looking for ways to leave their VANs. Many VANs, in response, are connecting to the Internet, hoping to deal with users' complaints as well as grow the size of their market. To see an example of a VAN that's aggressively promoting its services over the Internet, visit http://www.compnet.com/. The FAQ at http://www.compnet.com/faq.html is particularly useful. It contains price details, specific setup instructions for Macintosh and Windows machines, and information about how to begin to receive and respond to federal RFQs immediately.

Internet EDI

The Internet is destined to play a larger role in EDI. A number of companies have banded together in a nonprofit consortium named CommerceNet to explore the general area of electronic commerce via the Internet. This consortium's FAQ is at http://www.commerce.net/information/faq.html. Also at that site is the charter of the CommerceNet EDI Working Group, which says in part that it will do the following:

"Define an architecture that links buyers, sellers, and service providers through the Internet as well as proprietary networks…"

One of the group's objectives is the following:

"Support alternative business models where communications flow within a VAN, across VANs bridged by the Internet, or entirely on the Internet."

More detailed information on the progress of bringing EDI to the Internet is available by subscribing to the IETF-EDI mailing list. Send a message to listserv@byu.edu with the following message body:

sub ietf-edi yourname