view Side-By-Side changes

EDIINT Working Group                                     Dale Moberg
Internet draft                                           Dick Brooks
Expires: November 2002                                           Rik Drummond
                                                       David Fischer
                                                            May 2002
Expires: July 2003                                	 
                                                       
                                                         January 2003

                HTTP Transport for Secure Peer-to-Peer
              Business Data Interchange over the Internet

                     draft-ietf-ediint-as2-11.txt

                     draft-ietf-ediint-as2-12.txt
	

Status of this Memo
  
  This document is an Internet-Draft and is in full conformance 
  with all provisions of Section 10 of RFC2026.
  
  Internet-Drafts are working documents of the Internet Engineering 
  Task Force (IETF), its areas, and its working groups.  Note that 
  other groups may also distribute working documents as Internet-Drafts.  

  Internet-Drafts are draft documents valid for a maximum of six 
  months and may be updated, replaced, or obsoleted obsolete by other 
  documents at any time. It is inappropriate to use Internet Drafts Internet-Drafts 
  as reference material or to cite them other than as "work in 
  progress."
  
  The list of current Internet-Drafts can be accessed at  
  http://www.ietf.org/ietf/1id-abstracts.txt
  
  The list of Internet-Draft Shadow Directories can be accessed at  
  http://www.ietf.org/shadow.html.

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

  Copyright Notice
  Copyright (c) The Internet Society (2002). All rights reserved.


  NOTE FROM WG LEADER: This draft has been extensively rewritten from 
  draft-ietf-ediint-as2-11.txt to enhance clarity. The previous draft
  attempted to combine two means of accomplishing the objectives which
  made the draft very clumbersom and greatly contributed to the lack of
  clarity. This draft extends the AS1 functionality to HTTP, drops PGP and gib??
  In the event that gib?? is still required as and ietf standard i recommend
  we do it as AS3.


  
Moberg,  Drummond,                               	[page 1]

HTTP Transport for Secure EDI                               Jan 2003




Abstract

  This document describes how to exchange structured business data 
  securely using HTTP transport transfer for XML, Binary, Electronic Data 
  Interchange, (EDI - either the American Standards Committee X12
  or UN/EDIFACT, Electronic Data Interchange for Administration, 
  Commerce and
   Transport), XML Transport) or other data describable in MIME used 
  for business to business data interchange. The data is packaged 
  using standard MIME content-types. Authentication and privacy are 
  obtained by using Cryptographic Message Syntax (S/MIME) or OpenPGP 
  security body parts. Authenticated 
  acknowledgements make use of   multipart/signed replies to the HTTP POST requests.

   This document extends repliesto 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

Moberg, Brooks, Drummond, Fischer                           [page 1]
  original HTTP Transport for Secure EDI                               May 2002

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

Feedback Instructions:

NOTE TO RFC EDITOR:  This section should be removed 
  by the RFC editor prior to publication.

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

   - Send

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

   - Be

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

   - If
  -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 Transmission and Acknowledgment  Overview
   2.1   Requesting Receipts
      2.1.1   Requesting MDN-based receipts
      2.1.2   Requesting Generalized receipts
         2.1.2.1   Additional Commonly Used Headers
      2.1.3   Summary Remarks on Receipt request options   Overall operations
   2.2   Sending   Purpose of a security guideline for MIME EDI in HTTP POST Requests
   2.3   Using Transport Layer Security   Definitions
   2.4   Response Status Codes in Replies
    2.5   Receipt Reply
      2.5.1   MDN Receipts and Signed MDN Receipts
      2.5.2   Generalized Receipts and Signed Receipts
    2.6   Additional Reply Content
    2.7   Non-Repudiation of the POST Reply
    2.8   Error Recovery   Assumptions
     2.4.1   EDI process assumptions
     2.4.2   Flexibility assumptions

3.  Other differences between HTTP and SMTP based transport   Referenced RFCs
  3.1   Unused MIME headers and operations
      3.1.1   Content-Transfer-Encoding not used   RFC 2616 HTTP v1.1


Moberg, Brooks,  Drummond, Fischer                               	[page 2]

HTTP Transport for Secure EDI                               May 2002

      3.1.2                               Jan 2003


  3.2   RFC 1847 MIME Security Multiparts
  3.3   RFC 1892 Multipart/report
  3.4   RFC 1767 EDI Content
  3.5   RFC 2045, 2046, 2049 MIME
  3.6   RFC 2298 Message Disposition Notification
  3.7   RFC 2633, 2630 S/MIME Version 3 Message Specifications
  3.8   RFC 2376 XML Media Types

4.   Structure of an AS2 message
  4.1   Introduction
  4.2   Structure of EDI MIME message

5.   HTTP Considerations
  5.1   Sending EDI in HTTP Post Requests
  5.2   Unused MIME headers and operations
    5.2.1   Content-Transfer-Encoding not used
    5.2.2   Epilogue must be empty
      3.1.3
    5.2.3   Lengthy message bodies
    3.2   Differences in
  5.3   Modification of MIME or other headers or parameters used
      3.2.1
    5.3.1   Content-Length
      3.2.2
    5.3.2   Final Recipient and Original Recipient
      3.2.3
    5.3.3   Message-Id and Original-Message-Id
      3.2.4
    5.3.4   Host header
4.  Additional AS2 specific Header
  5.4   HTTP headers
    4.1 Response Status Codes
  5.5   HTTP Error Recovery
6.   AS2 Headers
  6.1   AS2 Version Header
    4.2
  6.2   AS2 System Identifiers
         4.2.1  Unrecognized System Identifiers

A.   AS2 MIME templates.
B.   Using AS2 Extensions in the GISB Protocol
C.   Samples
7.   Structure and Processing of AS2 Protocol Data Units
D.   Acknowledgments
E.   References
F. an MDN Message
  7.1   Introduction
  7.2   Synchronous and Asynchronous MDNs
  7.3   Requesting a signed receipt
    7.3.1   Signed receipt considerations
  7.4   MDN Format
    7.4.1   AS2-MDN General Formats
    7.4.2   AS2-MDN Construction
    7.4.3   AS2-MDN Fields
    7.4.4   Additional AS2-MDN Programming Notes
  7.5   Disposition Mode, Type, and Modifier
    7.5.1   Disposition Mode Overview
    7.5.2   Successful Processing Status Indications
    7.5.3   Unsuccessful Processed Content
    7.5.4   Unsuccessful Non-Content Processing
    7.5.5   Processing Warnings
    7.5.6   Backwards Compatibility with Disposition Type, Modifier, and 
              Extension
  7.6   Receipt Reply Considerations in a HTTP Post
8.   Public key certificate handling
9.   Security Considerations
G.
10. Acknowledgements
11. References
12. Authors' Addresses

Appendix
A.  Message Examples
B.  IANA Registration Form


Moberg, Drummond                                                  [page 3]

HTTP Transport for Secure EDI                               Jan 2003



1.   Introduction

1.1  Purpose and relation to previous work

    Early
  
  Previous work on Internet EDI focused on specifying MIME content types 
  for EDI data [MIMEEDI] The functional requirements [2] and extending this work to support secure EC/EDI 
  transport over SMTP [4].  This document , "Requirements for Interoperable Internet EDI,"
    [EDIINT] provides extensive information expands on EDI RFC 1767 to specify
  a  comprehensive set of data security and the
    business and user processes that can benefit from the use features, specifically data privacy, 
  dataintegrity/authenticity, non-repudiation 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 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. over HTTP.  This draft, like the SMTP/MIME transport document, builds on
    previous document also recognizes contemporary RFCs
  and is attempting to "re-invent" as little as possible.  The goal While this document
  focuses on EDI data, any other data type describable in a MIME format 
  are also supported.  
 
  Internet MIME based EDI can be accomplished by using and complying 
  with the following RFC's :
  *       -RFC 2616 Hyper Text Transfer Protocol 
  *       -RFC 1767 EDI Content Type
  *       -RFC 2376 XML Media Types
  *       -RFC 1847 Security Multiparts for MIME
  *       -RFC 1892 Multipart/Report
  *       -RFC 2045 to 2049 MIME RFC's
  *       -RFC 2298 Message Disposition Notification
  *       -RFC 2630, 2633 S/MIME v3 Specification
  
  Our intent here is to specify define clearly and precisely how previously specified
    MIME messaging structures these are used 
  together, and operations can what is required by user agents to be adapted for use compliant with this 
  document.

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
  "SHALL   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 
   "MAY", and  "OPTIONAL" in this document are to be interpreted as 
  described in RFC 2119.

2.   Overview
  2.1   Overall Operations
         A HTTP servers POST operation [3] is used to send appropriately packaged 
         EDI, XML, or other business data. The Request-URI ([3], section 9.5)
         identifies a process to unpack and handle the message data and clients to obtain 
         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
    acknowledged  authenticated transport for
         EDI and or other business data.

    The applicability statement, [AS1] "MIME-based Secure EDI,"

Moberg, Brooks, Drummond, Fischer                           [page 3]

HTTP Transport for Secure EDI                               May 2002

    explained the basic EDI transaction data using the concept HTTP. The security protocols and
         structures used also support auditable records of these transmissions,
         acknowledgements, and authentication.
2.2   Purpose of a
    "secure transmission loop" security guideline for EDI. This loop involves one
    organization sending a signed and encrypted MIME EDI interchange
       The purpose of these specifications is to
    another organization, requesting a signed receipt, followed by ensure interoperability between
       B2B Electronic  Commerce user agents, invoking some or all of the receiving organization sending this signed receipt back 
       commonly expected security features. This document is also NOT
       limited to
    the sending organization. The transmission therefore involves
    the following stages:

      1. The organization sending strict EDI use, but applies to any electronic commerce 
       application where business data encrypts needs to be exchanged over the data
         and provides Internet
       in a digital signature, using secure manner.

2.3   Definitions
  2.3.1.   Terms
             * EDI - Electronic Data Interchange
             * EC - Business to Business Electronic Commerce
             * B2B - Business to Business
             * Receipt - The functional message that is sent from a receiver to a 

Moberg,  Drummond,                               	[page 4]

HTTP Transport for Secure EDI                               Jan 2003
             

	sender to acknowledge receipt of an EDI/EC interchange. 
                This message may be either PGP/MIME synchronous or
         S/MIME. In addition, they request asynchronous
                in nature.
             * Signed Receipt - A receipt with a signed receipt.

      2. The receiving organization decrypts digital signature.
             * Synchronous Receipt - A receipt returned to the message and
         verifies sender during 
                the signature, resulting in verified integrity of same HTTP session as the data and authenticity of sender's original message
             * Asynchronous Receipt - A receipt returned to the sender.

      3. sender on a 
                different communication session than the sender's original message 
                session
             * Message Disposition Notification (MDN) - The receiving organization then sends Internet messaging 
                format used to convey a signed receipt
         using 
                receipt. This term is used interchangeably with receipt. A MDN is 
                a signature over the hash receipt.
             * Non-repudiation of receipt (NRR) - NRR is a message disposition
         notification, which contains a hash "legal event" that 
                occurs when the original sender of an EDI/EC interchange has 
                verified the received message. signed receipt coming back from the receiver. 
                NRR IS NOT a functional or a technical message.
             * S/MIME - A format and protocol for adding Cryptographic 
                signature and/or encryption services to Internet MIME messages.
             * SHA-1 - A secure, one-way hash algorithm used in conjunction 
                with digital signature. 
                This is the recommend algorithm for AS2
             * MD5 - A secure, one-way hash algorithm used in conjunction with 
                digital signature. 
                This algorithm is accepted in AS2 but not recommended due to its 
                short key length
             * MIC - The above stages describe message integrity check (MIC), also called the functionality message 
                digest, is the digest output of the hash algorithm used by the digital 
                signature. The digital signature is computed over the MIC.
             * User Agent (UA) - The application that would
    satisfy all handles and processes the 
                AS2 request
  2.3.2   The secure transmission loop
            This document's focus is on the formats and protocols for exchanging 
            EDI/EC content that has had security requirements. Applications are expected
    to be able to provide full functionality, though users may
    agree applied to exchange data it using only the Internet's 
            HTTP environment.

           The "secure transmission loop" for EDI/EC involves one organization 
           sending a restricted subset of
    functionality. For example, businesses may agree to send signed
    data using TLS, and only request encrypted  EDI/EC interchange to another 
           organization, requesting a simple, unsigned receipt.

    Implementations are expected signed receipt, followed later by the 
           receiving organization sending this signed receipt back to be configurable so that they may
    support business community agreements that use subsets
    of the full functionality. sending
           organization.  
           In this document, other words, the goal is to make use of HTTP instead of SMTP
    as a transport protocol, following  transpires:
          * -The organization sending EDI/EC data signs and make encrypts the changes that are needed to
    adapt to protocol packaging differences. data 
              using S/MIME. In either transport case, the body of addition, the message is will request a MIME
    structure, using MIME headers ("content-type" and other
    "content-X" tags) signed receipt
              to be returned to convey information about the data
    being transported.

    Also, one primary use sender 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 message.
          * -The receiving organization decrypts the syntax of SMTP headers. Only message and verifies the
    "From" header is overloaded by possibly different usages 
              signature, resulting in verified integrity of the
    SMTP data and HTTP contexts. The "From" header normally contains
    machine-usable email addresses  as defined in [SMTPMSG]. The authenticity of 
              the sender.

Moberg, Brooks,  Drummond, Fischer                               	[page 4] 5]

