EDIINT Working Group                                         Dale Moberg
Internet draft                                               Dick Brooks
Expires: October 2001                                       Rik Drummond
                                                           April 1, 2001

                     HTTP Transport for Secure EDI

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   To view the current status of any Internet-Draft, please check
   the ``1id-abstracts.txt'' listing contained in an Internet-
   Drafts Shadow Directory, see http://www.ietf.org/shadow.html.

   Any questions, comments, and reports of defects or ambiguities in
   this specification may be sent to the mailing list for the EDIINT
   working group of the IETF, using the address
   <ietf-ediint@imc.org>. Requests to subscribe to the mailing list
   should be addressed to <ietf-ediint-request@imc.org>.


   This document describes how to exchange structured business data
   securely using HTTP transport for EDIFACT, X12, XML or other
   used for business to business data interchange. The data is packaged
   using standard MIME content-types. Authentication and privacy are
   obtained by using CMS (S/MIME) or OpenPGP security body
   parts. Authenticated acknowledgements make use of multipart/signed
   replies to the HTTP POST requests.

   This document extends the procedures and payload packaging options of
   AS1 in the following ways: HTTPS may be used to obtain data privacy,
   both synchronous and asynchronous reply procedures are described,
   multipart/form-data packaging may be used, a generalized
   multipart/report format is added to the MDN format of AS1,
   replies may include a multipart/mixed payload that contains
   both the acknowledgement and an additional EDI payload.

   This document is intended to be read in conjunction with AS1 and
   the referenced RFCs defining the MIME and cryptographic
   packaging that are used to obtain secure, authenticated, and
   acknowledged transport.

Moberg, Brooks, Drummond                                   [page 1]

HTTP Transport for Secure EDI                         April 1, 2001

   Feedback Instructions:

   If you want to provide feedback on this draft, follow these guidelines:

  -Send feedback via e-mail to the ietf-ediint list for discussion, with
   "AS#2" in the Subject field. To enter/follow the discussion, you
   need to subscribe at ietf-ediint@imc.org.

  -Be specific as to what section you are referring to, preferably
   quoting the portion that needs modification, after which you state
   your comments.

  -If you are recommending some text to be replaced with your suggested
   text, again, quote the section to be replaced, and be clear on the
   section in question.

Table of Contents

1.   Introduction
   1.1   Purpose and relation to previous work
   1.2   Overall operation
2.   Stages and Details of HTTP EDI Transmission and Acknowledgment
    2.1   Requesting receipts in the POSTED request
     2.1.1   Requesting MDN-based receipts
     2.1.2   Requesting Generalized receipts
     2.1.3   Summary Remarks on Receipt request options
    2.2    Additional Commonly Used Headers
    2.3    Sending EDI in HTTP POST Requests
    2.4    Using Transport Layer Security for Transmission
    2.5   Response Status Codes in Replies
    2.6    Receipt Reply
     2.6.1   MDN Receipts and Signed MDN Receipts
     2.6.2   Generalized Receipts and Signed Generalized Receipts
    2.7   Additional Reply Content
    2.8   Non-Repudiation of the POST Reply
    2.9   Error Recovery
3.   Other differences between  HTTP and SMTP based transport
    3.1 Unused MIME headers and operations
     3.1.1   Content-Transfer-Encoding not used
     3.1.2   Epilogue must be empty
     3.1.3   Lengthy message bodies and Message/partial
    3.2   Differences in MIME or other headers or parameters used
     3.2.1   Content-Length needed
     3.2.2   Final Recipient and Original Recipient
     3.2.3   Message-Id and Original-Message-Id
     3.2.3   Host header
    3.3   New Options for HTTP transport

A.   AS 2 MIME templates.
B.   Using AS2 Extensions in the GISB Protocol
C.   Samples of AS 2 Protocol Data Units
D.   Acknowledgments
E.   References
F.   Security Considerations
G.   Authors' Addresses

Moberg, Brooks, Drummond                                   [page 2]

HTTP Transport for Secure EDI                         April 1, 2001

1.  Introduction

    1.1 Purpose and relation to previous work

    Early work on Internet EDI focused on specifying MIME content
    types for EDI data [MIMEEDI] The functional requirements
    document , "Requirements for Interoperable Internet EDI,"
    [EDIINT] provides extensive information on EDI security
    and the business and user processes that can benefit
    from the use of EDI security. In addition, MIME structures
    appropriate for SMTP transport of the packaged EDI data are
    specified in ([AS1] "MIME-based Secure EDI" ) as well
    as the details needed to support signed receipts as acknowledgments.
    The framework of [AS1] shows how to implement the security features--
    specifically data privacy, data integrity/authenticity,
    non-repudiation of origin and non-repudiation of receipt --
    found to be requirements for secure EDI.

    In this document, it is assumed that the reader is familiar
    with the SMTP/MIME transport document, the requirements document,
    and the RFCs applied or referenced in those documents.

    This draft, like the SMTP/MIME transport document, builds on
    previous RFCs and is attempting to "re-invent" as little
    as possible.  The goal here is to specify how previously specified
    MIME messaging structures and operations can be adapted for use with
    HTTP servers and clients to obtain secure, reliable,
    and acknowledged transport for EDI and other business data.

    The applicability statement, [AS1] "MIME-based Secure EDI,"
    explained the basic EDI transaction using the concept of a
    "secure transmission loop" for EDI. This loop involves
    one organization sending a signed and encrypted EDI
    interchange to another organization, requesting a signed receipt,
    followed by the receiving organization sending this
    signed receipt back to the sending organization. The transmission,
    therefore, involves the following stages:

       1. The organization sending business data encrypts the data and
       provides a digital signature, using either PGP/MIME or S/MIME.
       In addition, they request a signed receipt.

       2. The receiving organization decrypts the message and verifies
       the signature, resulting in verified integrity of the data and
       authenticity of the sender.

       3. The receiving organization then sends a signed receipt
       using a signature over the hash of a message disposition
       notification, which contains a hash of the received message.

    The above stages describe the functionality that would
    satisfy all security requirements. Applications are expected
    to be able to provide full functionality, though users may
    agree to exchange data using only a restricted subset of

Moberg, Brooks, Drummond                                   [page 3]