HTTP Transport for Secure EDI                               May 2002

    usage of                               Jan 2003

  
        * -The receiving organization then returns a signed receipt, as 
               requested either synchronous or asynchronous, to the "From" header sending
              organization in [HTTP] section 14.22 is to provide the email address form of an administrative contact for a message disposition notification.  
              This signed receipt will contain the HTTP
    client. The function hash of the "From" header in signature from the SMTP context of
    secure EDI transport has been 
              received message, indicating to supply a value used in
    constructing the MDN style receipt. But sender that the MDN received message 
              was verified and/or decrypted properly. 
              The above describes functionality which, if implemented, will 
              satisfy all security requirements and implement non-repudiation of 
              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 exchange. This specification, however, leaves full
              flexibility for users to decide the context of HTTP reserved usage of "FROM".

    Also, it is currently difficult degree to make use which they want to 
              deploy those security features with their trading partners.

  2.3.3   Definition of HTML [HTML] receipts 
            The term used for both the functional activity and simple scripting to send HTTP entity-headers as part the message for 
            acknowledging delivery of an EDI/EC interchange is receipt or 
            signed receipt.  The term is used if the
    HTML FORM tag construct. For HTML-based POST situations [GISB],
    it acknowledgment 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 an
            interchange  resulting in [FORMDATA].

    For SMTP transport, the receipt and signed a 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 which is useful. NOT signed.  The MDN is a special kind of multipart/report [REPORT]. For
    MDNS, specialization 
            second term is achieved by assigning used if the "report-type"
    parameter acknowledgment is for an interchange 
            resulting in the content-type  header the special value,
    "disposition-notification" and by having the second body part
    (the "machine-readable" body part) have the MIME content-type,
    "message/disposition-notification".

    To generalize a MDN, all that is needed receipt which IS signed.
            A term often used in combination with receipts is non-repudiation 
            of receipt.  
            NRR refers to remove a legal event which occurs only when the
    restrictions that make original 
            sender of an interchange has verified the underlying multipart/report into a
    MDN. In other words, signed receipt coming back
            from recipient of the "report-type" parameter [REPORT,
    section 1] message. Note that NRR is given a new value not possible without
            signatures.
            For information on how to format and the second body part is
    changed process receipts in AS2, 
            refer to section 7.

2.4   Assumptions
  2.4.1   EDI/EC process assumptions
            -Encrypted object is an EDI/EC Interchange
             This specification assumes that a content-type other than "message/disposition-
    notification". Acknowledgements defined by these changes typical EDI/EC interchange is the
              lowest  level object that will be
    referred subject to as "generalized receipts. Each receipt of security services. 
             Specifically, in EDI ANSI X12, this kind
    will have its own specific report-type parameter means anything between, and its own
    specifications for
              including segments ISA and IEA.  In EDIFACT, this means 
              anything between, and including, segments UNA/UNB and UNZ.
              In other words, the syntax EDI/EC  interchanges including envelope 
              segments remain intact  and semantics of unreadable during secure transport. 
            -EDI envelope headers are encrypted
             Congruent with the automated
    response body part. Implementations above statement, EDI envelope headers are encouraged 
             NOT visible in the MIME package.  
             In order to be able optimize routing from existing commercial EDI networks
             (called Value Added Networks or VANs) to
    register new report-type handlers using only configuration
    changes (not recompiling) that specify how to process new report-
    type values.

    Nothing else needs the Internet, work 
             may need to be changed done in the future to construct reply
    acknowledgements that are define ways to pull out some
             of the envelope information to make them visible; however, this 
             specification does not restricted by go into any detail on this.
            -X12.58 and UN/EDIFACT security considerations
             The most common EDI standards bodies, ANSI X12 and EDIFACT, 
             have defined internal provisions for security.  X12.58 is the semantics security 
             mechanism for ANSI X12 and AUTACK provides security for 
             EDIFACT. This specification DOES NOT dictate use or non-use of
    MDNs. Specifically, a signed reply will still be constructed by
    using a multipart/signed package to wrap up generalized receipts 
             these security standards.  
             They are both fully compatible, though possibly redundant, with their signatures.

    Finally, within this 
             specification.

  2.4.2   Flexibility assumptions
            -Encrypted or un-encrypted data
             This specification allows for EDI/EC message exchange where the HTTP transport context, it is useful to make 

Moberg, Brooks,  Drummond, Fischer                               	[page 5] 6]

HTTP Transport for Secure EDI                               May 2002

    use of Transport Layer Security [TLS] to provide privacy.
    Compression                               Jan 2003

             EDI/EC data can either be provided using HTTP content-codings [HTTP],
    sections 3.5, 14.3, 14.12]. (Content codings are not to be
    confused with the MIME concept of content transfer encodings.)

    A variety of other minor differences (for example, absence un-protected or protected by means 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, 
             encryption.
           -Signed or other business data. The Request-URI
    ([HTTP],section 9.5) identifies a process to unpack and handle
    the message unsigned data and to generate a reply
            This specification allows for the client that
    contains a EDI/EC message disposition acknowledgement exchange with or a multipart/
    report, signed 
            without digital signature of the original EDI transmission.
           -Use of receipt or unsigned, and possibly other turnaround
    transactions. not
            This request/reply transactional interchange
    provides secure, reliable, and authenticated transport specification allows for EDI EDI/EC message transmission with or other business data using HTTP; 
            without a request for receipt notification.  If a signed receipt
            notification is requested  however, a MIC value is REQUIRED as
            part of the security protocols and
    structures used also support auditable records of these
    transmissions, acknowledgements, and authentication.


2. Stages and Details of HTTP Transmission and Acknowledgment

    A data file or stream is first structured into one of the
    message templates described returned receipt, unless an error condition occurs in [AS1], sections 4.2.1 to 4.2.4 which
            a MIC value cannot be returned. In error cases, an unsigned receipt
            or
    4.3.1 to 4.3.4 for PGP/MIME MDN SHOULD be returned with the correct "disposition modifier"
            error value.
           -Use of synchronous or S/MIME security. In asynchronous receipts
            This specification allows in addition to a receipt request the content-types 
             specification of the type of [MIMEEDI], applications receipt that should be
    prepared for handling other content-types used returned. 
             It supports synchronous or asynchronous receipts 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 MDN format
             specified  in Appendix A.

    If TLS is to be used, section 7 of this document.
          -Security Formatting 
           This specification relies on the typical packaging will be that
    described guidelines set forth in sections 4.2.2 or 4.3.2; that is, a multipart/signed
    message will be created with no encryption RFC 2633/2630  
            [8] "S/MIME Version 3 Message Specification; Cryptographic  
            Message Syntax".
            S/MIME as defined in the message.
    Otherwise, if privacy is desired, this Applicability statement.
         -Hash function, message templates 4.2.4 or
    4.3.4 are used. Content transfer encoding is not used and digest choices
          When a content-length field signature is to be provided.

    If HTML-based POST used, it is used (using the METHOD=POST attribute
    within the "FORM" tag) [HTML, 17 Forms], then RECOMMENDED that the message payload
    will SHA1
            hash algorithm be packaged in the input-data element of a multipart/form-
    data. The metadata needed used for application layer routing,
    identification, requesting a reply all utgoing messages, and other transaction
    operations can that both MD5
            and SHA1 be packaged in message body parts in the
    multipart/form-data. The labels supported for incoming messages.
         -Permutation Summary

In summary, the metadata values following twelve security permutations are found possible in any 
given trading relationship:
1. Sender sends un-encrypted data, does NOT request a receipt.
2. Sender sends un-encrypted data, requests an unsigned receipt. The 
    receiver sends back the "name" parameter of the Content-Disposition header in each
    form-data part as discussed in [FORMDATA, section 3].
    unsigned receipt.
3. Sender sends un-encrypted data, requests a signed receipt. The receiver 
    sends back the 
    signed receipt.
4. Sender sends encrypted data, does NOT request a receipt. 
5. Sender sends encrypted data, requests an unsigned receipt. The receiver 
    sends back the 
    unsigned receipt. 
6. Sender sends encrypted data, requests a signed. The receiver sends back 
    the signed receipt.
7. Sender sends signed data, does NOT request a signed or unsigned receipt.
8. Sender sends signed data, requests an unsigned receipt. Receiver sends 
    back the unsigned receipt.
9. Sender sends signed data, requests a signed receipt. Receiver sends back 
    the signed receipt.

Moberg, Brooks,  Drummond, Fischer                               	[page 6] 7]

HTTP Transport for Secure EDI                               May 2002

    In general, both HTTP servers                               Jan 2003


10. Sender sends encrypted 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 signed data, does NOT request a signed or 
     unsigned receipt.
11. Sender sends encrypted and MIME media type
    options defined in sections 4.2.x signed data, requests an unsigned receipt. 
     Receiver sends back the unsigned receipt.
12. Sender sends encrypted and 4.3.x signed data, requests a signed receipt. 
      Receiver sends back the signed receipt.
  NOTE: Users can choose any of "MIME-based
    Secure Peer-to-Peer Business Data Interchange over the
    Internet" [AS1], this specification enables twelve possibilities, but only the transport of
    payload objects containing other MIME media types. Implementors
    are to follow last 
              example (12), when a signed receipt is requested, offers the appropriate specifications identified under
    "References" whole
              suite of security features described in [MIME-TYPES], for the type of object being
    transmitted. For example, to send an XML object, "Secure transmission loop" 
              above.
  Additionally, the MIME media
    type of application/xml is used receipts discussed above may be either synchronous or 
  asynchronous in nature depending on the Content-type MIME header
    and type requested. The use of either
  the specifications  for enveloping synchronous or asynchronous receipts does not change the object are contained
    in [XMLTYPES]; for example:

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

    Many nature of the specifications referenced by [MIME-TYPES] were
    designed for SMTP transports. Implementors are advised to make
    appropriate adjustments for HTTP transport as indicated 
  "Secure transmission loop" in
    section 3 support of this document.

    Finally, several industry groups currently make NRR.


3.   Referenced RFC's and their contribution
  3.1   RFC 2616 HTTP v1.1 [3]
         This document specifies how data is transferred using HTTP.
  3.2   RFC 1847 MIME Security Multiparts [6]
         This document defines security multipart for MIME:   
          multipart/encrypted and multipart/signed.
  3.3   RFC 1892 Multipart/report [9]
         This RFC defines the 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 multipart/report content type, 
          something that the case MDN RFC 2298 builds upon.
  3.4   RFC 1767 EDI Content [2]
         This RFC defines the use of PGP, according to content type "application" for ANSI X12 
         (application/EDI-X12), EDIFACT (application/EDIFACT) and mutually 
         defined EDI (application/EDI-Consent).
  3.5   RFC 2045, 2046, and 2049 MIME [1]
         These are the specifications contained
    in section 6.2 basic MIME standards, upon which all MIME related 
         RFCs build, including this one.  
         Key contributions include definition of "MIME Security with Pretty Good Privacy (PGP)"
    [MIMEPGP] "content type", "sub-type" and "OpenPGP 
         "multipart", as well as encoding guidelines, 
         which establishes 7-bit US-ASCII as the canonical character set to be 
         used in Internet messaging.
  3.6   RFC 2298 Message Format" [RFC2440].

2.1  Requesting Receipts

2.1.1  Requesting MDN-based receipts

     For requesting Disposition Notification [5]
         This Internet RFC defines how a MDN based receipts, the originator supplies
     metadata using is requested, and the format and
         syntax of extension headers (the [SMTPMSG]
     header syntax) that precede the message body. MDN. 
         The header "tags" are as follows:

     A Disposition-Notification-To header is added to indicate
     that a message disposition notification MDN 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 basis upon which receipts and signed receipts are 
         defined 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 specification.
  3.7   RFC 2633 and 2630 S/MIME Version 3 Message Specifications [8]
         This specification describes how MIME shall carry Cryptographic 
         Message Syntax (CMS) Objects.
  3.8   RFC 2376 XML Media Types [12]
         This RFC defines the MDN use of content type "application" for XML 
         (application/xml).

Moberg, Brooks,  Drummond, Fischer                               	[page 7] 8]

HTTP Transport for Secure EDI                               May 2002

     body part                               Jan 2003


4.   Structure 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 SHOULD be supplied. an AS2 message
  4.1   Introduction 
         The
     "From" value needs to have basic structure of an email address as specified AS2 messages consists of MIME format 
         inside an HTTP message with a few additional specific AS2 headers. 
         The structures below are described hierarchically in
     [SMTPMSG] and [HTTP]. If other uses terms of "From" which 
         RFC's are needed, the
     generalized receipts  applied to be next discussed should be used. There form the role specific structure.  For details of "From" is replaced by symbols not having a reserved
     HTTP or SMTP usage.

     Other headers, especially "Subject" and "Date", should be
     supplied; how 
         to code in compliance with all RFC's involved, turn directly to the values of these headers RFC's
         referenced.  Any difference between AS2 implantations and RFCs are often
         mentioned specifically  in the
     human-readable section sections below.

  4.2   Structure of a an Internet EDI MIME message

No encryption, no signature 
     -RFC2616/2045
     -RFC1767/RFC2376 (application/EDIxxxx or /xml)

No encryption, signature
     -RFC2616/2045
     -RFC1847 (multipart/signed)
     -RFC1767/RFC2376 (application/EDIxxxx or /xml)
     -RFC2633 (application/pkcs7-signature)

Encryption, no signature
     -RFC2616/2045
     -RFC2633 (application/pkcs7-mime)
     -RFC1767/RFC2376  (application/EDIxxxx or /xml)(encrypted)

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

MDN over HTTP, no signature
     -RFC2616/2045
     -RFC2298 (message/disposition-notification)

MDN over HTTP, signature
     -RFC2616/2045
     -RFC1847 (multipart/signed)
     -RFC2298 (message/disposition-notification)
      -RFC2633 (application/pkcs7-signature)

MDN over SMTP, no signature
MDN over SMTP, signature
  Refer to aid in identifying the
     original message.

     A Disposition-Notification-Options header is used to request
     a signed message disposition notification. EDI over SMTP standard [4].

  While all MIME content types SHOULD be supported. 
  The parameters
     used to select protocols following MIME content types MUST be supported:

    Content-type: multipart/signed
    Content-Type: multipart/report
    Content-type: message/disposition-notification
    Content-Type: application/PKCS7-signature
    Content-Type: application/PKCS7-mime
    Content-Type: application/EDI-X12
    Content-Type: application/EDIFACT

Moberg,  Drummond,                               	[page 9]

HTTP Transport for signed message disposition
     notification are found Secure EDI                               Jan 2003

    
     Content-Type: application/edi-consent
    Content-Type: application/XML
5.   HTTP Considerations
  5.1   Sending EDI in [AS1].

     Disposition-Notification-To is a name that, if present,
     indicates that HTTP Post Requests
         The request line will have the MDN style of receipt is to be used.

     Disposition-notification-options identifies characteristics of
     message disposition notification in accordance form: "POST Request-URI HTTP/1.1", 
         with [AS1] spaces and
     [MDN].

     A Receipt-delivery-option is followed by a header whose value CRLF. The Request-URI is typically
         exchanged out of band, as part of setting up a URL
     that indicates how the receipt is to bilateral trading partner 
         agreement. Applications should 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," prepared to deal with an asynchronous initial 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) 
         containing a status indicating a need for this information. If this header/metadata is absent, then
     the mode authentication of operation is synchronous, which means that the
     receipt is returned in the reply usual 
          types used for authorizing access to the current HTTP request.

2.1.2  Requesting Generalized Receipts

     In this section, the ways to Request-URI ([3], section 10.4.2
         and elsewhere). 
         The request generalized receipts
     are specified. Generalized receipts are multipart/reports
     with a report-type other than "disposition-notification," line is followed by entity headers specifying content length 
         ([3] section 14.14) 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

Moberg, Brooks, Drummond, Fischer                           [page 8]

HTTP Transport for Secure EDI                               May 2002

     with report-type "GISB-Acknowledgement-Receipt" will be
     presented in appendix B. ([3], section  14.18). The Host request
         header ([3] sections 9 and 14.23) is also included.
        When using Transport Layer Security [10], the term "metadata" is used in request-URI should 
         indicate the following, 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.
        The receiving AS2 system MAY disconnect from the term
     indicates sending AS2 system 
         before completing the information may be supplied in one reception of two ways:

       First, the metadata information may be supplied using entire entity if it determines the
        syntax of 
         entity being sent is too large to process.
        For HTTP headers. That is, version 1.1, TCP persistent connections are the symbol name is
        followed by a colon default,
        ([3] sections 8.1.2, 8.2, and its value follows; the header 19.7.1). A number of other differences exist 
         because HTTP does not conform to MIME [1] as used in SMTP
         transport. Relevant differences are summarized below.

  5.2   Unused MIME headers and operations
    5.2.1   Content-Transfer-Encoding not used in HTTP transport
              HTTP can handle binary data and so there is subject no need to processing use the Content 
              transfer encodings of structured field bodies
        [SMTPMSG, MIME [1]. This difference is discussed in 
              [3] section 3.1.4], also including parameters.

       Second, the metadata information may be supplied by using
        the syntax 19.4.4. However, a Content transfer encoding value of the "name" parameter within the
        "Content-Disposition" 
              binary or 8-bit is permissible but not required. 
              The absence of this header must not result in transaction failure. 
              Content transfer encoding of the multipart/form-data
        structure, when that MIME packaging [FORMDATA] is used.
        For example,

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

          GISB-Acknowledgement-Receipt
          --boundaryformdata

     Within HTML, bodyparts within 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], AS2 
              message is also allowed.

    5.2.2   Epilogue must be empty
              In [3] section 18; 3.7.2, it is explicitly noted that multiparts must have null 
              epilogues.
              In [4], sections 5.4.1, options 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">
         </FORM>

     To indicate large file processing are discussed for
              SMTP transport.
              For HTTP, large files should be handled correctly by the various TCP layer. 
              However, [3] sections 3.5 and 3.6 discuss some options for generalized receipts, the
     basic metadata that the POSTing client needs 
              compressing or chunking  entities to convey be transferred. 
              [3] section 8.1.2.2 discusses a pipelining option that is useful for 
              segmenting large amounts of data.

  5.3   Modification of MIME or other headers or parameters used
    5.3.1   Content-Length
              Because connections are persistent, closing a connection cannot be used 
              to indicate the
     replying server are: "Receipt-Disposition-To", and
     "Receipt-report-type", "Receipt-Security-Selection",
     "Receipt-Delivery-Option".

     The presence end of an entity. Therefore, [3] sections 4.4 and 14.14
              indicate the metadata value "Receipt-Disposition-To",
     using the extension need for a Content-Length  entity header syntax, indicates in a request for a
     generalized receipt.

     Because HTTP already has is a role 
              MUST. The only exception to this for the "From" header, the
     "Receipt-Disposition-To" header AS2 messages 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
     conflict with one-line, 
              successful, HTTP headers.) Notice that response is provided.
    5.3.2   Final and Original Recipient
              The final and original recipient values SHOULD be the value for this
     identifier need not same value. 
              These values MUST NOT be an email address aliases or a URL. In this way,
     other systems of identification (such as a DUNS number) may be mailing lists.
    5.3.3   Message-Id and Original-Message-Id

Moberg, Brooks,  Drummond, Fischer                               	[page 9] 10]

HTTP Transport for Secure EDI                               May 2002

     used, if needed. Notice that the information needed for delivery
     of the receipt                               Jan 2003

              Message-Id and Original-Message-Id is found formatted as defined in the receipt-delivery-option element
     described below; delivery information 
              RFC2822:
               "<" id-left "@" id-right ">"        (RFC2822 3.6.4)
              Message-Id length is not generally needed
     if the default mode a maximum of operation occurs. In that case, the
     receipt just goes back in the reply 998 characters.  For maximum 
              backward compatibility, 
              Message-Id length SHOULD be 255 characters or less. Message-Id 
              SHOULD be globally unique, id-right should be something unique to 
              the current HTTP request.

     "Receipt-Report-Type" indicates sending host    environment (e.g. a host name).When sending a 
              message, always include the desired value angle brackets.  Angle brackets are not part
              of  the
     "report-type" parameter Message-Id value.  For maximum backward compatibility, when 
              receiving a message, do not check for angle brackets. When creating the
             Original-Message-Id header in an MDN, always use the multipart/report content type of
     a specific version of exact syntax as 
              received on the generalized receipt. This parameter original message - don't strip    or add angle brackets.
    5.3.4   Host header
              The host request header field must be supplied included in the POST request made
              when "Receipt-Disposition-To" sending business data. 
              This field 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
     "GISB-Acknowledgement-Receipt".

     "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 allow one server IP address to service multiple hostnames, 
              and algorithm choices is
     that used in [AS1] potentially conserve IP addresses. See [3], sections 14.23 and [MDN]; for 19.5.1.

  5.4   HTTP Response Status Codes
         The status codes return status concerning HTTP operations. For example,

         Receipt-Security-Selection:
           signed-receipt-protocol=optional,pkcs7-signature;
           signed-receipt-micalg=optional,rsa-sha1

     "Receipt-Delivery-Option" the
         status code 401, together with the WWW-Authenticate header, is used to indicate 
         challenge the
     URL for asynchronous delivery of client to repeat 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) request with an Authorization header. Other
         explicit status codes are   documented in the reply body, asynchronous reply is allowed through
     use of this symbol. The URLs will typically use the
     "MAILTO", "HTTP", [3], sections 6.1.1 and "HTTPS" schemes. 
          throughout section 10.
          For errors in the HTTP request-URI, 400 ("Bad Request"), 404 ("Not Found") and
     HTTPS schemes, the POST method is to be used.

2.1.2.1 Additional Commonly Used Headers

     The following set of header data elements 
          similar codes are also available for
     use. Organizations wishing to use this specification for the
     secure appropriate status codes. These codes and reliable transport of business documents their semantics
          are not
     required to utilize all specified by [3]. A careful examination of these headers codes and are free to use
     whatever subset they deem appropriate for their business needs.

     TO:
     The To name contains an identifier identifying the
     intended recipient of a data exchange and may semantics 
          should be
     D&B D-U-N-S number [DUNS] or other agreed upon
     identifier system. Applications made before implementing any retry functionality. Retries should allow users to
     configure these elements in not
          be made if the automated error is not transient or if retries are explicitly discouraged.

  5.5   HTTP agents




Moberg, Brooks, Drummond, Fischer                          [page 10] Error Recovery
          If the HTTP Transport for Secure EDI                               May 2002

     processing these values. For example, client fails to read the body
     part MIME header line looks like HTTP server response data,  the following line:

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

     FROM: POST 
          operation with identical content, including same Message-ID should be 
          repeated, if the condition is transient.
         The From name contains Message-ID on a textual value identifying the sender POST operation can be reused if and only if all 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], 
          content (including the From name parameter  original Date) is not to be considered equivalent
     to the extension header. If an extension header "From" is
     to be used within HTTP, it should conform to the usage, syntax,
     and semantics of [HTTP] section 14.22. The extension header
     counterpart of the sender identical.
         Details of a data exchange is the extension
     header version retry process -- including time intervals to pause, number of "Receipt-disposition-to"

     INPUT-FORMAT:
     The Input-format name identifies the type 
         retries to attempt, timeouts for retrying -- are implementation dependent. These
         settings are selected as part of data contained
     in a data file.

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

     APPLICATION:
     The Application name identifies the application used trading partner agreement.
         Servers should be prepared to process
     the data next (after the URI-request process has finished receive a POST with
     the stream).

     DATETIME: a repeated Message-ID. 
         The DateTime name provides the date and time MIME reply body previously sent should be resent, including the data was
     created MDN and uses the format specified in [SMTPMSG] as updated
     by RFC 1123.

     REFNUM:
         other MIME parts.

6.   Additional AS2 Specific HTTP Headers
     The RefNum is an integer value used following headers are to uniquely identify the
     communication exchange and is be included in a textual format. The RefNum is
     similar to the Message-ID all AS2 messages and Content-Id headers of SMTP all AS2 MDNs,
      except for asynchronous MDNs that are used in constructing values in receipts based on  MDNs.

     USERPARAM:
     The UserParam is a user-defined parameter.

     Version: sent over SMTP [4] and single line 
      HTTP 1.1 responses (section 5.5).
  6.1   AS2 Version is a protocol version number [GISB].

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

     INPUT-DATA:
     Input-data is the sending side's local file system name Header

Moberg, Brooks,  Drummond, Fischer                               	[page 11]

HTTP Transport for Secure EDI                               May 2002

     for the file being sent. The payload                               Jan 2003

         To promote backward compatibility AS2 includes a version:
         AS2-Version: 1.0	
             - is contained used in all implementations implementing this specification. 1.x 
              will be interpreted as 1.0 by all implementation implemented with the body
     part of 
              AS2-Version: 1.0 header. 
              That is only the most significant digit is used as the version identifier for 
              those not implementing additional non-AS2 specified functionality.
              AS2-Version: 1.0 through 1.9 MAY be used
              All implementations WILL interpret "1.0 through 1.9" as implementing this header element.

     PRIORITY:
     The "Priority" name
              specification. 
              However implementation MAY extend this specification with additional 
              functionality by specifying 
              versions 1.1 through 1.9. If this mechanism is used to indicate the processing priority
     of each message relative additional functionality 
             WILL be completely transparent to other messages sent implementations with AS2-Version: 1.0
             designation.
         AS2-Version: 1.1	
            - Designates those implementation which support Compression as defined by a given
     party. The value "1" indicates highest priority and a value
              RFC 3274.
              Receiving systems MUST NOT fail due to the absence of "5" indicates the lowest priority.

     EXPIRATION:
     The "Expiration" name is used to AS2-Version
              header. 
             Absence would 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.

2.1.3 Summary Remarks from  an implementation based 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 previous version of this specification.

  6.2   AS2 System Identifiers 
         To aid the message
     header syntax used receiving system in SMTP or HTTP identifying the sending system, AS2-From and
         AS2-To headers [SMTPMSG]. If
     metadata items are repeated in extension used.

       AS2-From: < AS2-name >
       AS2-To: < AS2-name >

  These AS2 headers and in
     form-data parts, but the values are not the same, contain textual values, as described below, identifying the
     extension header 
   sender/receiver of a data exchange. Their 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.

     The receipt-delivery-option's value should company specific, 
   such as DUNS number, or it may be a URL indicating
     the delivery transport destination for simply an identification string agreed upon 
   between the receipt.  trading partners. 

     AS2-text = "!" /           ; printable ASCII characters
                %d35-91 /       ; except double-quote (%d34)
                %d93-126        ; or backslash (%d92)
                
     AS2-qtext = AS2-text / SP  ; allow space only in quoted text

     AS2-quoted-pair = "\" DQUOTE /  ; \" or
                       "\" "\"       ; \\
                                           
     AS2-quoted-name = DQUOTE 1*128( AS2-qtext /
                                     AS2-quoted-pair) DQUOTE

     AS2-atomic-name = 1*128AS2-text

     AS2-name = AS2-atomic-name / AS2-quoted-name

  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; synchronous delivery of
     the reply is AS2-From header value and the default mode of delivery.

     For signed generalized receipts, an extension AS2-To header of
     "Receipt-security-selection" should value MUST each be added an 
  AS2-name, MUST each be comprised of from 1 to indicate the
     desired security protocol for the multipart/signed over the
     multipart/report.

     In summary, the receipt request 128 printable ASCII characters
  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 MUST NOT be folded. 
  The value in a
         multipart/form-data's Content-Disposition headers or by
         using a syntax each of HTTP extension headers. these headers is case-sensitive. The string definitions given 
   above are in ABNF format.

  The AS2-quoted-name SHOULD be used only if the AS2-name does not conform 
  to AS2-atomic-name. 