HTTP Transport for Secure EDI                         April 1, 2001

    functionality. For example, businesses may agree to send signed data
    using TLS, and only request a simple, unsigned receipt.
    Implementations are expected to be configurable so that they may
    support business community agreements that use subsets
    of the full functionality.

    In this document, the goal is to make use of HTTP instead of SMTP
    as a transport protocol, and make the changes that are needed to
    adapt to protocol packaging differences.

    In either transport case, the body of the message is a MIME
    structure, using MIME headers ("content-type" and other
    "content-X" tags) to convey information about the data
    being transported.

    Also, one primary use of SMTP RFC 822 headers within SMTP based
    transport of secure EDI has been to enable requests for
    acknowledgements and to specify options for signatures over
    acknowledgements (asymmetric encryption and cryptographic
    hash algorithm preferences).

    One way to convey this information within the HTTP transport
    context is to use either HTTP entity-headers or extension-headers
    [11, section 7.1] that have the syntax of SMTP headers. Only the
    "From" header is overloaded by possibly different usages in the
    SMTP and HTTP contexts. The "From" header normally contains
    machine-usable email addresses  as defined in [SMTPMSG]. The
    usage of the "From" header in [HTTP] section14.22 is to provide
    the email address of an administrative contact for the HTTP
    client. The function of the "From" header in the SMTP context of
    secure EDI transport has been to supply a value used in
    constructing the MDN style receipt. But the MDN receipt has been
    found to be too restrictive for some commercial EDI transport
    scenarios [GISB]. So alternative receipt mechanisms will be
    provided that, among other things, will remove any conflicts
    arising from trying to reuse the SMTP-MDN roles of
    "From" within the context of HTTP reserved usage of "FROM".

    Also, it is currently difficult to make use of HTML [HTML]
    and simple scripting to send HTTP entity-headers as part of the
    HTML FORM tag construct. For HTML-based POST situations [GISB],
    it is useful to specify ways to convey 'metadata' needed for the
    secure transmission loop that do not make use of HTTP headers.
    One way to specify this data is by using the MIME
    multipart/form-data packaging specified in [FORMDATA].

    For SMTP transport, the receipt and signed receipt functions are
    implemented using Message Disposition Notifications [MDN]
    and Multipart/signed Message Disposition Notifications [AS1].
    For HTTP transport, generalization of the Message Disposition
    Notification is useful.

    The MDN is a special kind of multipart/report [REPORT]. For
    MDNS, specialization is achieved by assigning the "report-type"
    parameter in the content-type  header the special value,
    "disposition-notification" and by having the second body part

Moberg, Brooks, Drummond                                   [page 4]

HTTP Transport for Secure EDI                         April 1, 2001

    (the "machine-readable" body part) have the MIME content-type,

    To generalize a MDN, all that is needed is to remove the
    restrictions that make the underlying multipart/report into a MDN.
    In other words, the "report-type" parameter [REPORT, section 1]
    is given a new value and the second body part is changed to a
    content-type other than "message/disposition-notification".
    Acknowledgements defined by these changes will be referred
    to as "generalized receipts. Each receipt of this kind will have its
    own specific report-type parameter and its own specifications
    for the syntax and semantics of the automated response body part.
    Implementations are encouraged to be able to register new
    report-type handlers using only configuration changes (not
    recompiling) that specify how to process new report-type values.

    Nothing else needs to be changed to construct reply acknowledgements
    that are not restricted by the semantics of MDNs. Specifically,
    a signed reply will still be constructed by using a multipart/signed
    package to wrap up generalized receipts with their signatures.

    Finally, within the HTTP transport context, it is useful
    to make use of Transport Layer Security [TLS] to provide
    privacy. Compression can be provided using HTTP content-codings
    [HTTP], sections 3.5, 14.3, 14.12]. (Content codings are not be be
    confused with the MIME concept of content transfer encodings.)

    A variety of other minor differences (for example,
    absence of content-transfer-encoding)
    are noted below and summarized in the concluding section.

   1.2 Overall operation

    A HTTP POST operation [HTTP] is used to send appropriately packaged
    EDI, XML, or other business data. The Request-URI ([HTTP],
    section 9.5) identifies a process to unpack and handle the
    message data and to generate a reply for the client that
    contains a message disposition acknowledgement or a
    multipart/report, signed or unsigned, and possibly other
    turnaround transactions. This request/reply transactional
    interchange provides secure, reliable, and authenticated
    transport for EDI or other business  data using HTTP;
    the security protocols and structures used also
    support auditable records of these transmissions,
    acknowledgements, and authentication.

2. Stages and Details of  HTTP EDI Transmission and Acknowledgment

    A data file or stream is first structured into one of the
    message templates described in [AS1], sections 4.2.1 to 4.2.4 or
    4.3.1 to 4.3.4 for PGP/MIME or S/MIME security. In addition
    to the content-types of [MIMEEDI], applications should be
    prepared for handling other content-types used in business to
    business transactions, such as those for XML [MIME-TYPES].
    For convenience, these message templates, adapted for the
    HTTP transport context, are provided in Appendix A below.

Moberg, Brooks, Drummond                                   [page 5]

HTTP Transport for Secure EDI                         April 1, 2001

    If TLS is to be used, the typical packaging will
    be that described in sections 4.2.2 or 4.3.2;
    that is, a multipart/signed message will be created with no
    encryption in the message. Otherwise, if privacy
    is desired, message templates 4.2.4 or 4.3.4 are used.
    Content transfer encoding is not used and a content-length
    field is to be provided.

    If HTML-based POST is used (using the METHOD=POST attribute
    within the "FORM" tag) [HTML, 17 Forms], then the message payload
    will be packaged in the input-data element of a multipart/form-data.
    The metadata needed for application layer routing, identification,
    requesting a reply and other transaction operations
    can be packaged in message body parts in the multipart/form-data.
    The labels for the metadata values are found in the "name"
    parameter of the Content-Disposition header in each form-data
    part as discussed in [FORMDATA, section 3].

    In general, both HTTP servers and HTTP clients handling the message
    templates of [AS1] should be prepared to process these basic EDIINT
    data formats when they are embedded within MIME multiparts.

    In addition to the enveloping and MIME media type options defined in
    sections 4.2.x and 4.3.x of "MIME-based Secure EDI" [AS1], this
    specification enables the transport of payload objects containing
    other MIME media types. Implementors are to follow the
    appropriate specifications identified under "References"
    in [MIME-TYPES], for the type of object being transmitted.
    For example, to send an XML object, the MIME media type
    of application/xml is used in the Content-type MIME header
    and the specifications  for enveloping the object are contained in
    [XMLTYPES]; for example:

        Content-type: application/xml; charset="utf-8"

    Many of the specifications referenced by [MIME-TYPES] were designed
    for SMTP transports. Implementors are advised to make appropriate
    adjustments for HTTP transport as indicated in section 4 of this

    Finally, several industry groups currently make use of
    "encapsulated"(or opaque) signatures within encrypted or
    signed objects. Encapsulated signatures should be supported
    in order to accommodate these existing practices. Objects
    containing encapsulated signatures must be prepared according
    to the specifications contained in  section 3.4.2 of [SMIMEV2]
    or, in the case of PGP, according to the
    specifications contained in section 6.2 of "MIME Security
    with Pretty Good Privacy (PGP)" [MIMEPGP] and
    "OpenPGP Message Format" [RFC2440].

   2.1 Requesting Receipts

   2.1.1  Requesting MDN-based receipts

     For requesting MDN based receipts, the originator supplies
     metadata using the syntax of extension headers
     (the [SMTPMSG] header syntax) that precede the message body.