Moberg, Brooks,  Drummond, Fischer                               	[page 12]

HTTP Transport for Secure EDI                               May 2002

      2. Both MDN                               Jan 2003


  The AS2-To and generalized receipts can be requested using
         either syntax. However, using an extension AS2-From header syntax fields MUST be present in all AS2 messages 
  and requesting a MDN receipt means restricting AS2 MDN's whether asynchronous or synchronous in nature, except for 
  asynchronous MDNs which are sent using SMTP.

  The sending system may choose to limit the "From" possible AS2-To/AS2-From textual 
   values to email addresses.

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

      4. Finally, receipts but must not exceed them. 
  The receiving system must make no restrictions on the textual values and should 
   handle all possible implementations. 
  However, implementers must be aware that older AS2 products may not adhere to
   this convention. 
  Trading partner agreements should be delivered synchronously (delivered
         in made to insure that older products can 
  support the HTTP reply) system identifiers that are used.
  If either the AS2-From or the AS2-To or the combination of both header values is
  determined to be invalid or asynchronously unknown by using the
         "Receipt-delivery-option" header.

2.2 Sending EDI receiving system, the receiving system 
  MAY respond in HTTP Client Requests using POST

    For sending EDI, one of the following protocol elements are typically
    present: a request line ([HTTP], section 5.1), entity headers, a
    CRLF pair ways, but is not limited to mark these options:
        1. The receiving AS2 system MAY disconnect from the end sending AS2 system 
            before completing the reception of the entire entity headers, followed by if it determines the
    message-body. HTTP
            headers do not represent a valid trading-relationship.
        2. The request line will have the form: "POST Request-URI HTTP/1.1", receiving AS2 system MAY return an HTTP response with spaces and followed by a CRLF. The Request-URI is typically
    exchanged out of band, as part response 
            code in the 2xx range, with or without any explanation of setting up a bilateral
    trading partner agreement. Applications should be prepared
    to deal the error, even if 
            the sending system requested an MDN.
        3. The receiving AS2 system MAY return an unsigned MDN with an initial reply containing a status indicating a
    need for authentication 
            explanation of the usual types used for authorizing
    access to error, if the Request-URI ([HTTP], section 10.4.2 sending system requested an MDN.

7.   Structure and elsewhere).

    Automation Processing of this process is not discussed in this document
    but might involve obtaining an MDN Message
  7.1   Introduction
          In order to support non-repudiation of receipt, a session URL from signed receipt, based on 
          digitally signing a page requesting
    authentication and possibly other information about proposed
    EDI standard versions and other trading conventions message disposition notification, is to be used.

    The request line is followed implemented by entity headers specifying content
    length ([HTTP] section 14.14) and content type [HTTP], section
    14.18. a 
          receiving trading partner's UA. The Host request header ([HTTP] sections 9 and 14.23) message disposition notification, 
          specified by RFC 2298 is also included.

    The entity or extension headers used for requesting digitally signed by a MDN
    (unsigned or signed) have previously been mentioned,
    as have those ("To" "From" "Message-Id") that are needed receiving trading partner as
    values for MDN fields or part 
          of a multipart/signed MIME message.
          The following support for other receipt requests.

    For generalized signed receipts based on is REQUIRED:
              1) The ability to create a multipart/report; where the multipart/report content
    type, 
                   report-type = disposition-notification.
              2) The ability to calculate a message integrity check (MIC) on the metadata can received 
                  message. The calculated MIC value will be returned to the values found in extension headers,
    but can also be placed in body parts sender of a multipart/form-data
    using "name" parameters in the content-disposition header.

    Finally,
                  message inside the payload is found in any of signed receipt.
              3) The ability to create a multipart/signed content with the message patterns
    of [AS1] sections 4.2.1 
                  disposition notification as the first body part, and the signature as the
                  second body part.
              4) The ability to 4.2.4 or 4.3.1 return the signed receipt to 4.3.4 for PGP/MIME the sending trading partner.
              5) The ability to return either a synchronous or S/MIME security. These payloads may arrive asynchronous receipt as the "input-data"
    part of the multipart/form-data or may even be enclosed in some
    other multipart.


Moberg, Brooks, Drummond, Fischer                          [page 13]

HTTP Transport
                  sending party requests.
          The signed receipt is used to notify a sending trading partner that requested the
          signed receipt that:
             1) The receiving trading partner acknowledges receipt of the sent EC 
                  Interchange.
             2) If the sent message was signed, then the receiving trading partner has 
                 authenticated the sender 

Moberg,  Drummond,                               	[page 13]

HTTP Transport for Secure EDI                               May 2002

2.3 Using Transport Layer Security

    To use Transport Layer Security [TLS],                               Jan 2003

                of the request-URI should
    indicate EC Interchange.
             3) If 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 was signed, then the "Receipt-delivery-option" header with
    a URL value making use receiving trading partner has
                 verified the integrity of 
                 the HTTPS scheme to obtain
    confidentiality.

2.4  Response Status Codes in Replies

    The status line for response to errors sent EC Interchange.
          Regardless of whether the EDI/EC Interchange was sent in S/MIME format 
          or not, the POST request line
    will be provided by a status line with receiving trading 
          partner's UA MUST provides the following protocol
    elements present ([HTTP], section 6.1): HTTP version (normally,

    The status codes return status concerning HTTP operations. For
    example, basic processing:
              1) If the status code 401, together with sent EDI/EC Interchange is encrypted, then the WWW-Authenticate
    header, encrypted symmetric 
                  key and initialization
                  vector (if applicable) is used to challenge decrypted using the client receiver's private key.
              2) The decrypted symmetric encryption key is then used to repeat decrypt the request
    with an Authorization header. Other explicit status codes are
    documented 
                   EDI/EC Interchange.
              3) The receiving trading partner authenticates signatures in [HTTP], sections 6.1.1 and throughout section 10.
    HTTP/1.1), a status code, reason phrase, message
                   using the sender's public key. 
                  The authentication algorithm performs the following:
                  a) The message integrity check (MIC or Message Digest), is decrypted
                      using the sender's public key.
                  b) A MIC on the signed contents (the MIME header and CRLF.

    For errors encoded EDI 
                      object, as per RFC 1767) 
                      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 message received is calculated using the same one-way hash 
                      function that the sending trading partner used.
                  c) The MIC extracted from the message that was sent, and their semantics
    should be made before implementing any retry functionality the MIC 
                      calculated using the same one-way hash function that is described below; specifically, retries should not
    be made if the error sending
                      trading partner used is not transient or if retries are
    explicitly discouraged (for real authentication failures, compared for example.)

2.5  Receipt Reply equality.
             4) The details of receiving trading partner formats the response to MDN and sets the POST command vary depending
    upon whether calculated 
                 MIC into the "Received-content-MIC" extension field.
             5) The receiving trading partner creates a receipt has been requested and upon what kind multipart/signed MIME message
                 according to RFC 1847.
             6) The MDN is the first part of receipt has been requested.

    With no extended header requesting a receipt, and no errors
    accessing the request-URI specified processing, multipart/signed message, and the status
    line in digital 
                 signature is created over this MDN, including its MIME headers.
             7) The second part of the Response to multipart/signed message contains the POST request should be digital
                  signature. The "protocol" option specified in the 200
    range. Status codes in second part of the 200 range should also be used when an
    entity is returned (a signed receipt in a 
                  multipart/signed is as follows:
                           S/MIME: protocol = "application/pkcs-7-signature"
             8) The signature information is formatted according to S/MIME specifications.
                 The EC Interchange and the RFC 1767 MIME EDI content type or an unsigned receipt in header can 
                 actually be part of a multipart/report).
    Even when multi-part MIME content-type.  When the disposition EDI 
                 Interchange is part of a multi-part MIME content-type, the data was an error condition
    at MIC 
                 MUST be calculated across the authentication, decryption or other higher level, the
    HTTP status code should indicate success at entire multi-part content, including the HTTP level. 
                 MIME headers.
         The HTTP server-side application may respond with an unsolicited
    multipart/report as a message body that signed MDN, when received by the sender of the HTTP client

Moberg, Brooks, Drummond, Fischer                          [page 14]

HTTP Transport for Secure EDI                               May 2002

    might not have solicited, but this may Interchange can be discarded
         used by the
    client. Applications should avoid emitting unsolicited receipt
    replies because bandwidth or processing limitations might
    have led administrators to suspend asking for acknowledgements.

    When a Disposition-Notification-To extension header is present
    in sender:
             1) As an acknowledgment that the POST request entity headers, then entity headers for EDI Interchange sent, was delivered and 
                 acknowledged by the MDN should be included. receiving trading partner. The content type for the MDN receipt
    (multipart/report [REPORT] or multipart/signed [SECURITY])
    should be included in receiver does this by
                 returning the Response entity headers.

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

2.5.1  MDN based Receipts and Signed MDN Receipts

    Message Disposition Notifications, when used the sent message in the HTTP
    reply context, will closely parallel a SMTP MDN. For
    example, MDN portion 
                 of the disposition field is a required element in signed receipt.
             2) As an acknowledgment that the
    machine readable second part integrity of a multipart/report for a
    MDN. the EDI Interchange was 
                 verified by the receiving trading partner.  The final-recipient-field ([MDN] section 3.1) value
    should be derived from receiver does this by 
                 returning the entity headers calculated MIC of the request.

    If received EC Interchange 
                (and 1767 MIME headers) in the "To" "Received-content-MIC" field is missing, for of the 
                signed messages, MDN.
             3) As an acknowledgment that the value for
    Original-recipient may be receiving trading partner has authenticated 
                 the email address field from sender of the
    signer's X.509 attribute for email addresses, if that value is
    available. For EDI Interchange.
             4) As a MDN, an application must report the Message-ID
    of the request. The human readable part (the first part non-repudiation of the
    multipart/report) should include items such as the subject, date
    and other information receipt 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 signed MDN is successfully 
                 verified by the original message
    or its headers in sender with the SMTP context).

2.5.2  Generalized Receipts receiving trading partner's public key 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 returned MIC value for inside 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 MDN is the original message and,
    when asynchronously delivered, information allowing same as the
    identification digest 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


Moberg, Brooks,  Drummond, Fischer                               	[page 15] 14]

HTTP Transport for Secure EDI                               May 2002

    syntax for expressing names                               Jan 2003

  7.2   Synchronous and values, such as the [SMTPMSG]
    header syntax, XML, or  some MIME content type correlated with
    automated processing. Asynchronous MDNs 
         The MDN requirements, therefore, are removed for this second
    part, but information used AS2-MDN exists in MDNs may be used here. two varieties: synchronous and asynchronous.
         The third
    part synchronous AS2-MDN is sent as an HTTP response to an HTTP POST
         or as an HTTPS response to an HTTPS POST. This form of AS2-MDN is 
         called synchronous because the multipart report AS2-MDN is usually omitted in returned to the HTTP
    context, but could include originator of the extension headers, or even 
         POST on the
    entire payload, to provide diagnostic information.

    A multipart/signed over a multipart/report same TCP/IP connection.
         The asynchronous AS2-MDN is constructed
    precisely in sent on a separate HTTP, HTTPS, or 
         SMTP TCP/IP connection. Logically, the same way as asynchronous AS2-MDN is a multipart/signed over
          response to an AS2 message. However, at the transfer-protocol layer, 
          assuming that no HTTP pipelining is utilized, the asynchronous AS2-MDN is 
         delivered on a MDN [AS1].

    One metadata element should unique TCP/IP connection, distinct from that used to deliver the 
         original AS2 message. When handling an asynchronous request, the HTTP 
         response must be within sent back before the automated part.
    This MDN is processed and sent on the Received-Content-MIC (also allowing
    X-Received-Content-MIC). This value 
         separate connection.
         When an asynchronous AS2-MDN is constructed and formatted
    as described in [AS1] and requested by the syntax should be either RFC822:

          Received-Content-MIC: w7AguNJEmhF/qIjJw6LnnA==, rsa-md5 sender of an AS2 
         message, the synchronous HTTP or simple XML

          <ReceivedContentMic algid=rsa-md5 encode=base64 >
           w7AguNJEmhF/qIjJw6LnnA==
          </ReceivedContentMic>

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

    Otherwise HTTPS response returned to the automated acknowledgement semantics are left open sender
         prior to specific definition by other electronic commerce
    communities, such as in [GISB]. Each specialization terminating the connection MUST be a transfer-layer response 
         indicating the success or failure of the
    generalized receipt should make use data transfer. The format of such a explicit identifying
    value to
         synchronous response MAY be placed in the parameter "report-type,"

    Any original metadata thought useful to include in same as that response returned when no 
         AS2-MDN is requested.
   The following diagram illustrates the automated
    part synchronous versus asynchronous varieties of
   AS2-MDN delivery:
     Synchronous AS2-MDN
         [C] ----( connect )----> [S]
         [C] -----( send )------> [S]   [HTTP Request [AS2-Message]]
         [C] <---( receive )----- [S]   [HTTP Response [AS2-MDN]]
Asynchronous AS2-MDN
         [C] ----( connect )----> [S]
         [C] -----( send )------> [S]   [HTTP Request [AS2-Message]]
         [C] <---( receive )----- [S]   [HTTP Response]

         [C]*<---( connect )----- [S]
         [C] <--- ( send )------- [S]   [HTTP Request [AS2-MDN]]
         [C] ----( receive )----> [S]   [HTTP Response]
  * Note: An AS2-MDN may be reflected back using "Original-X", as in

            Content-Type: multipart/report;
                         report-type="identifying-value";
                         boundary="=-Trfds88fd99"

    Implementations should attempt to be configurable directed to allow
    for new report-type values a different host than that of the sender of 
     the AS2 message and may utilize a different transfer protocol than that used to be added;  communities 
     send the original AS2 message.
     The advantage of the synchronous MDN is that it can then
    agree to provide the specific extensions they need to support application

    level routing, transaction identification, timestamps, and
    other specialized information about sender of the data they have exchanged.






Moberg, Brooks, Drummond, Fischer                          [page 16]

HTTP Transport for Secure EDI                               May 2002

2.6  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
     AS2 Message with a verifiable  confirmation of message delivery within MIME multiparts. This a 
     synchronous logic flow. However, if the message is true for HTTP request payloads
    as well as HTTP reply payloads.

    So, as previously mentioned, for HTML-based POSTS, any of relatively large, the
    EDIINT templates described in [AS1], sections 4.2.1 to 4.2.4 or
    4.3.1 time 
     required 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 process this document.]

    In addition, the response message and return an AS2-MDN to the POST operation sender on the 
     same TCP/IP connection may include other
    MIME wrapped content besides exceed the maximum configured time permitted for
     an MDN Receipt, Signed MDN,
    Generalized Receipt or Signed Generalized Receipt. If a receipt
    was requested within IP connection.
     The advantage of the POST data, and additional content asynchronous MDN is to
    be returned, the receipt multipart/report must be combined with that it provides for the other data using some MIME multipart pattern. Real-time EDI
    processing systems may use MIME multipart content-types to
    include rapid return of
     a transfer-layer response EDI message, for example,  from the receiver confirming the receipt of data,
     therefore not requiring a Quote in response TCP/IP connection to a Request-For-Quote transaction.

    Also, if requested, necessarily remain open for very
     long. However, this design requires that the sender may request an asynchronous mode
    for return of receipt. This mode is indicated AS2-MDN contain 
     enough information to uniquely identify the original message so that, when received
     by including the
    metadata for Receipt-delivery-option as explained above.

2.7  Non-Repudiation AS2 Message originator, the status of the POST Reply

    If original AS2 Message can be 
     properly updated based on the reply to a POST operation needs a MDN receipt for non-
    repudiation (for example, contents of the reply includes content other than
    a receipt), AS2-MDN.
     Synchronous MDNs and asynchronous HTTP and HTTPS MDNs are handled 
     according to 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.

    The MDN receipt requirements of this specification. However, asynchronous 
     SMTP MDNs are formatted according the response data is returned using requirements of RFC 3335 [4].

  7.3   Requesting a
    subsequent POST operation. signed receipt
         Message Disposition Notifications are requested as per RFC 2298.  A POST operation used only to transmit
    an MDN MUST NOT include request
         that 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 receiving user agent issue 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 disposition notification is used to combine the MDN with made by
         placing the other
    data, following header into the same as for a POST reply. message to be sent:
             MDN-request-header = "Disposition-notification-to" ":"  mail-address

Moberg, Brooks,  Drummond, Fischer                               	[page 17] 15]

HTTP Transport for Secure EDI                               May 2002

2.8  Error Recovery

    If                               Jan 2003

         This syntax is a residual of the HTTP client fails to read use of MDN's in a SMTP transfer. Since this 
         specification is adjusting the functionality from SMTP to HTTP server response data, and retaining as 
         much as possible from the POST operation with identical content (including Message-ID,
    RefNum, [4] functionality, the mail-address must be present
         but has no meaning in this specification. The mail-address field is specified 
         as an RFC 2822 local-part@domain [addr-spec] address, and other header elements) should while it MUST be repeated, if
         present, it MUST NOT be used in any manner in products. Lack of the
    error condition is transient.

    The Message-ID or RefNum on 
         appropriate syntax WILL BE ignored by the receiving application.
         In addition to requesting a POST operation message disposition notification, an asynchronous 
         message disposition notification can be reused if
    and only if all of the content (including requested by placing the original Date)
    is identical.

    Details of following 
         header into the retry process -- including time intervals message to
    pause, number be sent:
         Receipt-Delivery-Option: return-url

For requesting MDN based receipts, the originator supplies the syntax of retries to attempt, timeouts for retrying -- extension 
  headers that precede the message body.

     The header "tags" are implementation dependent.

    Servers should be prepared as follows:

A    Disposition-notification-to header is added to receive a POST with indicate that a repeated
    Message-ID. The MIME reply body previously sent should be resent,
    including message disposition 
      notification is requested in the MDN and other MIME parts.


3.  Other differences reply 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). POST request. This header is specified
      in [5].  A number
    of other differences exist because HTTP does not conform Message-ID header is added 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 support message reconciliation, so that an
      Original-Message-Id value can handle binary data be returned in the body part of MDN. 
       Other headers, especially "Subject" and so there is no need to use "Date", SHOULD be supplied; the Content transfer encodings values 
       of MIME [MIME]. This difference
    is discussed these headers are 
       often mentioned in [HTTP] section 19.4.4.

3.1.2  Epilogue must be empty

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

3.1.3  Lengthy 
       original message. 
       Disposition-notification-options identifies characteristics of message bodies

    In [AS1], section 5.4.1, disposition
       notification in accordance with  [5].
  EXAMPLE:
    Disposition-notification-to: xxx@temp.org 	// Requests the MDN
    Disposition-notification-options:		// The signing options
       signed-receipt-protocol=optional, pkcs7-signature;	//    for large file processing are
    discussed for SMTP transport. For HTTP, large files should be
    handled correctly by the TCP layer. However, [HTTP] sections
    3.5 and 3.6 discuss some options for compressing or chunking
    entities MDN
       signed-receipt-micalg=optional, sha1, md5
    Receipt-Delivery-Option: return-url		// Requests the MDN
					// to be transferred. Section 8.1.2.2 discusses a
    pipelining option that asynchronous

    Disposition-notification-options syntax:
    Disposition-notification-options =
         "Disposition-Notification-Options" ":"
         disposition-notification-parameters 
where
     disposition-notification-parameters =
                       parameter *(";" parameter)

       where
     parameter = attribute "=" importance ", " 1#value"

      where
     importance = "required" | "optional"

   So the Disposition-notification-options string could be:
     signed-receipt-protocol=optional, <protocol symbol>;
     signed-receipt-micalg=optional, <micalg1>, <micalg2>,...;
     The currently supported value for <protocol symbol> is useful "pkcs7-signature" for segmenting large
    amounts of data. the
      S/MIME detached signature format.
     The currently supported values for MIC algorithm <micalg> values are:
  		Algorithm   Value
   		Used
		--------   -------
   		MD5         md5

Moberg, Brooks,  Drummond, Fischer                               	[page 18] 16]

HTTP Transport for Secure EDI                               May 2002

3.2 Differences in MIME or other headers or parameters used

3.2.1  Content-Length

    Because connections are persistent, closing a connection cannot                               Jan 2003


   		SHA-1       sha1
   
  Receiving agents SHOULD be used able 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 recover gracefully from 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 <micalg> parameter 
   value that they 
   do not be used.

3.2.3  Message-Id and Original-Message-Id recognize.
  Receipt-delivery-option syntax:
  The Message-Id and Original-Message-Id distinction should not
    arise for HTTP transport because SMTP MTA alterations should
    not occur.  Message-Id "receipt-delivery-option: return-url" string indicates the url to return the
   asynchronous MDN. 
  This string is formatted as defined in RFC2822:

       "<" id-left "@" id-right ">"        (RFC2822 3.6.4)

    Message-Id length NOT present if the receipt is a maximum of 998 characters.  For
    maximum backward compatibility, Message-Id length SHOULD to be
    255 characters synchronous. Because the email
   value in Disposition-notification-to has no significance for how or less. Message-Id SHOULD be globally unique,
    id-right should where the receipt
   is transported, the extension header "Receipt-delivery-option" is to be something unique used to the sending host
    environment (e.g. a host name).

    When sending provide
   that information. The receipt-delivery-option's value MUST be a message, always include the angle brackets.
    Angle brackets are not part of URL indicating the Message-Id value.
    For maximum backward compatibility, when receiving a message,
    do not check
   delivery transport destination for angle brackets. When creating the
    Original-Message-Id header in receipt.

  An example request for an MDN, always use the exact
    syntax as received on the original message - don't strip
    or add angle brackets.

3.2.4  Host header

    The host asynchronous MDN via an HTTP transport:
  Receipt-delivery-option: http://www.AS2system.com

  An example request header field must be included in the
    POST for an asynchronous MDN via an HTTP/S transport:
  Receipt-delivery-option: https://www.AS2system.com

  An example 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.









Moberg, Brooks, Drummond, Fischer                          [page 19]

HTTP Transport for Secure EDI                               May 2002


4.  Additional AS2 specific HTTP headers

    The following headers are to be included in all AS2 messages
    and all AS2 MDNs.

4.1  AS2 Version Header

    To promote backward compatibility AS2 includes a version:

       AS2-Version: 1.0

    This header MUST be present an asynchronous MDN via an SMTP transport:
  Receipt-delivery-option: mailto:joe@abc.com
 
  For more information on all AS2 messages and AS2 requesting SMTP MDNs, but not in a single line response (see section 2.4).
    Receiving systems MUST NOT fail due refer to the absence RFC 3335 [4].
  The semantics of the
    AS2-Version header.  This would indicate "signed-receipt-protocol" and the message "signed-receipt-micalg" 
   parameters

  The semantics of the "signed-receipt-protocol" parameter is from
    an older system.

4.2  AS2 System Identifiers as follows:
     1) The receiving system needs "signed-receipt-protocol" parameter is used to obtain request a signed receipt from 
          the identity of recipient trading partner. The "signed-receipt-protocol" parameter also
          specifies the sending
    system. This may be company specific, such as DUNS number, or it
    may format in which the signed receipt should be simply an identification string agreed upon between returned to the
    trading partners. 
          requester.
        The two AS2 headers are:

       AS2-From: < AS2-name >
       AS2-To: < AS2-name >

    These AS2 headers contain textual values, as described below,
    identifying the sender/receiver of "signed-receipt-micalg" parameter is a data exchange. This
    information MUST appear either in list of MIC algorithms preferred by 
        the AS2-From/AS2-To headers
    or requester for use in signing the GISB Form-Data; name="from"/"to" (see appendix B).

     AS2-text = "!" /           ; printable ASCII characters
                %d35-91 /       ; except double-quote (%d34)
                %d93-126        ; or backslash (%d92)
                
     AS2-qtext = AS2-text / SP  ; allow space only in quoted text

     AS2-quoted-pair = "\" DQUOTE /  ; \" or
                       "\" "\"       ; \\
                                           
     AS2-quoted-name = DQUOTE 1*128( AS2-qtext /
                                     AS2-quoted-pair) DQUOTE

     AS2-atomic-name = 1*128AS2-text

     AS2-name = AS2-atomic-name / AS2-quoted-name returned receipt.  The AS2-From header value and the AS2-To header value MUST
    each be an AS2-name, MUST each be comprised list of


Moberg, Brooks, Drummond, Fischer                          [page 20]

HTTP Transport for Secure EDI                               May 2002 MIC algorithms 
        should be honored by the recipient from 1 left to 128 characters right.
       Both the "signed-receipt-protocol" and MUST NOT be folded. the "signed-receipt-micalg" option
        parameters are REQUIRED when requesting a signed receipt.
  The value
    in each lack of these headers the presence of the "Receipt-Delivery-Option" indicates a receipt is case-sensitive.
       synchronous in nature. 
  The AS2-quoted-name SHOULD be used only if presence of the AS2-name
    does not conform "Receipt-Delivery-Option: return-url" indicates that an 
       asynchronous receipt is requested and should be sent to AS2-atomic-name. the "return-url".
     2) The string definitions given above are "importance" attribute of "Optional" is defined in ABNF format.

4.2.1  Unrecognized System Identifiers

    If either the AS2-From or the AS2-To or RFC 2298 
         section 2.2 and has the combination following meaning:
          Parameters with an importance of both
    header values is determined to be invalid or unknown by the
    receiving system, "Optional" permit a UA that does not 
          understand the receiving system MAY respond particular options parameter to still generate a MDN in one of
    the following ways, but is not limited response
          to these options:

        1. The receiving AS2 system MAY disconnect from the
           sending AS2 system before completing the reception of a request for a MDN. A UA that does not understand the entire entity if it determines "signed-receipt-
          protocol" parameter,  or the HTTP headers
           do "signed-receipt-micalg" will obviously not represent return a valid trading-relationship.

        2. 
          signed receipt.
          The receiving AS2 system MAY disconnect from the
           sending AS2 system before completing the reception importance of "Optional" is used for the entire entity if signed receipt parameters because 
          it determines the entity
           being sent is too large to process.

        3. The receiving AS2 system MAY return RECOMMENDED that an HTTP response
           with a response code in the 2xx range, with or without
           any explanation of MDN be returned to the error, requesting trading 
          partner even if the sending
           system requested an MDN.

        4. recipient could not sign it.
          The receiving AS2 system MAY return an unsigned returned MDN
           with will contain information on the disposition of the message as
          well as why the MDN could  not be signed. See the Disposition field in section 
          7.5 for more information.
          Within an explanation EDI trading relationship, if a signed receipt is expected and is not 
          returned, then the validity of the error, transaction is up to the trading partners to resolve.
          In general, if a signed receipt is required in the sending
           system requested an MDN. trading relationship and is not 
         received, the transaction will likely not be considered valid.