Moberg, Brooks, Drummond                                   [page 6]

HTTP Transport for Secure EDI                         April 1, 2001

     The header "tags" are as follows:

     A Disposition-Notification-To header is added to indicate
     that a message disposition notification is requested
     in the reply to the POST request. This header is
     specified in [MDN]. It may have values
     other than email addresses, such as a D-U-N-S number,
     when it is found as a name parameter in a form-data body part
     When this tag is used in HTTP extension headers,
     it follows the MDN usage.

     A Message-ID header is added to support message reconciliation,
     so that an Original-Message-Id value can be returned in the MDN
     body part of the receipt. (The term "Receipts" is here used
     to refer to the signed or unsigned multipart/report content.)

     Both "From" and "To" extension headers are to be supplied. The "From"
     value needs to have an email address as specified in [SMTPMSG] and
     [HTTP]. If other uses of "From" are needed, the generalized receipts
     to be next discussed should be used. There the role of "From" is
     replaced by symbols not having a reserved HTTP or SMTP usage.

     Other headers, especially "Subject" and "Date", should be supplied;
     the values of these headers are often mentioned in the
     human-readable section of a MDN to aid in identifying the original

     A Disposition-Notification-Options header is used to request
     a signed message disposition notification. The parameters
     used to select protocols for signed message disposition
     notification are found in [AS1].

     Disposition-Notification-To is a name that, if present, indicates
     that the MDN style of receipt is to be used.

     Disposition-notification-options identifies characteristics of
     message disposition notification in accordance with [AS1] and [MDN].

     A Receipt-delivery-option is a header whose value is a URL
     that indicates how the receipt is to be delivered.
     This header is only used within AS2.
     The default mode of operation is synchronous
     within HTTP transport, which means that the receipt
     (be it MDN, signed MDN, generalized report receipt,
     or signed report receipt) is returned in the reply body.
     By using the "receipt-delivery-option," an asynchronous reply mode
     can be requested. The values for this option are URLs that indicate
     the destination for the reply, and may use any appropriate
     protocol ("mailto", "http", and "https" will
     be the more common types) for this information.
     If this header/metadata is absent, then the mode of operation
     is synchronous, which means that the receipt is returned
     in the reply to the current HTTP request.

   2.1.2 Requesting Generalized Receipts

     In this section, the ways to request generalized receipts
     are specified. Generalized receipts are multipart/reports

Moberg, Brooks, Drummond                                   [page 7]

HTTP Transport for Secure EDI                         April 1, 2001

     with a report-type other than "disposition-notification," and
     a second automated response with a content type other
     than "message/disposition-notification".

     For requesting generalized receipts using the MIME template for
     multipart/reports [REPORTS], the following metadata
     elements will be useful. A specific example of a
     generalized receipt with report-type "GISB-Acknowledgement-Receipt"
     will be presented in appendix B.

     When the term "metadata" is used in the following,
     the term indicates that the
     information may be supplied in one of
     two ways:

     First, the metadata information may be supplied using the
     syntax of HTTP headers. That is, the symbol
     name is followed by a colon and its value follows;
     the header is subject to processing of structured
     field bodies [SMTPMSG, section 3.1.4], also including

     Second, the metadata information may be
     supplied by using the syntax of the "name" parameter within the
     "Content-Disposition" header of the multipart/form-data structure,
     when that MIME packaging [FORMDATA] is used. For example,

          Content-Disposition: form-data; name="Receipt-Report-Type"


     Within HTML, the symbols used for these
     names correspond to the value of the name attribute within
     the INPUT element, where the "type" attribute has a "text" value.
     [HTML], section 18; for example,

         <FORM action="http://somesite.com/responder" method="post">
           <INPUT type="text" name="Receipt-Report-Type">
           <INPUT type="submit" value="Send"> <INPUT type="reset">

     To indicate the various options for generalized receipts, the
     basic metadata that the POSTing client needs to convey to the
     replying server are: "Receipt-Disposition-To",
     "Receipt-report-type",  "Receipt-Security-Selection",
     and "Receipt-Delivery-Option".

     The presence of the metadata value "Receipt-Disposition-To",
     using the extension header syntax, indicates a request
     for a generalized receipt.

     Because HTTP already has a role for the "From" header, the
     "Receipt-Disposition-To" header is used to avoid conflicts
     with [HTTP], when using the header syntax for metadata.
     (Within a multipart/form-data package, the "From" value
     can be used to identify the sending party without any

Moberg, Brooks, Drummond                                   [page 8]

HTTP Transport for Secure EDI                         April 1, 2001

     conflict with HTTP headers.) Notice that the value for
     this identifier need not be an email address or a URL.
     In this way, other systems of identification (such
     as a DUNS number) may be used, if needed. Notice that
     the information needed for delivery of the receipt
     is found in the receipt-delivery-option element
     described below; delivery information is not
     generally needed if the default mode of operation
     occurs. In that case, the receipt just goes back
     in the reply to the current HTTP request.

     "Receipt-Report-Type" indicates the desired value of
     the "report-type" parameter in the multipart/report
     content type of a specific version of the generalized
     receipt. This parameter must be supplied when
     "Receipt-Disposition-To" is used to indicate a request
     for a generalized receipt because this indicates what
     specific type of receipt is desired. An example
     for this value (discussed in appendix A) is

     "Receipt-Security-Selection" is a name that indicates the
     protocol and algorithm choices for a digital signature
     over the receipt. Signatures are always in multipart/signed
     packages. The format for protocol and algorithm choices is
     that used in [AS1] and [MDN]; for example,


     "Receipt-Delivery-Option" is used to indicate the
     URL for asynchronous delivery of the receipt.
     While the default mode of operation within HTTP
     transport is to return the receipt(be it MDN, signed
     MDN, generalized receipt, or signed generalized receipt)
     in the reply body, asynchronous reply is allowed through
     use of this symbol. The URLs will typically use the
     "MAILTO", "HTTP", and "HTTPS" schemes.  For the HTTP and
     HTTPS schemes, the POST method is to be used.

     2.1.3 Summary Remarks on Receipt request options

     Applications are encouraged to support handling all metadata
     values whether they make use of the name parameter syntax
     within a multipart/form-data or whether they use the message
     header syntax used in SMTP or HTTP headers [SMTPMSG]. If
     metadata items are repeated in extension headers and in
     form-data parts, but the values are not the same, the
     extension header values will be selected for use.

     Because the value in Receipt-Disposition-To
     may have no significance for how the receipt is transported,
     the extension header "Receipt-delivery-option"
     is to be used to provide that information.