Moberg, Brooks,  Drummond, Fischer                               	[page 21] 17]

HTTP Transport for Secure EDI                               May 2002

Appendices

A.  AS2 MIME templates

Structure of an AS2 MIME message - PGP/MIME

No encryption, no signature (analog of 4.2.1)

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

No encryption, signature (analog of 4.2.2)

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

Encryption, no signature (analog of 4.2.3)

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

Encryption, signature (analog of 4.2.4)

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

Structure of an AS2 MIME message - S/MIME

No encryption, no signature (analog of 4.3.1)

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

No encryption, signature (analog of 4.3.2)

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


Moberg, Brooks, Drummond, Fischer                          [page 22]

HTTP Transport for Secure EDI                               May 2002

Encryption, no signature (analog of 4.3.3)

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

Encryption, signature (analog of 4.3.4)

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


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

    GISB AS2 Profile                               Jan 2003

      7.3.1   Signed Receipt Considerations
                The United States based Gas Industry Standards Board (GISB) is method used to request a
    consortium of companies and individuals that operate receipt or a signed receipt is defined in the Gas
    Industry. 
                RFC 2298,
                 "An Extensible Message Format for Message Disposition Notifications". 
  The membership "rule" is:
      1) When a receipt is divided into 5 sectors, Producers,
    Pipelines, Services, End Users, Local Distribution Companies,
    representing requested, explicitly specifying that the various type of organizations within receipt be signed, then
          the
    industry. In 1996 GISB initiated receipt MUST  be returned with a program to move from signature.
      2) When a receipt is requested, explicitly specifying that the
    expensive Value Added Networks they were using, to receipt be signed, but
          the Internet.
    By October of 1996GISB had developed and tested recipient cannot support either the requested protocol format, or requested
          MIC algorithms, then either a protocol,
    called GISB Electronic Delivery Mechanism (EDM), which uses HTTP
    and signed or unsigned receipt SHOULD be returned.
      3) When a signature is based on RFC1867 (Form-based File Upload in HTML). By
    May 1997 this protocol was being used not explicitly requested, or if the signed receipt request 
          parameter is not recognized by Enron and others to
    send/receive live, mission critical business transactions over the Internet.  Additional companies followed suit and UA, then no receipt, an unsigned receipt, or a large
    percentage of today's business transactions in the Gas Industry
    are transmitted over 
          signed receipt MAY  be returned by the recipient.

NOTE: For Internet using the GISB EDM protocol. In
    1998 the Automobile Industry Action Group (AIAG) adopted EDI, it is RECOMMENDED that when a signature is not explicitly
            requested, or if parameters 
             are not recognized, that the GISB
    EDM protocol and UA send back at a minimum, an unsigned receipt.  
            If a signed receipt however was always returned as a policy, whether   
            requested or not, then any false unsigned receipts can be repudiated.
           When a request for a signed receipt is made, but there is an error in 1999 the local electric companies serving processing
            the
    state contents of Pennsylvania declared the GISB protocol as their
    standard message, a signed receipt MUST still be returned. The
            request for transmitting business transactions via the Internet.

    In May of 1999 a signed receipt SHALL still be honored, though the AIAG, GISB and members of transaction
             itself may not be valid.   The reason for why the IETF EDIINT
    workgroup initiated an effort to converge their independent
    specifications, contents could not be processed 
            MUST be set in the result of which "disposition-field".
          When a request for a signed receipt is this specification. In
    order to bring made, the GISB EDM into compliance with this
    specification GISB initiated a formal change "Received-content-MIC" MUST
          always be returned to the EDM
    specification. requester. 
          The following information, referred to "Received-content-MIC" MUST be calculated as follows:
                    - For any signed messages, the
    "GISB AS2Profile", reflects the planned utilization of this
    specification by the GISB membership.

    The GISB membership will utilize PGP MIC to meet all P.A.I.N.
    requirements. All data exchanges will utilize be returned is calculated on the multipart/form-
    data enveloping method and two generalized receipts,
    GISB-Acknowledgement-Receipt 
                      RFC1767 MIME header and GISB-Error-Notification. All

Moberg, Brooks, Drummond, Fischer                          [page 23]

HTTP Transport for Secure EDI                               May 2002

    original business transactions must content. 
                      Canonicalization as specified in RFC 1848 MUST be digitally signed (using
    encapsulated signatures) and encrypted using RSA algorithms. Upon
    successful transfer of an original business transaction performed before
                     the
    receiver MIC is required to send a GISB-Acknowledgement-Receipt
    indicating that calculated, since the transfer has completed successfully. If, upon
    further processing of 
                      sender requesting the business document an error is
    encountered a GISB-Error-Notification is sent signed receipt was also REQUIRED to canonicalize.
                    - For encrypted, unsigned messages, the original
    sender using the multipart/form-data enveloping.

    It MIC to be returned is expected that companies following calculated
                      on the GISB AS2 profile will
    protect their web sites from unauthorized access through the use
    of basic authentication (username/passwords), as defined in decrypted RFC 1767 MIME header and content. The content after
                      decryption MUST be canonicalized before the
    HTTP specification. GISB MIC 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:

        FROM:
        Contains the DUNS number of the sending party

        TO:
        Contains the DUNS number of calculated.
                    - For unsigned, unencrypted messages, the intended recipient

        INPUT-FORMAT:
        Type of data being sent (only x12 and error currently
        supported) other options can easily MIC MUST be added calculated over
                      the message contents prior to this list.

        INPUT-DATA:
        The actual payload containing Content-Tranfer-Encoding and without the business transaction
                      MIME or
        GISB-Error-Notification.  If the payload contains a business
        transaction it is signed any other RFC 822 headers, since these are sometimes
                      altered or reordered by MTAs.

  7.4   MDN Format and encrypted using PGP.

        Version:
        The GISB version number (currently 1.3)

        RECEIPT-DISPOSITION-TO:
        The DUNS number of the party to receive value
          This section defines the
        GISB-Acknowledgement-Receipt (typically format of the same DUNS
        number associated with AS2 Message Disposition Notification 
          (AS2-MDN).
    7.4.1   AS2-MDN General Formats
              The AS2-MDN follows the From header.) Presence of MDN specification [5] except where noted in 
              this
        field also serves as a flag indicating that an
        acknowledgement receipt is requested by the sender. section. 
              The
        receipt is returned synchronously (on modified entity definitions in this document use the same session
        used vertical-bar character,
              '|', to denote a logical "OR"
              construction. This usage follows RFC 2616 [3]. HTTP entities referred to send the input-data payload).

        RECEIPT-REPORT-TYPE:
        Contains the value GISB-Acknowledgement-Receipt.

    Optional headers also available:

        TRANSACTION-SET:
        Identifies the type of transaction contained 
              below are not further defined in 
              this document. Refer to RFC 2616 [3] for complete definitions of HTTP entities. 
             The format of the
        input-data payload. AS2-MDN is
                   AS2-MDN = AS2-sync-MDN | AS2-async-http-MDN | AS2-async-smtp-MDN
                   AS2-sync-MDN =
                   Status-Line
    *(( general-header | response-header | entity-header ) CRLF )
             CRLF
             AS2-MDN-body

Moberg, Brooks,  Drummond, Fischer                               	[page 24] 18]

HTTP Transport for Secure EDI                               May 2002

        RECEIPT-SECURITY-SELECTION:
        This field serves                               Jan 2003


    Status-Line =
       HTTP-Version SP Status-Code SP Reason-Phrase CRLF

    AS2-async-http-MDN =
        Request-Line
    *(( general-header | request-header | entity-header ) CRLF )
        CRLF
        AS2-MDN-body 

    Request-Line =
        Method SP Request-URI SP HTTP-Version CRLF

    AS2-async-smtp-MDN =
        *(( general-header | request-header | entity-header ) CRLF )
        CRLF
        AS2-MDN-body 

    AS2-MDN-body =
        AS2-signed-MDN-body | AS2-unsigned-MDN-body

      7.4.2    AS2-MDN Construction
                 The AS2-MDN-body is formatted as a flag indicating that MIME multipart/report with a signed
        receipt is being requested. The contents 
                  report-type of this field
        indicate the algorithm and signature type to use in
        constructing "disposition-notification".
                 When unsigned, the signature.

    Example transfer-layer ( "outermost" ) entity-headers of the
                 AS2-MDN contain the content-type header that specifies a GISB data exchange:

        The sending party creates an X12 business transaction content-type
                 of "multipart/report" and
        concatenates with an RFC 1767 compliant header. The entire
        package is then encrypted parameters indicating the report-type, and signed using PGP. The encrypted
        package the 
                 value of the outermost multipart boundary.
                 When the AS2-MDN is then enveloped with signed, the appropriate headers/values transfer-layer ( "outermost" ) 
                 entity-headers of the AS2-MDN contain a content-type header that 
                 specifies a content-type of "multipart/signed" and sent parameters indicating the 
                 algorithm used to compute the trading partner using HTTP POST, message digest, 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;
       boundary=---------------------------87453838942833
    Content-Length: 5379

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

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

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

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

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

    GISB-Acknowledgement-Receipt
    -----------------------------87453838942833
    Content-Disposition: form-data; name="input-format"

    x12
    -----------------------------87453838942833
    Content-Disposition: form-data; name="input-data";
      filename=c:\temp\smallnom.bin	

Moberg, Brooks, Drummond, Fischer                          [page 25]

HTTP Transport for Secure EDI                               May 2002

    Content-Type: multipart/encrypted; boundary=9876;
      protocol="application/pgp-encrypted"

    --9876
    Content-Type: application/pgp-encrypted

    Version: 1

    --9876
    Content-Type: application/octet-stream

    -----BEGIN PGP MESSAGE-----
    Version: PGP 6.5

    hQCMAzRG1pEOIOvdAQP+JMr0m/9+8yOL60Z9Vr6fFV81FCExB/o0xmwiMkiwYsHs
    z0e8sb7ErC340MrNA/dw3taGMjmI+CXYRF/PLEdg1NZE1ZCtNeL4YdIHAMLWwODG
    lQxhSucz8rMSgQ5mZzcOJwBdWLW70efgsu/9UljuJjYc1uZ6C03eFQv/43fkB+al
    ATtgydxX4g8QK664ad+Jo/XUICSmWBL66fqJR1KLeLf4wTaqGy174Aq48Wpwvg1E
    h785zC03UAw0qg0ugMt86dPeyd91e2JigqwDYEf/DYEKD0J9BGiGpS/uAupNKj8O
    aqx2Dq/ra9g65HNchOCzjul5Vi8HHf6Yhg2WnROe+npByyCue6rihqgNVOJwj0cV
    zpb4JE+gMDf3q4ISUb1Fv7/+SSFHDdnhdC5YTpqf1Bc3B07hiLmtTXqNit31EbX9
    UVElObzSa9ZhxbC6/eSl7Nuf5ZTDsh9nrk+QQJ6FeC9W4cqXLj7IZySaRO8Vtff+
    4ktqeuhYusT4kSpnk027aw4O/5jomUkfb22CAe4=
    =Oiuo
    -----END PGP MESSAGE-----

    --9876--

    -----------------------------87453838942833--

        Upon receiving signature formatting 
                 protocol ( e.g. pkcs7-signature ), and the above stream value of data the receiving host
        parses outermost multipart
                 boundary. The first part of the headers and returns MIME multipart/signed message is 
                 an unsigned
        GISB-Acknowledgement-Receipt, appearing as follows:

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

    --GISB7867
    Content-type: text/html

    <HTML><HEAD><TITLE>Acknowledgement Receipt Success</TITLE></HEAD>
    <BODY><P>
    time-c=19960619082855*
    request-status=ok*
    server-id=coolhost*
    trans-id=234423897*
    </P> </BODY></HTML>

    --GISB7867
    Content-type: text/plain



Moberg, Brooks, Drummond, Fischer                          [page 26]

HTTP Transport for Secure EDI                               May 2002

    time-c=19960619082855*
    request-status=ok*
    server-id=coolhost*
    trans-id=234423897*

    --GISB7867--


C.  Samples embedded MIME multipart/report of AS2 Protocol Data Units

C.1 type "disposition-notification". The following example illustrates
                 second part of the full HTTP request that
    sends X12 EDI data from company1 to company2. A signed receipt is
    requested; multipart/signed message contains a MIME 
                 application/pkcs7-signature message.
                 The first part of the receipt MIME multipart/report is to be a MDN report-type, with the pkcs7
    signature option, using "human-readable" portion 
                 that contains a signature algorithm general description of rsa-md5. the message disposition. The receipt second 
                 part of the MIME multipart/report is a "machine-readable" portion 
                 that is defined as AS2-disposition-notification-content =
                            [ reporting-ua-field CRLF ]
                            [ mdn-gateway-field CRLF ]
                            final-recipient-field CRLF
                            [ original-message-id-field CRLF ]
      AS2-disposition-field CRLF
        *( failure-field CRLF )
        *( error-field CRLF )
        *( warning-field CRLF )
        *( extension-field CRLF )
          [ AS2-received-content-MIC-field CRLF ]

    7.4.3   AS2-MDN Fields
              The rules for constructing the AS2-disposition-notification-content are identical
               to be sent synchronously (that is, the rules for constructing the disposition-notification-content as defined in
               section 7 of RFC 2298 [5] except that 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
AS2-To: zzzcompany2
AS2-From: zzzcompany1
AS2-Version: 1.0
From: ediadmin@company1.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

--20011106RsXgYlvCNW
Content-Type: application/edi-x12
Content-Disposition: Attachment; filename=rfc1767.dat
  [ISA ...EDI transaction data...IEA...]

--20011106RsXgYlvCNW
Content-Type: application/pkcs7-signature

  [omitted binary pkcs7 signature data]
--20011106RsXgYlvCNW--








Moberg, Brooks, Drummond, Fischer                          [page 27]

HTTP Transport for Secure EDI                               May 2002

C.2 This second example illustrates returning a signed MDN RFC 2298 disposition-field has
               been replaced with the AS2-disposition-field and that corresponds to the request for a MDN found in C.1.

        HTTP/1.0 200 OK
        Server: HTTPEDI/1.1
        AS2-To: zzzcompany1
        AS2-From: zzzcompany2
        AS2-Version: 1.0
        Content-type: multipart/signed; boundary="boundary1"
        Content-Length: 1200

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

        --boundary2
        Content-type: text/plain

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

        --boundary2
        Content-type: message/disposition-notification

        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

        --boundary2--

        --boundary1
        Content-Type: application/pkcs7-signature

           [Signature data omitted]
        --boundary1--


D. Acknowledgments

   Carl Hage, Karen Rosenfeld, Chuck Fenton AS2-received-
              -content-MIC field has been added. The differences between the RFC 2298 
               disposition-field and many others have
   provided valuable suggestions improving the AS2-disposition-field are described below. Where
              there are differences between this applicability
   statement.

E. References

 [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax
     Specifications: ABNF", document and RFC 2234, November 1997

 [AS1]  T. Harding, R. Drummond, C. Shih, "Peer-to-Peer
     MIME-based Secure Business Data Interchange", April 2002,
     Internet draft: draft-ietf-ediint-as1-17.txt. 2298, those entity

Moberg, Brooks,  Drummond, Fischer                               	[page 28] 19]

HTTP Transport for Secure EDI                               May 2002

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

 [FORMDATA]  L. Masinter, "Returning Values                               Jan 2003


              names have been changed by prepending "AS2-". Entities below that do not
              differ from Forms:
     multipart/form-data", RFC 2388, August, 1998.

 [GISB]  Gas Industry Standards Board, "Electronic Delivery
       Mechanism Related Standards", Version 1.3 July 31, 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/>

 [HTTP]  R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners-Lee,
     "Hypertext Transfer Protocol--HTTP/1.1", 2298 are not necessarily further defined in this document. 
              Refer to RFC 2068,   March 1997.

 [MIME]  N. Borenstein, N. Freed, "Multipurpose Internet Mail
     Extensions (MIME) Part One: Format 2298 for AS2-MDN entities that are not further defined in 
              this document.
  AS2-disposition-field =
      "Disposition" ":" disposition-mode ";"
      AS2-disposition-type [ '/' AS2-disposition-modifier ]

  disposition-mode =
      action-mode "/" sending-mode

  action-mode =
      "manual-action" | "automatic-action"

  sending-mode =
      "MDN-sent-manually" | "MDN-sent-automatically"

  AS2-disposition-type =
      "processed" | "failed"

  AS2-disposition-modifier =
      ( "error" | "warning" ) | AS2-disposition-modifier-extension

  AS2-disposition-modifier-extension =
      "error: authentication-failed" |
      "error: decompression-failed" |
      "error: decryption-failed" |
      "error: insufficient-message-security" |
      "error: integrity-check-failed" |
      "error: unexpected-processing-error" |
      "warning: " AS2-MDN-warning-description |
    "failure: " AS2-MDN-failure-description

  AS2-MDN-warning-description = *( TEXT )

  AS2-MDN-failure-description = *( TEXT )

  AS2-received-content-MIC-field =
      "Received-content-MIC" ":" encoded-message-digest "," digest-alg-id CRLF

  encoded-message-digest =
      1*( 'A'-Z' | 'a'-'z' | '0'-'9' | '/' | '+' | '=' )  ( i.e. base64( message-digest ) )

  digest-alg-id = "sha1" | "md5"

"Insufficient-message-security" and "decompression-failed" are newer error codes to
     this specification, are not mentioned in the AS1 RFC, and may not be compatible
     with earlier implementations of Internet Message Bodies", AS2. The "Received-content-MIC" extension field 
     is set when the integrity of the received message is verified. 
    The MIC is the base64-encoded message-digest computed over the received 
     message with a hash function. 
    This field is required for signed receipts but optional for unsigned receipts. For 
    details defining the specific content over which the message-digest is to be computed,
    see Section 7.3.1 of this document.
    The algorithm used to calculate the message-digest MUST be the same as the
    "micalg" value used by the sender in the multipart/signed message. When no
    signature is received, or the micalg parameter is not  provided then the SHA-1 
    algorithm SHOULD be used to calculate the MIC. This field is set only when 

Moberg,  Drummond,                               	[page 20]

HTTP Transport for Secure EDI                               Jan 2003

     the contents of the message are processed successfully. This field is used in 
     conjunction with the recipient's signature on the MDN in order for the sender to 
     verify non-repudiation of receipt.
    AS2-MDN field names ( e.g. "Disposition:", "Final-Recipient:") are case-insensitive
    ( cf. RFC 2298, 3.1.1 ). 
    AS2-MDN action-modes, sending-modes, AS2-disposition-types, and AS2-
    disposition-modifier values that are defined above, and user-supplied *( TEXT ) values 
    are also case-insensitive. AS2 implementations MUST NOT make assumptions 
    regarding the values supplied for AS2-MDN-warning-description, AS2-MDN-failure-
    -description nor for the values of any (optional) error, warning, or failure fields.

      7.4.4   Additional AS2-MDN Programming Notes
                 1. Unlike SMTP, for HTTP transactions, Original-Recipient and Final 
                     Recipient should not be different. The value in Original-Message-ID 
                     SHOULD match the original Message-ID header value.  
                 2. Refer to RFC 2298 for the formatting of the MDN except for the 
                     specific deviations mentioned above.
                 3. Refer to RFC 1892 and RFC 2298 for the formatting of the content-type 
                     entity-headers for the MDN.
                 4. Use an action-mode of "automatic-action" when the disposition described
                     by the  disposition type was a result of an automatic action, rather than an 
                     explicit instruction by the user for this message.
                 5. Use an action-mode of "manual-action" when the disposition described 
                     by the disposition type was a result of an explicit instruction by the user
                     rather than some sort of automatically performed action.
                 6. Use a sending-mode of "MDN-sent-automatically" when the MDN is 
                     sent because the UA had previously been configured to do so.
                 7. Use a sending-mode of "MDN-sent-manually" when the user explicitly 
                     gave permission for this particular MDN to be sent.
                 8. The sending-mode "MDN-sent-manually" is ONLY meaningful with
                     "manual-action", not with "automatic-action".
                 9. The "failed" disposition type MAY NOT be used for the situation in 
                     which there is some problem in
                     processing the message other than interpreting the request for an MDN.
                    The "processed" or other disposition type with appropriate disposition 
                     modifiers is to be used in such situations.
  7.5   Disposition Mode, Type, and Modifier
    7.5.1   Disposition Mode Overview
              This section would provide a brief overview of how processed, error, failure,
              and warnings are used.
    7.5.2 Successful Processing status indication
             When the request for a receipt or signed receipt, and the received message 
             contents are successfully processed by the receiving EDI UA, a receipt or 
             MDN SHOULD be returned with the  "disposition-type" set to 'processed'. 
             When the MDN is sent automatically by the EDI UA, and there is no explicit 
             way for a user to control the sending of the MDN, then the first part of the 
             "disposition-mode" should be set to "automatic-action". 
             When the MDN is being sent under user configurable control, then the first 
             part of the "disposition-mode" should be set to "manual-action". Since a
             request for a signed receipt should always be honored, the user MUST not be
             allowed to configure the UA to not send a signed receipt when the sender 
             requests one.

             The second part of the "disposition-mode" is set to "MDN-sent-manually" if the 
             user gave explicit permission for the MDN to be sent. Again, the user MUST
             not be allowed to explicitly refuse to send a signed receipt when the sender 
             requests one. The second part of the "disposition-mode" is set to "MDN-sent-
             -automatically" whenever the EDI UA sends the MDN automatically, regardless 
             of whether the sending was under a user's, administrator's, or under software
             control.


Moberg,  Drummond,                               	[page  21]

HTTP Transport for Secure EDI                               Jan 2003

             Since EDI content is generally handled automatically by the EDI UA, a 
             request for a receipt or signed receipt will generally return the following in the
            "disposition-field":
             Disposition: automatic-action/MDN-sent-automatically; processed
  Note this specification does not restrict the use of the "disposition-mode" to just automatic actions. 
            Manual actions are valid as long as it is kept in mind that a request for a signed 
            receipt MUST be honored.

    7.5.3   Unsuccessful processed Content
              The request for a signed receipt requires the use of two 
              "disposition-notification-options", which specify the protocol format of the 
               returned signed receipt, and the MIC algorithm used to calculate the MIC over
               the message contents. The "disposition-field" values that should be used in the 
              case where the message content is being rejected or ignored, for instance if the 
              EDI UA determines that a signed receipt cannot be returned because it does not 
              support the requested protocol format, so the EDI UA chooses not to process the
              message contents itself, should be specified in the MDN "disposition-field" as follows:
                           Disposition: "disposition-mode";  failed/Failure: unsupported format
                           The "failed" AS2-disposition-type should be used when a failure occurs that
                           prevents the proper generation of an MDN. 
                           For example, this disposition-type would apply if the sender of the message
                           requested the application of an unsupported message-integrity-check (MIC) 
                          algorithm.
                          The "failure:" AS2-disposition-modifier-extension should be used with an
                          implementation-defined description of the failure. 
                          Further information about the failure may be contained in a failure-field.
                         The syntax of the "failed" "disposition-type" is general, allowing the sending 
                         of any textual information along with the "failed"  "disposition-type". 
                         Implementations WILL support any printable textual characters after the 
                         Failure disposition-type.  
     For use in Internet EDI, the following "failed" values are pre-defined and MUST be
     supported:
              "Failure: unsupported format"
              "Failure: unsupported MIC-algorithms"

    7.5.4    Unsuccessful Non-Content Processing 
               When errors occur processing the received message other than content, the
               "disposition-field" should be set to the "processed" "disposition-type" value and 
                the "error" "disposition-modifier"  value.
               The "error" AS2-disposition-modifier with the "processed" disposition-type 
               should be used to indicate that an error of some sort occurred that prevented
               successful processing of the message. Further information may be contained
               in an error-field.
               An "error:" AS2-disposition-modifier-extension should be used to combine the
               indication of an error with a pre-defined description of a specific, well-known
               error. Further information about the error may be contained in an error-field.
               For use in Internet EDI, the following "error"  "disposition-modifier" values are
               defined:
                        "Error: decryption-failed" - the receiver could not decrypt the message 
                         contents.
                        "Error: authentication-failed" - the receiver could not authenticate the
                         sender.
                        "Error: integrity-check-failed" - the receiver could not verify content 
                         integrity.
                        "Error: unexpected-processing-error" - a catch-all for any additional 
                         processing errors.
    An example of how the "disposition-field" would look when other than content
    processing errors are detected is as follows:
EXAMPLE

Moberg,  Drummond,                               	[page 22]

HTTP Transport for Secure EDI                               Jan 2003

    Disposition: "disposition-mode";   processed/Error: decryption-failed
    7.5.5   Processing Warnings
              Situations arise in EDI where even if a trading partner cannot be authenticated
              correctly, the trading partners still agree to continue processing the EDI 
              transactions. Transaction reconciliation is done between the trading 
              partners at a later time. In the content processing warning situations as 
              described above, the "disposition-field' SHOULD be set to the "processed" 
             "disposition-type" value, and the "warning" "disposition-modifier" value. 
              The "warning" AS2-disposition-modifier should be used with the "processed" 
              disposition-type to indicate that the message was successfully processed but 
              that an exceptional condition occurred. Further information may be contained
              in a warning-field.
              A "warning:" AS2-disposition-modifier-extension should be used to combine
              the indication of a warning with an implementation-defined description of the
              warning. Further information about the warning may be contained in an 
              warning-field.
  For use in Internet EDI, the following "warning" "disposition-modifier" values are defined:
            "Warning: authentication-failed, processing continued"
  
An example of how the "disposition-field" would look when other than content 
processing warnings are detected is as follows:
            EXAMPLE
                   Disposition: "disposition-mode"; processed/Warning:
                          authentication-failed, processing continued
    7.5.6   Backwards Compatibility with Disposition Type, Modifier and Extension
              The following set of examples represent typical constructions of the 
              Disposition field that have been in use by AS2 implementations. This is NOT
              an exhaustive list of possible constructions. However, AS2 implementations
              MUST accept constructions of this type to be backward compatible with
              earlier AS2 versions.
  Disposition: automatic-action/MDN-sent-automatically; processed

  Disposition: automatic-action/MDN-sent-automatically; processed/error: 
              authentication-failed

  Disposition: automatic-action/MDN-sent-automatically; processed/warning: 
              duplicate-document

  Disposition: automatic-action/MDN-sent-automatically; failed/failure: 
          sender-equals-receiver
   The following set of examples represent allowable constructions of the Disposition 
   field that combine the historic constructions above with optional RFC 2298 error, 
   warning and failure fields. AS2 implementations MAY produce these constructions.
   However, AS2 servers are not required to recognize or process optional error, 
   warning, or failure fields at this time. Note that the use of the multiple Error fields in
   the second example below provides for the indication of multiple error conditions.
      Disposition: automatic-action/MDN-sent-automatically; processed

      Disposition: automatic-action/MDN-sent-automatically; processed/error: 
               decryption-failed
      Error: The signature did not decrypt into a valid PKCS#1 Type-2 block.
      Error: The length of the decrypted key does not equal the octet-length of the 
                modulus.

      Disposition: automatic-action/MDN-sent-automatically; processed/warning: 
               duplicate-document
      Warning: An identical message already exists at the destination server.

      Disposition: automatic-action/MDN-sent-automatically; failed/failure: 

Moberg,  Drummond,                               	[page 23]

HTTP Transport for Secure EDI                               Jan 2003

               sender-equals-receiver
      Failure: The AS2-To name is identical to the AS2-From name.

  The following set of examples represent allowable constructions of the Disposition 
  field that employ pure RFC 2298 Disposition-modifiers with optional error, warning 
  and failure fields. These examples are provided as informational only. These 
  constructions are not guaranteed to be backward compatible with AS2 
  implementations prior to version 1.1.
       Disposition: automatic-action/MDN-sent-automatically; processed

       Disposition: automatic-action/MDN-sent-automatically; processed/error
       Error: authentication-failed
       Error: The signature did not decrypt into a valid PKCS#1 Type-2 block.
       Error: The length of the decrypted key does not equal the octet-length of the
                 modulus.

       Disposition: automatic-action/MDN-sent-automatically; processed/warning
      Warning: duplicate-document

       Disposition: automatic-action/MDN-sent-automatically; failed
       Failure: sender-equals-receiver
  7.6    Receipt Reply Considerations in a HTTP POST
          The details of the response to the POST command vary depending upon 
          whether  a 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 administrators 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 [9] or multipart/signed
          [6]) should be included in the Response entity headers.
 
           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 ([5] 
           section 3.1) value should be derived from the entity headers of the request.

          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

Moberg,  Drummond,                               	[page 24]

HTTP Transport for Secure EDI                               Jan 2003

          the SMTP context).

  8.   Public key certificate handling
        In the near term, the exchange of public keys and certification of these keys
         must be handled as part of the process of establishing a trading partnership. 
        The UA and/or EDI application interface must maintain a database of public keys 
        used for encryption or signatures, in addition to the mapping between EDI 
        trading partner ID and RFC 822 [11] email address and http URL/URI. The 
        procedures for establishing a trading partnership and configuring the secure
        EDI messaging system might vary among trading partners and   software 
        packages. 
        X.509 certificates are REQUIRED. It is RECOMMENDED that trading partners
        self-certify each other if an agreed upon certification authority is not used. This
        applicability statement does NOT require the use of a certification authority. 
        The use of a certification authority is therefore OPTIONAL. Certificates may be 
        self-signed.
        It is RECOMMENDED that when trading partners are using S/MIME, that they
        also exchange public key certificates using the recommendations specified in the 
        S/MIME Version 3 Message  Specification. The message formats and S/MIME
        conformance  requirements for certificate exchange are specified in this document.
        In the long term, additional Internet-EDI standards may be developed to simplify 
        the process of establishing a trading partnership, including the third party 
        authentication of trading partners, as well as attributes of the trading relationship