Moberg, Brooks, Drummond                                   [page 9]

HTTP Transport for Secure EDI                         April 1, 2001

     The receipt-delivery-option's value should be a URL
     indicating the delivery transport destination for the

     The Receipt-delivery-option field is used when
     asynchronous delivery is desired. It should not
     be present if the intention is to deliver
     the reply synchronously; synchonous delivery of
     the reply is the default mode of delivery.

     For signed generalized receipts,
     an extension header of  "Receipt-security-selection" should
     be added to indicate the desired security protocol for the
     multipart/signed over the multipart/report.

     In summary, the receipt request and construction processes now
     have the following options:

       1. Receipt requests are made by conveying metadata
          values using a syntax of either the name parameter in a
          multipart/form-data's Content-Disposition headers or by
          using a syntax of HTTP extension headers.

       2. Both MDN and generalized receipts can be requested using
          either syntax. However, using an extension header syntax
          and requesting a MDN receipt means restricting the "From"
          values to email addresses.

       3. Either type of receipt comes in signed or unsigned versions.

       4. Finally, receipts may be delivered synchronously (delivered
          in the HTTP reply) or asynchronously by using
          the "Receipt-delivery-option" header.

    2.2 Additional Commonly Used Headers

    The following set of header data elements are also available for
    use. Organizations wishing to use this specification for the
    secure and reliable transport of business documents are not required
    to utilize all of these headers and are free to use whatever subset
    they deem appropriate for their business needs.

     The To name contains an identifier identifying the
     intended recipient of a data exchange and may be
     D&B D-U-N-S number [DUNS]  or other agreed upon
     identifier system. Applications should allow users to
     configure these elements in the automated HTTP agents
     processing these values. For example, the body
     part MIME header line looks like the following line:

     Content-Disposition: form-data; name="To"

     The From name contains a textual value identifying
     the sender of a data exchange, such as the a D&B D-U-N-S number
     [DUNS] as in [GISB].   Because "From" has a specified use within
     [HTTP], the From name parameter is not to be considered equivalent

Moberg, Brooks, Drummond                                   [page 10]

HTTP Transport for Secure EDI                         April 1, 2001

     to the extension header. If an extension header "From" is to be
     used it should within HTTP, it should conform to the usage, syntax,
     and semantics of [HTTTP] section 14.22.  The extension header
     counterpart of the sender of a data exchange is the extension
     header version of "Receipt-disposition-to".

     The Input-format name identifies the type of data contained in a
     data file.

     The Agent name parameter indicates the network or agent where the
     data exchange originated.

     The Application name identifies the application used to process
     the data next(after the URI-request process has finished with the

     The DateTime name provides the date and time the data was created
     and uses the format specified in [SMTPMSG] as updated by
     RFC 1123.

     The RefNum is an integer value used to uniquely identify the
     communication exchange and is in a textual format. The RefNum is
     similar to the Message-ID and Content-Id headers of SMTP that
     are used in constructing values in receipts based on  MDNs.

     The UserParam is a user defined parameter.

     Version is a protocol version number [GISB].

     Transaction-set is an optional data element identifying the
     EDI transaction.

     Input-data is the sending side's local file system name
     for the file being sent. The payload is contained as the body
     part of this header element.

     The "Priority" name is used to indicate the processing priority of
     each message relative to other messages sent by a given party.
     The value "1" indicates highest priority and a value of "5"
     indicates the lowest priority.

     The "Expiration" name is used to indicate the date and time at
     which a message is no longer transportable. No message delivery
     should be attempted beyond the date and time specified in
     this value.  The date/time format must follow the specifications
     contained in section 5 of RFC822.

Moberg, Brooks, Drummond                                   [page 11]

HTTP Transport for Secure EDI                         April 1, 2001

    2.3 Sending EDI in HTTP Client Requests using POST

    For sending EDI, the following protocol elements are typically
    present: a request line ([HTTP], section 5.1), entity headers, a
    CRLF pair to mark the end of the entity headers, followed by the

    The request line will have the form: "POST Request-URI HTTP/1.1",
    with spaces and followed by a CRLF. The Request-URI is typically
    exchanged out of band, as part of setting up a bilateral
    trading partner agreement. Applications should be prepared
    to deal with an initial reply containing a status indicating a need
    for authentication of the usual types used for authorizing access
    to the Request-URI ([HTTP], section 10.4.2 and elsewhere).

    Automation of this process is not discussed in this document
    but might involve obtaining a session URL from a page requesting
    authentication and possibly other information about proposed
    EDI standard versions and other trading conventions to be used.

    The request line is followed by entity headers specifying content
    length ([HTTP] section 14.14) and content type [HTTP],
    section 14.18. The Host request header ([HTTP] sections 9 and
    14.23) is also included.

    The entity or extension headers used for requesting a MDN
    (unsigned or signed) have previously been mentioned,
    as have those  ("To" "From" "Message-Id") that are needed as
    values for MDN fields or for other receipt requests.

    For generalized receipts based on the multipart/report content type,
    the metadata can be the values found in extension headers,
    but can also be placed in body parts of a multipart/form-data
    using "name" parameters in the content-disposition header.

    Finally, the payload is found in any of the message patterns
    of [AS1] sections 4.2.1 to 4.2.4 or  4.3.1 to 4.3.4 for PGP/MIME
    or S/MIME security. These payloads may arrive as the "input-data"
    part of the multipart/form-data or may even be enclosed in some
    other multipart.

    2.4 Using Transport Layer Security

    To use Transport Layer Security [TLS], the request-URI should
    indicate the appropriate scheme value, HTTPS. Usually only a
    multipart/signed message body would be sent using TLS, as encrypted
    message bodies would be redundant. Encrypted message bodies are not
    prohibited, however. For asynchronous receipt delivery requests,
    use the  "Receipt-delivery-option" header with a URL value making
    use of the HTTPS scheme to obtain security privacy.

    2.5  Response Status Codes in Replies

    The status line for response to errors in the POST request line
    will be provided by a status line with the following protocol
    elements present ( [HTTP], section 6.1 ) : HTTP version (normally,
    HTTP/1.1), a status code, reason phrase, and CRLF.

Moberg, Brooks, Drummond                                   [page 12]

HTTP Transport for Secure EDI                         April 1, 2001

    The status codes return status concerning HTTP operations. For
    example, the status code 401, together with the WWW-Authenticate
    header, is used to challenge the client to repeat the request
    with an Authorization header. Other explicit status codes are
    documented in [HTTP], sections 6.1.1 and throughout section 10.
    For errors in the request-URI, 400 ("Bad Request"), 404
    ("Not Found") and similar codes are appropriate status codes.
    These codes and their semantics are specified by [HTTP].
    A careful examination of these codes and their semantics
    should be made before implementing any retry functionality
    that is described below; specifically, retries should not
    be made if the error is not transient or if retries are
    explicitly discouraged (for real authentication failures,
    for example.)

    2.6  Receipt Reply

    The details of the response to the POST command vary depending
    upon whether  a receipt has been requested and upon what kind
    of receipt has been requested.

    With no extended header requesting a receipt, and no errors
    accessing the request-URI specified processing, the status
    line in the Response to the POST request should be in the 200
    range. Status codes in the 200 range should also be used when an
    entity is returned (a signed receipt in a multipart/signed
    content type or an unsigned receipt in a multipart/report).
    Even when the disposition of the data was an error condition
    at the authentication, decryption or other higher level, the
    HTTP status code should indicate success at the HTTP level.

    The HTTP server-side application may respond with an unsolicited
    multipart/report as a message body that the HTTP client
    might not have solicited, but this may be discarded by the
    client. Applications should avoid emitting unsolicited receipt
    replies because bandwidth or processing limitations might
    have led administators to suspend asking for acknowledgements.

    When a Disposition-Notification-To extension header is present
    in the POST request entity headers, then entity headers for
    the MDN should be included. The content type for the MDN receipt
    ( multipart/report [REPORT] or multipart/signed [SECURITY])
    should be included in the Response entity headers. The

    The basic responsibilities of responding to requests are discussed
    in [AS1] section 5, and in detail within section 5.2.1.

    2.6.1  MDN based Receipts and Signed MDN Receipts

    Message Disposition Notifications, when used in the HTTP reply
    context, will closely parallel a SMTP MDN. For example,
    the disposition field is a required element in the machine
    readable second part of a multipart/report for a MDN.
    The final-recipient-field([MDN] section 3.1) value should
    be derived from the entity headers of the request

Moberg, Brooks, Drummond                                   [page 13]

HTTP Transport for Secure EDI                         April 1, 2001

    If the "To" field is missing, for signed messages,
    the value for Original-recipient may be the email
    address field from the signer's X.509 attribute for
    email addresses, if that value is available.
    For a MDN, an application must report the Message-ID
    of the request. The human readable part (the first
    part of the multipart/report) should include items
    such as the subject, date and other information
    when those fields are present in entity header fields
    following the POST request

    The HTTP reply should normally omit the third optional part
    of the  multipart/report (used to return the original message
    or its headers in the SMTP context).

  2.6.2  Generalized Receipts and Signed Receipts

    For generalized receipts, the multipart/report [REPORT]
    or a multipart/signed containing a multipart/report
    as the signed data is the basic MIME packaging. Each
    generalized receipt needs a value for the multipart/report
    parameter, "report-type," a selection of a content-type
    for its second body part, when signed, a hash value over
    a defined portion of the original message and,
    when asynchronously delivered, information allowing the
    identification of the original POSTed message.

    The basic structure of the multipart/report is used so that
    the first part is a "human-readable" message concerning the received
    message. The second part should be for automated process utilization.
    It should at least possess some common Internet syntax for
    expressing names and values, such as the [SMTPMSG] header syntax,
    XML, or  some MIME content type correlated with automated

    The MDN requirements, therefore, are removed for this second part,
    but information used in MDNs may be used here.
    The third part of the multipart report is
    usually omitted in the HTTP context, but could include
    the extension headers, or even the entire payload,
    to provide diagnostic information.

    A multipart/signed over a  multipart/report is constructed
    precisely in the same way as a multipart/signed over a MDN [AS1].

    One metadata element should be within the automated part.
    This is the Received-Content-MIC (also allowing
    X-Received-Content-MIC). This value is constructed and formatted
    as described in [AS1] and the syntax should be either RFC822:

          Received-Content-MIC: w7AguNJEmhF/qIjJw6LnnA==,rsa-md5

    or simple XML

          <ReceivedContentMic algid=rsa-md5 encode=base64 >

Moberg, Brooks, Drummond                                   [page 14]

HTTP Transport for Secure EDI                         April 1, 2001

    Any original metadata thought useful to include in the automated
    part may be reflected back using "Original-X", as in

           Original-Message-ID: <43141asfioufasd@somewhere.com>

    Otherwise the automated acknowledgement semantics are left open
    to further semantic specification by specific electronic commerce
    communities, such as in [GISB]. Each specialization of the
    generalized receipt should make use of a specific identifying
    value to be placed in the parameter "report-type,"

            Content-Type: multipart/report;

    Implementations should attempt to be configurable to allow
    for new report-type values to be added;  communities can then agree
    to the specific extensions they need to support application
    level routing, transaction identification, timestamps, and
    other specialized information about the data they have exchanged.

    2.7  Additional Reply Content

    In general, both HTTP servers and HTTP clients should be prepared
    to process the basic EDIINT data formats when they are embedded
    within MIME multiparts. This is true for HTTP request payloads
    as well as HTTP reply payloads.

    So, as previously mentioned, for HTML-based POSTS,
    any of the EDIINT templates described in [AS1],
    sections 4.2.1 to 4.2.4 or
    4.3.1 to 4.3.4 for PGP/MIME or S/MIME security,
    may be found as parts of a multipart/form-data.
    [Consult Appendix A for the templates adapted for this document.]

    In addition, the response to the POST operation may include other
    MIME wrapped content besides an MDN Receipt, Signed MDN,
    Generalized Receipt or Signed Generalized Receipt. If a receipt was
    requested within the POST data, and additional content is to be
    returned, the receipt multipart/report must be combined with the
    other data using some MIME multipart pattern.
    Real-time EDI processing systems may use MIME
    multipart content-types to include a response EDI message,
    for example, a Quote in response to a Request-For-Quote transaction.

    Also, if requested, the sender may request an asynchronous mode
    for return of receipt. This mode is indicated by including the
    metadata for Receipt-delivery-option as explained above.

    2.8  Non-Repudiation of the POST Reply

    If the reply to a POST operation needs a MDN receipt for non-
    repudiation (for example, the reply includes content other than
    a receipt), the top-level headers in the response include
    the same headers required for POST data described above:
    Disposition-Notification-To, Message-ID, From, and To. Other
    headers described above used in a MDN should be included,
    for example, Date and Subject.

Moberg, Brooks, Drummond                                   [page 15]

HTTP Transport for Secure EDI                         April 1, 2001

    The MDN receipt of the response data is returned using
    a subsequent POST operation. A POST operation used only
    to transmit an MDN should not include the Disposition-
    Notification-To receipt request, and only a 200 ("OK") response
    would be expected.

    An MDN in response to a reply may be combined with a
    subsequent EDI message sent with a POST operation, for example
    a Purchase-Order transaction in response to a Quote. The MIME
    multipart/mixed form is used to combine the MDN with the other
    data, the same as for a POST reply.

   2.9  Error Recovery

   If the HTTP client fails to read the HTTP server
   response data, the POST operation with identical content (including
   Message-ID, RefNum, and other header elements) should be repeated,
   if the error condition is transient.

   The Message-ID or RefNum on a POST operation can be reused if and only
   if all of the content (including the original Date) is identical.

   Details of the retry process -- including time intervals to pause, number of
   retries to attempt, timeouts for retrying -- are implementation dependent.

   Servers should be prepared to receive a POST with a repeated Message-ID.
   The MIME reply body previously sent should be resent, including the MDN
   and other MIME parts.

3.  Other differences to notice in HTTP and SMTP based transport

    For HTTP version 1.1, TCP persistent connections are the default,
    ([HTTP] sections 8.1.2, 8.2, and 19.7.1).

    A number of other differences exist because HTTP does not
    conform to MIME [MIME] as used in SMTP transport. Relevant
    differences are summarized below.

  3.1 Unused MIME headers and operations

   3.1.1  Content-Transfer-Encoding not used in HTTP transport

    HTTP can handle binary data and so there is no need to use
    the Content transfer encodings of MIME [MIME]. This difference
    is discussed in [HTTP] section 19.4.4.

   3.1.2  Epilogue must be empty

    The EBNF for a multipart [MIME] RFC 2046, section 5.1.1 allows
    a multipart to have trailing octets after the close delimiter.
    In [HTTP] section 3.7.2, it is explicitly noted that multiparts
    must have null epilogues.

   3.1.3  Lengthy message bodies

    In [AS1], section 5.4.1, options for large file processing are
    discussed for SMTP transport. For HTTP, large files should
    be handled correctly by the TCP layer. However, [HTTP] sections

Moberg, Brooks, Drummond                                   [page 16]

HTTP Transport for Secure EDI                         April 1, 2001

    3.5 and 3.6 discuss some options for compressing or chunking
    entities to be transferred. Section discusses a
    pipelining option that is useful for segmenting large
    amounts of data.

  3.2 Differences in MIME or other headers or parameters used

   3.2.1  Content-Length

    Because connections are persistent, closing a connection
    cannot be used to indicate the end of an entity. Therefore,
    [HTTP] sections 4.4 and 14.14 indicate the need for a
    Content-Length entity header in a request.

   3.2.2 Final and Original Recipient

    The final and original recipient distinction should not
    arise for HTTP transport because SMTP aliases and mailing
    lists should not be used.

   3.2.3 Message-Id and Original-Message-Id

    The Message-Id and Original-Message-Id distinction should not
    arise for HTTP transport because SMTP MTA alterations should
    not occur.

   3.2.4 Host header

    The host request header field must be included in the
    POST request made when sending business data. This field
    is to allow one server IP address to service multiple
    hostnames, and potentially conserve IP addresses.
    See [HTTP], sections 14.23 and 19.5.1.


A.  AS 2 MIME templates

Structure of an AS2 MIME message - PGP/MIME

No encryption, no signature (analog of 4.2.1)

     -RFC1767/RFC2376 (application/EDIxxxx or application/xml)

No encryption, signature (analog of 4.2.2)

     -RFC1847 (multipart/signed)
       -RFC1767/RFC2376 (application/EDIxxxx or application/xml)
       -RFC2015 (application/pgp-signature)

Moberg, Brooks, Drummond                                   [page 17]

HTTP Transport for Secure EDI                         April 1, 2001

Encryption, no signature (analog of 4.2.3)

     -RFC1847 (multipart/encrypted)
       -RFC2015 (application/pgp-encrypted)
         -"Version: 1"
       -RFC2015 (application/octet-stream)
         -RFC1767/RFC2376 (application/EDIxxxx or application/xml) (encrypted)

Encryption, signature (analog of 4.2.4)

     -RFC1847 (multipart/encrypted)
       -RFC2015 (application/pgp-encrypted)
         -"Version: 1"
       -RFC2015 (application/octet-stream)
         -RFC1847 (multipart/signed)(encrypted)
           -RFC1767/RFC2376 (application/EDIxxxx or application/xml)(encrypted)
           -RFC2015 (application/pgp-signature)(encrypted)

Structure of an AS2 MIME message - S/MIME

No encryption, no signature (analog of 4.3.1)

     -RFC1767/RFC2376 (application/EDIxxxx or application/xml)

No encryption, signature (analog of 4.3.2)

     -RFC1847 (multipart/signed)
       -RFC1767/RFC2376 (application/EDIxxxx or application/xml)
       -RFC2633 (application/pkcs7-signature)

Encryption, no signature (analog of 4.3.3)

     -RFC2633 (application/pkcs7-mime)
       -RFC1767/RFC2376 (application/EDIxxxx or application/xml) (encrypted)

Encryption, signature (analog of 4.3.4)

     -RFC2633 (application/pkcs7-mime)
       -RFC1847 (multipart/signed) (encrypted)
         -RFC1767/RFC2376 (application/EDIxxxx or application/xml) (encrypted)
         -RFC2633 (application/pkcs7-signature) (encrypted)

B.AS2 Extensions for the GISB Protocol and Report-type

GISB AS2 Profile

The United States based Gas Industry Standards Board (GISB) is a
consortium of companies and individuals that operate in the Gas
Industry. The membership is divided into 5 sectors, Producers,
Pipelines, Services, End Users, Local Distribution Companies,

Moberg, Brooks, Drummond                                   [page 18]

HTTP Transport for Secure EDI                         April 1, 2001

representing the various type of organizations within the industry.
In 1996 GISB initiated a program to move from the expensive Value
Added Networks they were using, to the Internet. By October of 1996
GISB had developed and tested a protocol, called GISB Electronic
Delivery Mechanism (EDM), which uses HTTP and is based on RFC1867
(Form-based File Upload in HTML). By April 1997 this protocol was
being used by Enron and others to send/receive live, mission
critical business transactions over the Internet.  Additional
companies followed suit and a large percentage of today's
business transactions in the Gas Industry are transmitted over the
Internet using the GISB EDM protocol. In 1998 the Automobile
Industry Action Group (AIAG) adopted the GISB EDM protocol and in
1999 the local electric companies serving the state of Pennsylvania
declared the GISB protocol as their standard for transmitting
business transactions via the Internet.

In May of 1999 the AIAG, GISB and members of the IETF EDIINT
workgroup initiated an effort to converge their independent
specifications, the result of which is this specification. In order
to bring the GISB EDM into compliance with this specification GISB
initiated a formal change to the EDM specification. The following
information, referred to as the "GISB AS2Profile", reflects the
planned utilization of this specification by the GISB membership.

The GISB membership will utilize PGP to meet all P.A.I.N. requirements.
All data exchanges will utilize the multipart/form-data enveloping
method and two generalized receipts, GISB-Acknowledgement-Receipt and
GISB-Error-Notification. All original business transactions must be
digitally signed (using encapsulated signatures) and encrypted using
RSA algorithms. Upon successful transfer of an original business transaction
the receiver is required to send a GISB-Acknowledgement-Receipt indicating
that the transfer has completed successfully. If, upon further processing
of the business document an error is encountered a GISB-Error-Notification
is sent to the original sender using the multipart/form-data enveloping.

It is expected that companies following the GISB AS2 profile will protect
their web sites from unauthorized access through the use of basic
authentication (username/passwords), as defined in the HTTP specification.

GISB is not "requiring" the use of signed receipts; however, signed
receipts are allowed between consenting trading partners.

GISB has decided to use the following core headers:

Contains the DUNS number of the sending party

Contains the DUNS number of the intended recipient

Type of data being sent (only x12 and error currently
supported) other options can easily be added to this list.

The actual payload containing the business transaction or
GISB-Error-Notification.  If the payload contains a business
transaction it is signed and encrypted using PGP.

Moberg, Brooks, Drummond                                   [page 19]

HTTP Transport for Secure EDI                         April 1, 2001

The GISB version number (currently 1.3)

The DUNS number of the party to receive the
GISB-Acknowledgement-Receipt (typically the
same DUNS number associated with the From header.)
Presence of this field also serves as a
flag indicating that an acknowledgement
receipt is requested by the sender. The receipt is
returned synchronously (on the same session used
to send the input-data payload).

Contains the value GISB-Acknowledgement-Receipt.

Optional headers also available:

Identifies the type of transaction contained in the
input-data payload.

This field serves as a flag indicating that a
signed receipt is being requested. The contents
of this field indicate the algorithm and
signature type to use in constructing the signature.

Example of a GISB data exchange:

The sending party creates an X12 business transaction and concatenates with
an RFC 1767 compliant header. The entire package is then encrypted and
signed using PGP. The encrypted package is then enveloped with the
appropriate headers/values and sent to the trading partner using HTTP POST,
the contents of this post appear as follows:

POST c:\execute HTTP/1.0
Referer: http://www.get.a.life/upl.htm
Connection: Keep-Alive
User-Agent: brow v0.1 XYZ Corp.
Host: localhost
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Content-type: multipart/form-data;
Content-Length: 5379

Content-Disposition: form-data; name="from"

Content-Disposition: form-data; name="to"


Moberg, Brooks, Drummond                                   [page 20]

HTTP Transport for Secure EDI                         April 1, 2001

Content-Disposition: form-data; name="Version"

Content-Disposition: form-data; name="receipt-disposition-to"

Content-Disposition: form-data; name="receipt-report-type"

Content-Disposition: form-data; name="input-format"

Content-Disposition: form-data; name="input-data";
Content-Type: multipart/encrypted; boundary=8760;

Content-Type: application/pgp-encrypted

Version: 1

Content-Type: application/octet-stream

Version: PGP 6.5




Upon receiving the above stream of data the receiving host parses the
headers and returns an unsigned
GISB-Acknowledgement-Receipt, appearing as follows:

Content-Type: multipart/report;
  report-type="GISB-Acknowledgement-Receipt"; boundary="GISB7867"


Moberg, Brooks, Drummond                                   [page 21]

HTTP Transport for Secure EDI                         April 1, 2001

Content-type: text/html

<HTML><HEAD><TITLE>Acknowledgement Receipt Success</TITLE></HEAD>
</P> </BODY></HTML>

Content-type: text/plain



C. Samples of AS 2 Protocol Data Units

C.1 The following example illustrates the full HTTP request that sends
    X12 EDI data from company1 to company2. A signed receipt is requested;
    the receipt is to be a MDN report-type, with the pkcs7 signature option,
    using a signature algorithm of rsa-md5.

    The receipt is to be sent synchronously (that is, in the reply to
    this HTTP request), because no special delivery options are indicated.

POST https://tp2server.company2.com/cgi-bin/tp1drawer.pl HTTP/1.1
Host: tp2server.company2.com
To: tp2@company2.com
Date: Tue, 06 Nov 2001 12:53:01 UT
Subject: Purchase orders for 6 November 2001
Message-Id: <20011106@company1.com>
Disposition-Notification-To: tp1@company1.com
Disposition-Notification-Options: signed-receipt-protocol=optional,
    pkcs7-signature; signed-receipt-micalg=optional,rsa-md5
Content-Type: multipart/signed; boundary="20011106RsXgYlvCNW";
    protocol=application/pkcs7-signature;  micalg=rsa-md5
Content-Length: 3056

Content-Type: application/edi-x12
Content-Disposition: Attachment; filename=rfc1767.dat
Content-Length: 2605

  [ISA ...EDI transaction data...IEA...]
Content-Type: application/pkcs7-signature
Content-Length: 804

  [omitted binary pkcs7 signature data]

C.2 This second example illustrates returning a signed MDN
    that corresponds to the request for a MDN found in C.1.

Moberg, Brooks, Drummond                                   [page 22]

HTTP Transport for Secure EDI                         April 1, 2001

HTTP/1.0 200 OK
Server: HTTPEDI/1.1
Content-type: multipart/signed; boundary="boundary1"
Content-Length: 1200

Content-type: multipart/report; boundary="boundary2"
Content-length: 1133

Content-type: text/plain
Content-length: 85

Message <20011106@company1.com> was authenticated;
EDI processing was initiated.

Content-type: message/disposition-notification
Content-length: 213

Reporting-UA: Company2UA
Final-Recipient: rfc822; tp2@company2.com
Original-Message-Id: <20011106@company1.com>
Received-Content-MIC: w7AguNJEmhF/qIjJw6LnnA==,rsa-md5
Disposition: MDN-sent-automatically/processed


Content-Type: application/pkcs7-signature
Content-Length: 560

[ Signature data omitted]

D. Acknowledgments

   Carl Hage, Karen Rosenfeld, Chuck Fenton
   and many others have provided valuable suggestions
   improving this applicability statement.

E. References

[MIME]  N. Borenstein,  N.Freed, "Multipurpose Internet Mail Extensions (MIME)
     Part One: Format of Internet Message Bodies", RFC 2045,
     December 02, 1996.

     N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME)
     Part Two: Media Types", RFC 2046, December 02, 1996.

     N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME)
     Part Five: Conformance Criteria and Examples", RFC 2049 , December 02,