.
  9.   Security Considerations
       This entire document is concerned with secure transport of business to business 
       data, and considers both privacy and authentication issues.
       Extracted from S/MIME Version 2 Message Specification:    40-bit encryption is 
       considered weak by most cryptographers. 
       Using weak cryptography offers little actual security over sending  plaintext. 
       However, other features of S/MIME, such as the specification of tripleDES or 
       AES and the ability to announce  stronger cryptographic capabilities to parties with 
       whom you communicate, allow senders to create messages that use strong  
       encryption. Using weak cryptography is never recommended unless  the only
       alternative is no cryptography. When feasible, sending and receiving agents should 
       inform senders and recipients the relative cryptographic strength of messages.
       Extracted from S/MIME Version 2 Certificate Handling:  When processing 
       certificates, there are many situations where the processing might fail. Because the
       processing may be done by a user agent, a security gateway, or other program, there
       is no single way to handle such failures. Just because the methods to handle the 
       failures has not been listed, however, the reader should not assume that they are not
       important.  The opposite is  true: if a certificate is not provably valid and associated
      with the message, the processing software should take immediate and noticeable 
       steps to inform the end user about it.
       Some of the many places where signature and certificate checking might fail include:
          - no certificate chain leads to a trusted CA
          - no ability to check the CRL for a certificate
          - an invalid CRL was received
          - the CRL being checked is expired
          - the certificate is expired
          - the certificate has been revoked
     There are certainly other instances where a certificate may be invalid, and it is the 
     responsibility of the processing software to check them all thoroughly, and to decide 
     what to do if the check fails.
     The following certificate types MUST be supported.
            With URL
            Without URL
            Self Certified
    Certification Authority Certified

Moberg,  Drummond,                               	[page 25]

HTTP Transport for Secure EDI                               Jan 2003

    The URL, which matches the source server identity, SHOULD be carried in the 
    certificate. However, the receiver SHOULD NOT expect that the certificate would 
    contain a matching URL. Since the certificates were exchanged with the establishing
    of the trading partner relationship, the server identify may be ignored.
    The complete certification chain MUST  be included in all certificates.  All certificate
    verifications MUST "chain to root". Additionally, the certificate hash should match the
    hash recomputed by the receiver.

  10.    Acknowledgements
          Carl Hage, Karen Rosenfeld, Chuck Fenton and many others have provided 
          valuable suggestions improving this applicability statement. The authors would also
          like to thank the vendors who participated in the Drummond Group Inc AS2
          interoperability testing. Their contributions led to great improvement in the clarity 
          of this document.

11.   References

  [1]  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, 2049 ,
        December 02, 1996.

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

 [MIMEPGP]  M. Elkins, "MIME Security With Pretty Good Privacy
     (PGP)",
  [3]    R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext Transfer 
          Protocol--HTTP/1.1", RFC 2015, Sept. 1996.

 [MDN] 2616,   March 1997.
  [4]    T. Harding, R. Drummond, C. Shih, "Peer-to-Peer MIME-based Secure 
          Business Data Interchange", RFC 3335, September 2002.
  [5]    R. Fajman, "An Extensible Message Format for Message Disposition 
          Notifications", RFC 2298, March 1998.

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

 [SMTP]  P. Resnick, Editor "Internet 
  [7]     J. Postel, "Simple Mail Format", RFC 2822,
     April 2001.

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

 [SMIMEV3]  821, August 1, 1982.
  [8]    B. Ramsdell, "S/MIME Version 3 Message Specification", Specification;  Cryptographic
          Message Syntax", RFC 2633, 2633 RFC 2630, June 1999.

 [REPORT]
  [9]    G. Vaudreuil, "The Multipart/Report Content Type for the Reporting of Mail 
          System Administrative Messages", RFC 1892,   March 15, 1996.
  [10]  T. Dierks,C. Allen, "The TLS Protocol Version 1.0" RFC 2246,  March 1999.
  [11]  D. Crocker, "Standard for the Format of ARPA Internet Text   Messages", STD
          11,  RFC 822, August 13, 1982.
  [12]  E. Whitehead, M. Murata, "XML Media Types", RFC 2376, July 1998.
 
  12.   Authors' Addresses

    Dale Moberg
    dmoberg@cyclonecommerce.com
    Cyclone Commerce
    8388 E. Hartford Drive, Suite 100
    Scottsdale, AZ  85255 USA

    Dick Brooks
    dick.brooks@systrends.com
    Systrends, Inc
    7855 South River Parkway, Suite 111
    Tempe, Arizona  85284   USA

    Rik Drummond
    Rvd2@drummondgroup.com
    Drummond Group Inc.
    4700 Bryant Irvin Court
    Fort Worth, TX  76107 USA

  Appendices
    A.   Message Examples
  NOTE: All examples are provided as an illustration only, and are not considered part of
              the protocol specification. 
              If an example conflicts with the protocol definitions specified above or in the 
              other referenced RFC's, the example is wrong.
      A.1    Signed message requesting a signed, synchronous receipt

      POST /invoke/wm.EDIINT/receive HTTP/1.0
      Host: 208.234.160.12:80
      User-Agent: AS2 Company Server
      Date: Wed, 31 Jul 2002 13:34:50 GMT
      From: mrAS2@as2.com
      AS2-Version: 1.1
      AS2-From: "\"  as2Name  \""
      AS2-To: "0123456780000"
      Subject: G1
      Message-Id: <200207310834482A70BF63@\"~~foo~~\">
      Disposition-Notification-To: mrAS2@as2.com
      Disposition-Notification-Options: signed-receipt-protocol=optional,pkcs7-signature; 
         signed-receipt-micalg=optional,sha1
      Content-Type: multipart/signed; boundary="as2BouNdary1as2";
         protocol="application/pkcs7-signature"; micalg=sha1
      Content-Length: 2464

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

Moberg,  Drummond,                               	[page 26]

HTTP Transport for Secure EDI                               Jan 2003

      [ISA ...EDI transaction data...IEA...]

      --as2BouNdary1as2
      Content-Type: application/pkcs7-signature

        [omitted binary pkcs7 signature data]
      --as2BouNdary1as2--

    A.2   MDN for Message A.1 Above
             HTTP/1.0 200 OK
             Set-Cookie: ssnid=35MdRcIFhez60mO6UDq+JDMWoumBQ=666612; path=/;
             AS2-From: "0123456780000"
             AS2-To: "\"  as2Name  \""
             AS2-Version: 1.1
             Message-ID: <709700825.1028122454671.JavaMail@ediXchange>
             Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; 
             boundary="----=_Part_57_648441049.1028122454671"
             Connection: Close
             Content-Length: 1980

      ------=_Part_57_648441049.1028122454671

     & Content-Type: multipart/report; Report-Type=disposition-notification; 
     &	boundary="----=_Part_56_1672293592.1028122454656"
     &
     &------=_Part_56_1672293592.1028122454656
     &Content-Type: text/plain
     &Content-Transfer-Encoding: 7bit
     &
     &MDN for -
     & Message ID: <200207310834482A70BF63@\"~~foo~~\">
     &  From: "\"  as2Name  \""
     &  To: "0123456780000"
     &  Received on: 2002-07-31 at 09:34:14 (EDT)
     & Status: processed
     &  Comment: This is not a guarantee that the message has been completely processed or 
          &understood by the receiving translator
     &
     &------=_Part_56_1672293592.1028122454656
     &   Content-Type: message/disposition-notification
     &   Content-Transfer-Encoding: 7bit
     &
     &   Reporting-UA: AS2 Server
     &   Original-Recipient: rfc822; "0123456780000"
     &   Final-Recipient: rfc822; "0123456780000"
     &   Original-Message-ID: <200207310834482A70BF63@\"~~foo~~\">
     &   Received-content-MIC: 7v7F++fQaNB1sVLFtMRp+dF+eG4=, sha1
     &   Disposition: automatic-action/MDN-sent-automatically; processed
     &
     &    ------=_Part_56_1672293592.1028122454656--

      ------=_Part_57_648441049.1028122454671
     Content-Type: application/pkcs7-signature; name=smime.p7s
     Content-Transfer-Encoding: base64
     Content-Disposition: attachment; filename=smime.p7s

     MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQ
     cp24hMJNbxDKHnlB9jTiQzLwSwo+/90Pc87x+Sc6EpFSUYWGAAAAAAAA
     ------=_Part_57_648441049.1028122454671--
      
Moberg, Brooks,  Drummond, Fischer                               	[page 29] 27]

HTTP Transport for Secure EDI                               May 2002

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

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

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

F. Security Considerations

    This entire document                               Jan 2003

  Notes:
                1.   The lines proceeded with "&" is concerned what the signature is calculated over.
                2.   For details on how to prepare the multipart/signed with secure transport  protocol =   
                      "application/pkcs7-signature" 
                      see the "S/MIME  Message Specification, PKCS Security Services for 
                      MIME".)
                3.   Note that the textual first body part of
    business the multipart/report can be used to business data and considers both privacy and
    authentication issues.

G.  Authors' Addresses

    Dale Moberg
    dale_moberg@cyclonecommerce.com
    Cyclone Commerce
    8388 E. Hartford Drive
    Scottsdale, AZ  85255 USA

    Dick Brooks
    dick.brooks@systrends.com
    Systrends, Inc
    7855 South River Parkway, Suite 111
    Tempe, Arizona  85284   USA

    Rik Drummond
    rik@drummondgroup.com
    Drummond Group
    5008 Bentwood Ct.
    Fort Worth, TX  76132 USA

    David Fischer
    david@drummondgroup.com
    Drummond Group
    4200 S. Hulen St.  Suite 600
    Fort Worth, TX  76109 USA 
                      include a more detailed explanation of the error conditions reported by the 
                      disposition headers. The first body part of the multipart/report when used in 
                      this way, allows a person to better diagnose a problem in detail.
                4.   As specified by RFC 1892 [9], returning the original or portions of the original
                      message in the third body part of the multipart/report is not required. This is an 
                     optional body part. However, it is RECOMMENDED that this body part be 
                     omitted or left blank.

  A.3    Signed, encrypted message requesting a signed, asynchronous receipt

  A.4    Asynchronous MDN for Message A.3 Above

  B.    IANA Registration Form

  A.1    IANA registration of the signed-receipt-protocol content
           disposition parameter

  Parameter-name: signed-receipt-protocol
  Syntax: See section 7.3 of this document
  Specification: See section 7.3 of this document

  A.2    IANA registration of the signed-receipt-micalg content
           disposition parameter

  Parameter-name: signed-receipt-micalg
  Syntax: See section 7.3 of this document
  Specification: See section 7.3 of this document

  A.3    IANA registration of the Received-content-MIC MDN extension
           field name

  Extension field name: Received-content-MIC
  Syntax: See section 7.4.3 of this document
  Specification: See section 7.4.3 of this document




Moberg, Brooks,  Drummond, Fischer                               	[page 30] 28]

HTTP Transport for Secure EDI                               Jan 2003
----