[MIMEEDI]  D. Crocker, "MIME Encapsulation of EDI Objects",  RFC 1767,  March
     2, 1995.

Moberg, Brooks, Drummond                                   [page 23]

HTTP Transport for Secure EDI                         April 1, 2001

[XMLTYPES]  E. Whitehead, M. Murata, "XML Media Types", RFC 2376, July 1998.

[SMTPMSG]  D. Crocker, "Standard for the Format of ARPA Internet Text
     Messages", STD 11,  RFC 822,  August 13, 1982.
    (Also RFC 1123 provides important updates on date and time formats
    as well as email addresses.)

[MIMEPGP]  M. Elkins, "MIME Security With Pretty Good Privacy (PGP)",  RFC
     2015, Sept. 1996.

[MDN]  R. Fajman, "An Extensible Message Format for Message Disposition
     Notifications", RFC 2298, March 1998.

[SECURITY]  J. Galvin, S. Murphy, S. Crocker, N. Freed,  "Security Multiparts
     for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847,
     Oct. 3, 1995

[SMTP]  J. Postel, "Simple Mail Transfer Protocol",  STD 10, RFC 821,
     August 1, 1982.

[SMIMEV2]  S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka,
     "S/MIME Version 2 Message Specification", RFC 2311.

[SMIMEV3]  B. Ramsdell, "S/MIME Version 3 Message Specification",
     RFC 2633, June 1999.

[CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999.

[REPORT] G. Vaudreuil, "The Multipart/Report Content Type for the
     Reporting of Mail System Administrative Messages",  RFC 1892,
     January 15, 1996.

[HTTP] R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners-Lee,
     "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068,
     January 1997.

[AS1] T. Harding, R. Drummond, "MIME-based Secure EDI", Internet draft:

[TLS] T. Dierks,C. Allen, "The TLS Protocol Version 1.0" RFC 2246,
     January 1999.

[FORMDATA] L. Masinter, "Returning Values from Forms:  multipart/form-data",
     RFC 2388, August, 1998.

[HTML]  D. Raggett, A. Le Hors, I. Jacobs. "HTML 4.0
      Specification", World Wide Web Consortium Technical Report
      "REC-html40", December, 1997. <http://www.w3.org/TR/REC-html40/>

[GISB] Gas Industry Standards Board, "Electronic Delivery
       Mechanism Related Standards", Version 1.3 July 31, 1998

[MIME-TYPES] "Media Types," http://www.isi.edu/in-notes/iana/assignments/

[EDIINT] T. Harding, R. Drummond , "Requirements for Interoperable Internet
       EDI",Internet draft: draft-ietf-ediint-req.txt.

Moberg, Brooks, Drummond                                   [page 24]

HTTP Transport for Secure EDI                         April 1, 2001

F. Security Considerations

   This entire document is concerned with secure transport of business to
   business data, and considers both privacy and authentication issues.

G.  Authors' Addresses

Dale Moberg
Sterling Commerce
4600 Lakehurst Ct.
Dublin, OH 43016 USA

Dick Brooks
Group 8760
110 12th Street North
Suite F103
Birmingham, Alabama 35203
Tel: 205-250-8053

Rik Drummond
Drummond Group
5008 Bentwood Ct.
Ft. Worth, TX 76132 USA

Moberg, Brooks, Drummond                                   [page 25]