view Side-By-Side changes

draft-ietf-ediint-as2-06.txt		                            Dale Moberg
Expires March 2000
Internet draft				                    Dick Brooks
Expires: January 2001	                                    Rik Drummond

October 10 1999
                                                            July 13 2000


                     HTTP Transport for Secure EDI 

                     draft-ietf-ediint-as2-07.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 draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet Drafts
   as reference material or to cite them other than as "work in
   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>.

   Abstract

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

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

   This document is intended to be read in conjunction with AS1 and
   the referenced RFCs defining the MIME and cryptographic
Moberg, Brooks, Drummond 		  			[page 1]

HTTP Transport for Secure EDI					March 1, 2000 
   packaging that are used to obtain secure, authenticated, and
   acknowledged transport. 


   Feedback Instructions:

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

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

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

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

Table of Contents

1.  Introduction                                              
   1.1 Purpose and relation to previous work
   1.2 Overall operation 
2. Stages and Details of  HTTP EDI Transmission and Acknowledgment
    2.1   Requesting receipts in the POSTED request

Moberg, Brooks, Drummond 					[page1]

HTTP Transport for Secure EDI					October 1999
     2.1.1   Requesting MDN-based receipts
     2.1.2   Requesting Generalized receipts
     2.1.3   Summary of Remarks on Receipt request options
    2.2    Additional Commonly Used Headers
    2.3    Sending EDI in HTTP POST Requests  
    2.3  
    2.4    Using Transport Layer Security for Transmission
    2.4.
    2.5   Response Status Codes in Replies
    2.5
    2.6    Receipt Reply
    2.5.1
     2.6.1   MDN based Receipts and Signed MDN Receipts
2.5.2
     2.6.2   Generalized Receipts and Signed Generalized Receipts
2.5.3 Example of GISB Acknowledgement Receipt 
2.5.4 Example of GISB Error Notification Receipt
    2.6
    2.7   Additional Reply Content
    2.7
    2.8   Non-Repudiation of the POST Reply
    2.8
    2.9   Error Recovery
3. Referenced RFCs Other differences between  HTTP and their contribution SMTP based transport
    3.1  RFC 2068: Hypertext Transfer Protocol -- HTTP/1.1 [HTTP] Unused MIME headers and operations
     3.1.1  Content-Transfer-Encoding not used
     3.1.2  Epilogue must be empty
     3.1.3  Lengthy message bodies and Message/partial
    3.2  RFC 2246: Transport Layer Security [TLS]
   3.3  RFC 1847: MIME Security Multiparts [SECURITY]                
   3.4  RFC 1892: Multipart/report [REPORT]                        
   3.5  RFC 1767: EDI Content [MIMEEDI]                             
   3.6  RFC 2015: PGP/MIME [MIMEPGP]                                
   3.7  RFC 2045, 2046, and 2049: MIME [MIME]                     
   3.8  RFC 2298: Message Disposition Notification [MDN]
   3.9  RFC 2311: S/MIME Version 2 Specification [SMIMEV2]
   3.10 RFC 2633: S/MIME Version 3 Message Specification [SMIMEV3]
   3.11 RFC XXXX: MIME-based Secure EDI [AS1]
   3.12 RFC 2388: Multipart/form-data [FORMDATA]
4. Other differences to notice in HTTP and SMTP based transport
   4.1 Unused MIME headers and operations
    4.1.1  Content-Transfer-Encoding not used
    4.1.2  Epilogue must be empty 
    4.1.3  Lengthy message bodies and Message/partial
   4.2 Differences in Differences in MIME or other headers or parameters used
    4.2.1
     3.2.1  Content-Length needed.
    4.2.2 needed
     3.2.2  Final Recipient and Original Recipient
    4.2.3
     3.2.3  Message-Id and Original-Message-Id
    4.2.3
     3.2.3  Host header
   4.3
    3.3 New Options for HTTP transport

5.

A.  AS 2 MIME templates.
B.  Using AS2 Extensions in the GISB Protocol
C.  Samples of AS 2 Protocol Data Units
D.  Acknowledgments                                         

6.                                         
E.  References                                              

7.                                              
F.  Security Considerations
Moberg, Brooks, Drummond 		  			[page 2]

HTTP Transport for Secure EDI					March 1, 2000 
G.  Authors' Addresses                                      

A.  Example exchange.                                      


1.  Introduction

    1.1 Purpose and relation to previous work
         

Moberg, Brooks, Drummond 					[page2]

HTTP Transport for Secure EDI					October 1999
         

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

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

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

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

       i.

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

       ii.

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

       iii.

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

    The above describes stages describe the functionality which, when implemented, that would
    satisfy all security requirements. Other Applications are expected
    to be able to provide full functionality, though users may
    agree to exchange data using only a restricted subsets subset of 
    functionality (for
Moberg, Brooks, Drummond 		  			[page 3]

HTTP Transport for Secure EDI					March 1, 2000 
    functionality. For example, only signature and no businesses may agree to send signed receipt) 
    have also been characterized. data 
    using TLS, and only request a simple, unsigned receipt.
    Implementations are expected to be configurable so that they may
    support business community agreements that use subsets 
    of the full functionality. 

    In this document, the goal is to make use of HTTP instead of SMTP 

Moberg, Brooks, Drummond 					[page3]

HTTP Transport for Secure EDI					October 1999 
    as a transport protocol, and make the changes that are needed to 
    adapt to protocol packaging differences.

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

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

    One way to convey this information within the HTTP transport 
    context is to use either HTTP entity-headers or extension-headers 
    [11, section 7.1] that have the syntax of  SMTP headers. 
    Only the "From" header is overloaded by possibly different 
    usages in the SMTP and HTTP contexts. The From "From" header 
    normally contains  machine-usable email addresses  as defined 
    in [SMTPMSG]. The usage of the FROM "From" header in [HTTP] section 
    14.22 is to provide the email address of an administrative 
    contact for the HTTP client. The function of the "From" header 
    in the SMTP context of secure EDI transport has been to 
    supply a value used in constructing the MDN style receipt.
    But the MDN receipt has been found to be too restrictive for 
    some commercial EDI transport scenarios [GISB]. 
    So alternative receipt mechanisms will be provided
    that, among other things, will remove any conflicts arising 
    from trying to reuse the SMTP-MDN roles of  "From"  within the 
    context of HTTP reserved usage of "FROM".
    
    Also, it is currently difficult to make use of HTML [HTML]
    and simple scripting to send HTTP entity-headers 
    as part of the HTML FORM tag construct.
    For HTML-based POST situations [GISB], it is useful to specify
    ways to convey 'metadata' needed for the secure transmission 
    loop that do not make use of HTTP headers. One way to 
    specify this data is by using the MIME multipart/form-data 
    packaging specified in [FORMDATA].

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

    The MDN is a special kind of multipart/report [REPORT] MIME package [REPORT].
    For MDNS, specialization is retained to support these 
    generalizations, and multipart/signed packages are used to support     
    signatures over these generalized receipts.
     
    Finally, within achieved by assigning 
    the "report-type" parameter 
    in the content-type  header the special value, 
Moberg, Brooks, Drummond 		  			[page 4]

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

    Nothing else needs to be changed to construct reply acknowledgements
    that are not restricted by the semantics of MDNs. Specifically, 
    a signed reply will still be constructed by using a multipart/signed
    package to wrap up generalized receipts with their signatures.
     
    Finally, within the HTTP transport context, it is useful
    to make use of Transport Layer Security [TLS] to provide 
    privacy. Compression can be provided using HTTP content-codings
    [HTTP], sections 3.5, 14.3, 14.12]. (Content codings are not be be
    confused with the MIME concept of content transfer encodings.)


Moberg, Brooks, Drummond 					[page4]

HTTP Transport for Secure EDI					October 1999

    A variety of other minor differences (for example, 
    absence of content-transfer-encoding)
    are noted below and summarized in the concluding section.
  
   1.2 Overall operation
    
    A HTTP POST operation [HTTP] is used to send appropriately packaged
    EDI
    EDI, XML, or other business data. The Request-URI ([HTTP], 
    section 9.5) identifies a process to unpack and handle the
    message data and to generate a reply for the client that 
    contains a message disposition acknowledgement or a 
    multipart/report, signed or unsigned, and possibly other 
    turnaround transactions. This request/reply transactional 
    interchange provides secure, reliable, and authenticated 
    transport for EDI or other business  data using HTTP; 
    the security protocols and structures used also 
    support auditable records of these transmissions, 
    acknowledgements, and authentication. 
 
2. Stages and Details of  HTTP EDI Transmission and Acknowledgment

    An EDI

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

Moberg, Brooks, Drummond 		  			[page 5]

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

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

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

    In addition to the enveloping and MIME media type options defined in
    sections 4.2.x and 4.3.x of "MIME-based Secure EDI" [AS1], this
    specification enables the transport of payload objects containing 
    other MIME media types. A listing of registered MIME media types is available from
    the Internet Assigned Numbers Authority (IANA) at:
    http://www.isi.edu/in-notes/iana/assignments/media-types/media-types
    [MIME-TYPES].

Moberg, Brooks, Drummond 					[page5]

HTTP Transport for Secure EDI					October 1999 Implementors are to follow the 
    appropriate specifications identified under "References"
    in [MIME-TYPES], for the type of object being transmitted.
    For example, to send an XML object, the MIME media type 
    of text/xml application/xml is used in the Content-type MIME header 
    and the specifications  for enveloping the object are contained in RFC2376, (e.g.
    [XMLTYPES]; for example:

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

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

    Finally, several industry groups currently make use of "encapsulated"
    (or 
    "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 RFC 2311[SMIMEV2] [SMIMEV2] 
    or, in the case of PGP, according to the
    specifications contained in section 6.2 of "MIME Security 
    with Pretty Good Privacy (PGP)" [MIMEPGP] and 
    "OpenPGP Message Format" [RFC2440].

   2.1 Requesting Receipts

   2.1.1  Requesting MDN-based receipts

     For requesting MDN based receipts, the originator supplies
     metadata using the syntax of extension headers 
     (the [SMTPMSG] header syntax) that precede the message body.  
     The header "tags" are  
Moberg, Brooks, Drummond 		  			[page 6]

HTTP Transport for Secure EDI					March 1, 2000 
     The header "tags" are as follows:

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

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

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

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

     A Disposition-Notification-Options header is used to request 
     a signed message disposition notification. The parameters 
     used to select protocols for signed message disposition 

Moberg, Brooks, Drummond 					[page6]

HTTP Transport for Secure EDI					October 1999
     notification are found in [AS1].

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

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

     A Receipt-delivery-option is a header whose value is a URL 
     that indicates how the receipt is to be delivered. 
     While the
     This header is only used within AS2.
     The default mode of operation is synchronous
     within HTTP transport is to return transport, which means that the receipt
     (be it MDN, signed MDN, generalized report receipt,
     or signed report receipt) is returned in the reply body, body.
     By using the "receipt-delivery-option," an asynchronous reply is
     allowed through use of this name. mode
     can be requested. The "mailto", 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 of value types) for this information. 
     If this header header/metadata is found and contains the value "default" (case-insensitive), absent, then
     any the mode of operation
     is synchronous, which means that the receipt is to be returned
     in the reply to the current HTTP request. 

   2.1.2 Requesting Generalized Receipts

     In this section, the ways to request generalized receipts
     are specified. Generalized receipts are multipart/reports
Moberg, Brooks, Drummond 		  			[page 7]

HTTP Transport for Secure EDI					March 1, 2000 
     with a report-type other than "disposition-notification," and
     a second automated response with a content type other 
     than "message/disposition-notification". 

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

     When the name parameter within term "metadata" is used in the
     Content-Disposition header of following, 
     the multipart/form-data structure.
     Within HTML, these names correspond to term indicates that the name
     information may be supplied in one of
     two ways:

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

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

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

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

     The 18; for example,

         <FORM action="http://somesite.com/responder" method="post">
           <INPUT type="text" name="Receipt-Report-Type">
           <INPUT type="submit" value="Send"> <INPUT type="reset">
         </FORM>
                               
     To name contains an identifier identifying indicate the 
     intended recipient of a data exchange and may be
     D&B D-U-N-S number [DUNS]  or other agreed upon
     identifier system. Applications should allow users to
     configure these elements in various options for generalized receipts, the automated HTTP agents
     processing these values. For example,
     basic metadata that the body
     part MIME header line looks like POSTing client needs to convey to the following line:          

     Content-Disposition: form-data; name="To" 
     replying server are: "Receipt-Disposition-To", 
     "Receipt-report-type",  "Receipt-Security-Selection",
     and "Receipt-Delivery-Option". 

     The From name contains a textual presence of the metadata value identifying "Receipt-Disposition-To",
     using the sender of extension header syntax, indicates a data exchange, such as the request
     for a D&B D-U-N-S  number [DUNS]
     as in [GISB]. generalized receipt.

     Because "From" HTTP already has a specified use within [HTTP], role for the
     From name parameter is not to be considered equivalent to "From" header, the
     extension header. If an extension
     "Receipt-Disposition-To" header "From" is to be 
     used it should
     within HTTP, it should conform to avoid conflicts with [HTTP], when using
     the usage, syntax, and semantics of
     [HTTTP] section 14.22.  The extension header counterpart of the
     sender of syntax for metadata. (Within a data exchange is 
     multipart/form-data package, the extension header version of
     "Receipt-disposition-to".
    
     The Input-format name identifies the type of data contained in a data file.
   
     The Agent name parameter indicates the network or agent where the data 
     exchange originated.

     The Application name identifies the application used to process 

     the data next(after the URI-request process has finished with the stream). "From" value 
Moberg, Brooks, Drummond 					[page7] 		  			[page 8]

HTTP Transport for Secure EDI					October 1999


     The DateTime name provides the date and time the data was created 
     and uses the format specified in [SMTPMSG] as updated by
     RFC 1123.
  
     The RefNum is an integer value					March 1, 2000 
     can be used to uniquely identify the 
     communication exchange and is in a textual format. The RefNum is
     similar to the Message-ID and Content-Id headers of SMTP sending party without 
     any conflict with HTTP headers.)
     Notice that
     are used in constructing values in receipts based on  MDNs.

     The UserParam is a user defined parameter.

     GISB-Version is a protocol version number [GISB].

     Transaction-set is an optional data element identifying the
     EDI transaction.
            
     Input-data is the sending side's local file system name value for the file being sent
 
     Receipt-disposition-to name contains an identifer 
     identifying the party to receive positive notification of delivery.
     This this identifier may need not
     be an email address or a D&B D-U-N-S number [DUNS] URL. In this way, other
     systems of identification (such as in [GISB].
 
     Receipt-delivery-option is a URL containing a value indicating how DUNS number)
     may be used, if needed. Notice that the information
     needed for delivery of the receipt is to be delivered. While found in the
     receipt-delivery-option element described below;
     delivery information is not generally needed if the
     default mode of operation
     within HTTP transport is to return occurs. In that case, the
     receipt 
     (be it MDN, signed MDN, generalized report receipt,
     or signed report receipt) just goes back in the reply body, asynchronous reply is
     allowed through use of this name. The "MAILTO", "HTTP", and "HTTPS" will
     be the more common types of value for this information. 
     For to the current 
     HTTP and HTTPS schemes, the POST method is
     to be used.

     Receipt-report-type request.

     "Receipt-Report-Type" indicates the desired 
     value of the "report-type" parameter in the 
     multipart/report content type of a
     specific version of the generalized receipt. If multiple types
     are to
     This parameter must be indicated, use supplied when "Receipt-Disposition-To"
     is used to indicate a semi-colon as request for a separator. generalized receipt
     because this indicates what specific type of receipt
     is desired. An example for this value (discussed below) in appendix A)
     is "GISB-Acknowledgement-
     Receipt."

     Receipt-security-selection "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 and algorithm choices is
     that used in [AS1] and [MDN].

     Disposition-Notification-To [MDN]; for example,

	Receipt-Security-Selection: 
           signed-receipt-protocol=optional,pkcs7-signature;
           signed-receipt-micalg=optional,rsa-sha1
	    
     "Receipt-Delivery-Option" is a name that, if present, indicates
     that used to indicate the MDN style
     URL for asynchronous delivery of receipt the receipt.
     While the default mode of operation
     within HTTP transport is to be used. It may have values
     other than email addresses when return the receipt 
     (be it is found as a name parameter
     in a form-data body part, such as a D-U-N-S number. When this
     tag is used in HTTP extension headers MDN, signed MDN, generalized receipt,
     or signed generalized receipt) in SMTP headers it follows

Moberg, Brooks, Drummond 					[page8]

HTTP Transport for Secure EDI					October 1999 the MDN usage.

     Disposition-notification-options identifies characteristics reply body, 
     asynchronous reply is
     allowed through use of message 
     disposition notification in accordance with [AS1] this symbol.
     The URLs will typically use the "MAILTO", "HTTP",
     and [MDN].
   
     Application "HTTPS" schemes.  For the HTTP and HTTPS
     schemes, the POST method is to be used.


      2.1.3 Summary Remarks on Receipt request options
   
     Applications are encouraged to support handling all metadata values
     whether they make use of the name parameter syntax within a
     multipart/form-data or whether they use the message header syntax
     used in SMTP or HTTP headers [SMTPMSG]. If metadata items are
     repeated in extension headers and in form-data parts, but the
     values are not the same, the extension header values will be 
     selected for use. 
    
     The presence of the metadata value "Receipt-Disposition-To"
     using the extension header syntax indicates a request
     for a generalized receipt. This value also fulfills 
    
     Because the
     role of "From" when a value other than an email address
     needs to be used.  The value in Receipt-Disposition-To
     may have no significance for setting up the transport connection.
     Therefore, how the receipt is transported,
Moberg, Brooks, Drummond 		  			[page 9]

HTTP Transport for Secure EDI					March 1, 2000 
     the extension header " Receipt-delivery-option"
     should "Receipt-delivery-option"
     is to be used to provide that information as information.
     The receipt-delivery-option's value should be a URL or as
     indicating the special value "default." delivery transport destination for the
     receipt.

     The Receipt-delivery-option field is used when
     asynchronous delivery is desired. It should not
     be present if the intention is to deliver
     the reply synchronously; synchonous delivery of
     the reply is the default mode of delivery.
     
     For signed generalized receipts,
     an extension header of  "Receipt-security-selection" should
     be added to indicate the desired security protocol for the
     multipart/signed over the multipart/report.

      2.1.3 Summary of Receipt request options

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

       1. Receipt requests are made by conveying metadata
       values using a syntax of either the name parameter in a 
       multipart/form-data's Content-Disposition headers or by using a syntax
       of HTTP extension headers.
 
       2. Both MDN and generalized receipts can be requested in using either way,
     though
       syntax. However, using an extension header syntax and 
       requesting a MDN receipt means restricting the "From"
       values to email addresses. And either
  
       3. Either type of receipt comes in signed or unsigned versions. 

       4. Finally, receipts may be delivered synchronously (HTTP only) (delivered
       in the HTTP reply) or asynchronously by using 
       the  " Receipt-delivery-option" "Receipt-delivery-option" header.
  
    2.2 Sending EDI in HTTP Client Requests using POST  
    
    For sending EDI, the Additional Commonly Used Headers

    The following protocol set of header data elements are typically
    present: a request line ([HTTP], section 5.1), entity headers, a 
    CRLF pair also available for 
    use. Organizations wishing to mark use this specification for the end 
    secure and reliable transport of business documents are not required
    to utilize all of these headers and are free to use whatever subset
    they deem appropriate for their business needs. 

     TO:
     The To name contains an identifier identifying the entity headers, followed by
     intended recipient of a data exchange and may be
     D&B D-U-N-S number [DUNS]  or other agreed upon
     identifier system. Applications should allow users to
     configure these elements in the
    message-body. 
    The request automated HTTP agents
     processing these values. For example, the body
     part MIME header line will have looks like the form: "POST Request-URI HTTP/1.1",
    with spaces and followed by a CRLF. following line:

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

     FROM: 
     The Request-URI is typically From name contains a textual value identifying
     the sender of a data exchange, such as the a D&B D-U-N-S number 
Moberg, Brooks, Drummond 					[page9] 		  			[page 10]

HTTP Transport for Secure EDI					October 1999


    exchanged out of band,					March 1, 2000 
     [DUNS] as part of setting up in [GISB].   Because "From" has a bilateral 
    trading partner agreement. Applications should specified use within
     [HTTP], the From name parameter is not to be prepared considered equivalent 
     to deal with an initial reply containing a status indicating a need
    for authentication of the usual types extension header. If an extension header "From" is to be 
     used for authorizing access it should within HTTP, it should conform to the Request-URI ([HTTP], section 10.4.2 usage, syntax, 
     and elsewhere). 

    Automation semantics of this process [HTTTP] section 14.22.  The extension header 
     counterpart of the sender of a data exchange is not discussed the extension 
     header version of "Receipt-disposition-to".

     INPUT-FORMAT:
     The Input-format name identifies the type of data contained in this document
    but might involve obtaining a session URL from a page requesting
    authentication and possibly other information about proposed
    EDI standard versions and other trading conventions 
     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 to be used. process
     the data next(after the URI-request process has finished with the
     stream).
     
     DATETIME:
     The request line is followed by entity headers specifying content length 
    ([HTTP] section 14.14) DateTime name provides the date and content type [HTTP] section 14.18. time the data was created
     and uses the format specified in [SMTPMSG] as updated by
     RFC 1123.
    
     REFNUM:
     The Host request header ([HTTP] sections 9 RefNum is an integer value used to uniquely identify the
     communication exchange and 14.23) is also included. in a textual format. The entity or extension RefNum is
     similar to the Message-ID and Content-Id headers used for requesting a MDN
     (unsigned or signed) have previously been mentioned,
    as have those  ("To" "From" "Message-Id") of SMTP that
     are needed as used in constructing values
    for MDN fields or for other receipt requests.

    For generalized in receipts based on the multipart/report content type,
    the metadata can be the values found  in  extension headers, 
    but can also  be placed  in body parts of  MDNs.

     USERPARAM:
     The UserParam is a multipart/form-data
    using "name" parameters in the content-disposition header.

   Finally, user defined parameter.

     Version:
     Version is a protocol version number [GISB].

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

     INPUT-DATA:
     Input-data is found in any of the message patterns
   of  [AS1]  sections 4.2.1 to 4.2.4 or  4.3.1 to 4.3.4 sending side's local file system name
     for PGP/MIME  
   or S/MIME security. These payloads may arrive the file being sent. The payload is contained as the final body 
     part of a  
   multipart/form-data or may even be enclosed in some other multipart. 

    2.3 Using Transport Layer Security

    To use Transport Layer Security [TLS], the request-URI should this header element.

     PRIORITY:
     The "Priority" name is used to indicate the appropriate scheme value, HTTPS. Usually only a multipart/signed processing priority of
     each message body would be relative to other messages sent using TLS, as encrypted message bodies
    would be redundant. Encrypted message bodies are not prohibited, however.
    For asynchronous receipt delivery requests, use the 
    "Receipt-delivery-  option" header with by a given party. 
     The value "1" indicates highest priority and a URL value making 
    use of "5" 
     indicates the HTTPS scheme to obtain security privacy.
      
    2.4  Response Status Codes in Replies lowest priority.

     EXPIRATION:
     The status line for response "Expiration" name is used to errors in indicate the POST request line
    will be provided by date and time at 
     which a status line with the following protocol
    elements present ( [HTTP], section 6.1 ) : HTTP version (normally,
    HTTP/1.1), a status code, reason phrase, and CRLF. 

    The status codes return status concerning HTTP operations. For example,
    the status code 401, together with the WWW-Authenticate header, message is used to challenge no longer transportable. No message delivery
     should be attempted beyond the client to repeat date and time specified in 
     this value.  The date/time format must follow the request with an
    Authorization header.   Other explicit status codes are specifications 
Moberg, Brooks, Drummond 					[page10] 		  			[page 11]

HTTP Transport for Secure EDI					October 1999


    documented					March 1, 2000 
     contained in [HTTP], sections 6.1.1 and throughout section 10. 
    For errors 5 of RFC822.
 

    2.3 Sending EDI in HTTP Client Requests using POST  
    
    For sending EDI, the request-URI, 400 ("Bad Request"), 
    404 ("Not Found") and similar codes are appropriate status codes.
    These codes and their semantics following protocol elements are specified by [HTTP].
    A careful examination typically
    present: a request line ([HTTP], section 5.1), entity headers, a 
    CRLF pair to mark the end of these codes the entity headers, followed by the
    message-body. 

    The request line will have the form: "POST Request-URI HTTP/1.1",
    with spaces and their semantics
    should be made before implementing any retry functionality
    that followed by a CRLF. The Request-URI is described below; specifically, retries typically
    exchanged out of band, as part of setting up a bilateral 
    trading partner agreement. Applications should not be made if the error is not transient or if retries are
    explicitly discouraged (for real authentication failures, prepared
    to deal with an initial reply containing a status indicating a need
    for example.) 

    2.5  Receipt Reply

    The details authentication of the response usual types used for authorizing access
    to the POST command vary depending
    upon whether  a receipt has been requested Request-URI ([HTTP], section 10.4.2 and upon what kind elsewhere). 

    Automation of receipt
    has been requested.

    With no extended header requesting this process is not discussed in this document
    but might involve obtaining a receipt, session URL from a page requesting
    authentication and no errors
    accessing the request-URI specified processing, the status possibly other information about proposed
    EDI standard versions and other trading conventions to be used.

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

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

    For generalized receipts based on the Response to multipart/report content type,
    the POST request should metadata can be in the
    200 range. Status codes values found in the 200 range should extension headers, 
    but can also be used when
    an entity is returned (a signed receipt placed in body parts of a multipart/signed 
    content type or an unsigned receipt multipart/form-data
    using "name" parameters in a multipart/report).
     That is, even when the disposition of content-disposition header.

    Finally, the data was an error condition
    at payload is found in any of the authentication, decryption message patterns
    of [AS1] sections 4.2.1 to 4.2.4 or other higher level,  4.3.1 to 4.3.4 for PGP/MIME  
    or S/MIME security. These payloads may arrive as the
    HTTP status code should indicate success at "input-data"
    part of 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 multipart/form-data or may even be discarded by the
    client. Applications should avoid emitting unsolicited receipt replies
    because bandwidth or processing limitations might have led
    administators to suspend asking for acknowledgements.

    When a Disposition-Notification-To extension header is present enclosed in some 
    other multipart. 

    2.4 Using Transport Layer Security

    To use Transport Layer Security [TLS], the POST request entity headers, then entity headers for
    the MDN request-URI should be included. The content type for 
    indicate the MDN receipt
    ( multipart/report [REPORT] or appropriate scheme value, HTTPS. Usually only a 
    multipart/signed [SECURITY])
    should message body would be included in the Response entity headers. The
    
    The basic responsibilities of responding to requests sent using TLS, as encrypted
    message bodies would be redundant. Encrypted message bodies are discussed
    at length 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 in the HTTP reply
    context, will closely parallel a SMTP MDN. not 
    prohibited, however. For example,
    the disposition field is a required element in asynchronous receipt delivery requests, 
    use the machine 
    readable second part of a multipart/report for  "Receipt-delivery-option" header with a MDN. 
    The final-recipient-field([MDN] section 3.1) URL value should
    be derived from the entity headers making 
    use of the HTTPS scheme to obtain security privacy.
      
    2.5  Response Status Codes in Replies

    The status line for response to errors in the POST request
    If line
    will be provided by a status line with the "To" field is missing, for signed messages, following protocol
Moberg, Brooks, Drummond 					[page11] 		  			[page 12]

HTTP Transport for Secure EDI					October 1999


    the value for Original-recipient may be					March 1, 2000 
    elements present ( [HTTP], section 6.1 ) : HTTP version (normally,
    HTTP/1.1), a status code, reason phrase, and CRLF. 

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

    2.6  Receipt Reply

    The human readable part (the first 
    part details of the multipart/report) should include items 
    such as response to the subject, date POST command vary depending
    upon whether  a receipt has been requested and other information 
    when those fields are present in entity upon what kind 
    of receipt has been requested.

    With no extended header fields following requesting a receipt, and no errors
    accessing the
    POST request
     
    The HTTP reply should normally omit request-URI specified processing, the third optional part of status
    line in the 
    multipart/report (used Response to return the original message or its 
    headers POST request should be in the SMTP context).

  2.5.2  Generalized Receipts and Signed Receipts
  
    In addition, a generalized receipt using
    200 range. Status codes in the multipart/report [REPORT]
    and 200 range should also be used when
    an entity is returned (a signed receipt in a multipart/signed containing 
    content type or an unsigned receipt in a multipart/report as multipart/report).
     That is, even when the signed data
    is allowed. The basic structure disposition of the multipart/report is used so that data was an error condition
    at the first part is a "human-readable" message concerning authentication, decryption or other higher level, the received
    message. The second part should be for automated process utilization
    so
    HTTP status code should indicate success at least possess some common Internet syntax for expressing
    names and values, such as the [SMTPMSG] header syntax, XML, or 
    some MIME content type correlated with automated processing. HTTP level.
     
    The MDN
    requirements are removed for this second part but fields used in MDNs HTTP server-side application may
    be used here. The third part of the multipart report is 
    usually omitted in respond with an unsolicited 
    multipart/report as a message body that the HTTP context, client
    might not have solicited, but would include this may be discarded by the extension headers when used
    client. Applications should avoid emitting unsolicited receipt
    replies because bandwidth or processing limitations might 
    have led administators to provide
    diagnostic hints.  A multipart/signed over suspend asking for acknowledgements.

    When a multipart/report Disposition-Notification-To extension header is constructed
    precisely present
    in the same way as a multipart/signed over a POST request entity headers, then entity headers for
    the MDN [AS1].

    To indicate a desire should be included. The content type for a generalized the MDN receipt (which may
    ( multipart/report [REPORT] or multipart/signed [SECURITY])
    should be fulfilled
    by a MDN), included in the following metadata elements are Response entity headers. The
    
    The basic responsibilities of responding to be included requests are discussed
    in
    the original message [AS1] section 5, and in detail within section 5.2.1.

    2.6.1  MDN based Receipts and Signed MDN Receipts
  
    Message Disposition Notifications, when used in either the extended header format or the
    form-data format:

    The Receipt-Disposition-To metadata element contains an identifier
    identifying HTTP reply
    context, will closely parallel a SMTP MDN. For example,
    the party to receive positive notification of delivery.
    This disposition field is usually the same value contained in the "From" metadata element.

    The Receipt-report-type metadata a required element is used by in the sender to request a
    specific type machine 
    readable second part of general acknowledgement receipt. At present only one report
    type is defined, GISB-acknowledgement-receipt. a multipart/report for a MDN. 
    The content and format of
    this report type is defined in final-recipient-field([MDN] section 2.5.3 of this document.

    Receipt-delivery-option is either the key word (case-insensitive) 3.1) value
    "default" or a URL that indicates how and where
    the receipt is to should
    be delivered. While derived from the default mode entity headers of operation
    within HTTP transport is to return the receipt 
    (be it MDN, signed MDN, generalized report receipt,
    or signed report receipt) in the reply body, asynchronous reply is request
Moberg, Brooks, Drummond 					[page12] 		  			[page 13]

HTTP Transport for Secure EDI					October 1999


    allowed through use of this metadata value. 
    The  "MAILTO", "HTTP", and "HTTPS" 
    will be the more common schemes found in					March 1, 2000 
    If the URL  value. 

    Receipt-security-selection "To" field is a name that indicates missing, for signed messages,
    the
    protocol and algorithm choices value for a digital signature
    over Original-recipient may be the receipt. Signatures are always in multipart/signed
    packages. The format email 
    address field from the signer's X.509 attribute for protocol and algorithm choices is 
    email addresses, if that used in [AS1] and [MDN].

    One metadata element should, if at all possible, 
    be within the automated part.
    This is the Received-Content-MIC (also allowing X-Received-Content-MIC).
    This value is constructed and formatted as described in [AS1] and available.
    For a MDN, an application must report the syntax Message-ID 
    of the request. The human readable part (the first 
    part of the multipart/report) should be either RFC822:

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

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

    Any original metadata thought useful to include items 
    such as the subject, date and other information 
    when those fields are present in entity header fields 
    following the automated POST request
     
    The HTTP reply should normally omit the third optional part
    may be reflected back using "Original-X", as in

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

    Otherwise 
    of the automated acknowledgement semantics are left open  multipart/report (used to further semantic specification by specific electronic commerce 
    communities, such as return the original message 
    or its headers in [GISB]. Each specialization of the SMTP context).

  2.6.2  Generalized Receipts and Signed Receipts
  
    For generalized receipts, the multipart/report [REPORT]
    or a multipart/signed containing a multipart/report 
    as the signed data is the basic MIME packaging. Each
    generalized receipt should make use of needs a specific identifying value to be placed in for the parameter multipart/report
    parameter, "report-type," 
         
            Content-Type: multipart/report; 
                         report-type="organizationalid"; 
                         boundary="=-Trfds88fd99"

    2.5.3 Example a selection of GISB Acknowledgement Receipt

    An "Acknowledgement Receipt" contains a content-type
    for its second body part, when signed, a hash value over
    a defined portion of the original message and, 
    when asynchronously delivered, information indicating allowing the
    success/failure
    identification of a file transfer. Acknowledgement Receipts are
    communicated on the same session connection as original POSTed message.
    
    The basic structure of the HTTP POST, by multipart/report is used so that
    the
    receiving party's system, immediately after receiving all of first part is a "human-readable" message concerning the MIME parts
    contained received
    message. The second part should be for automated process utilization.
    It should at least possess some common Internet syntax for 
    expressing names and values, such as the [SMTPMSG] header syntax, 
    XML, or  some MIME content type correlated with automated 
    processing.

    The MDN requirements, therefore, are removed for this second part, 
    but information used in an HTTP POST request. These receipts contain MDNs may be used here. 
    The third part of the following data
    elements:
    time-c multipart report is 
    usually omitted in the time of transfer completion at HTTP context, but could include 
    the server. The format extension headers, or even the entire payload,
    to provide diagnostic information.

    A multipart/signed over a  multipart/report is yyyymmddhhmmss.

    request-status constructed
    precisely in the same way as a text status indicator by multipart/signed over a MDN [AS1].

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

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

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

Moberg, Brooks, Drummond 					[page13] 		  			[page 14]

HTTP Transport for Secure EDI					October 1999


for
                a successful transfer is  "ok". If an error is identified,
                the server should supply a descriptive indication of the
                error detected following the standards for error codes and
                messages presented					March 1, 2000 
    Any original metadata thought useful to include in APPENDIX A.

    server-id       hostname.domainname uniquely identifying the server
                associated with automated 
    part may be reflected back using "Original-X", as in

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

    Otherwise the program that received and processed automated acknowledgement semantics are left open 
    to further semantic specification by specific electronic commerce
    communities, such as in [GISB]. Each specialization of the
                file.

    trans-id
    generalized receipt should make use of a number (integer) up specific identifying
    value to 15 characters be placed in length uniquely
                identifying the received transaction file at the server. The
                trans-id will uniquely identify parameter "report-type," 
         
            Content-Type: multipart/report; 
                         report-type="identifying-value"; 
                         boundary="=-Trfds88fd99"
 
    Implementations should attempt to be configurable to allow 
    for new report-type values to be added;  communities can then agree 
    to the file only at specific extensions they need to support application
    level routing, transaction identification, timestamps, and
    other specialized information about the
                receiving server. A client may receive non-unique trans-ids
                across multiple servers.

    The above data elements must be formatted into Name/Value pairs with "="
    separating Names from Values (e.g. server-id=www.mydomain.com) they have exchanged.

    2.7  Additional Reply Content
    
    In general, both HTTP servers and "*"
    separating each Name/Value pair (e.g. time-c=19990804090000*request-
    status=ok*server-id=www.me.com*trans-id=12345*).  The receipt can HTTP clients should be
    identified as either text/plain or text/html. If text/html is used prepared
    to process the set basic EDIINT data formats when they are embedded
    within MIME multiparts. This is true for HTTP request payloads
    as well as HTTP reply payloads.

    So, as previosuly mentioned, for HTML-based POSTS,
    any of all name/value pairs must be encapsulated the EDIINT templates described in <html> </html> tags.

    The report-type parameter value [AS1], 
    sections 4.2.1 to 4.2.4 or
    4.3.1 to 4.3.4 for the Acknowledgement Receipt is
    "GISB-Acknowledgement-Receipt," and PGP/MIME or S/MIME security,
    may be found as parts of a case insensitive match is
    used multipart/form-data.
    [Consult Appendix A for testing the value.

    See Appendix A.4 and A.5 templates adapated for formatted examples.


    2.5.4 Example of GISB Error Notification

    Though a file this document.]

    In addition, the response to the POST operation may be received correctly initially, and a positive
    "Acknowledgement Recipt" has been delivered, errors can occur during a later
    stage of processing, such as decryption. When include other 
    MIME wrapped content besides an MDN Receipt, Signed MDN, 
    Generalized Receipt or Signed Generalized Receipt. If a file passes receipt was
    requested within the decryption
    step no notifying communication POST data, and additional content is sent back to be
    returned, the original sender. However,
    if the decryption step fails, an Error Notification receipt multipart/report must be sent to the
    original sender of the file. In general, combined with the standard format
    other data using some MIME multipart pattern.     
    Real-time EDI processing systems may use MIME
    multipart content-types to include a response EDI message, 
    for Error
    Notification applies example, a Quote in response to a Request-For-Quote transaction.

    Also, if requested, the posting of sender may request an error message after the sender's
    session has been disconnected. asynchronous mode
    for return of receipt. This Error Notification has mode is indicated by including the potential 
    metadata for Receipt-delivery-option as explained above.


    2.8  Non-Repudiation of
    occurring only after the original HTTP Response is returned with an "ok" or
    a warning.


    Error Notifications are sent using HTTP POST, POST Reply
    
    If the same method used reply to send EDI
    files. The sender of a Error Notification must adhere to the specifications
    in section 2 of this document, using POST operation needs a value of "error" MDN receipt for non-
    repudiation (for example, the input-format
    data element. Error Notifications are sent reply includes content other than
    a receipt), the top-level headers in cleartext (non-encrypted)
    within the input-data element and contain response include
    the following same headers required for POST data elements: described above:
    Disposition-Notification-To, Message-ID, From, and To. Other
    headers described above used in a MDN should be included,
Moberg, Brooks, Drummond 					[page14] 		  			[page 15]

HTTP Transport for Secure EDI					October 1999


    orig-from               The "from" value from the original transmission

    orig-to                 The "to" value from the original transmission.

    orig-input-format       The "input-format" value from the original
                        transmission.

    resp-time-c             The "time-c" value from the original Acknowledgement
                        Receipt.

    resp-server-id          The "server-id" value from the original Acknowledgement
                        Receipt

    resp-trans-id           The "trans-id" value from the original Acknowledgement
                        Receipt.

    request-status          The new status of the transaction based on the
                        occurance of an error during a later stage of
                        processing; see APPENDIX A, "Standard Error Codes
                        and Messages"					March 1, 2000 
    for a listing example, Date and Subject.
    
    The MDN receipt of possible values.

    comments 		Any comments the original receiving server wishes to
                        include.

    The above response data elements must be formatted into Name/Value pairs with "="
    separating Names from Values (e.g. server-id=www.mydomain.com) and "*"
    separating each Name/Value pair (e.g. time-c=19990804090000*request-status=
    ok*server-id=www.me.com*trans-id=12345*).  The data elements must be
    formatted as text/plain. 


    The report-type parameter value for the Error Notification is
    "GISB-Error-Notification," and returned using
    a case insensitive match is
    used for testing the value. " The extension header "Receipt-delivery-option"
    (or its form data correlate) may be subsequent POST operation. A POST operation used only
    to indicate transmit an MDN should not include the desired 
    destination for any GISB-Error-Notifications.

    See Appendix A.6 for a formatted example.


    2.6  Additional Reply Content
    
    In general, both HTTP servers Disposition-
    Notification-To receipt request, and HTTP clients should only a 200 ("OK") response
    would be prepared expected.
    
    An MDN in response to process the basic EDIINT data formats when they are embedded

    within MIME multiparts. This is true for HTTP request payloads
    as well as HTTP a reply payloads.

    So, as previosuly mentioned, for HTML-based POSTS,

Moberg, Brooks, Drummond 					[page15]

HTTP Transport for Secure may be combined with a
    subsequent EDI					October 1999


    any of the EDIINT templates described message sent with a POST operation, for example
    a Purchase-Order transaction in [AS1], sections 4.2.1 response to 4.2.4 or
    4.3.1 a Quote. The MIME
    multipart/mixed form is used to 4.3.4 for PGP/MIME or S/MIME security, may be found combine the MDN with the other
    data, the same as 
    parts of for a multipart/form-data.

    In addition, POST reply.


   2.9  Error Recovery

   If the response HTTP client fails to read the HTTP server
   response data, the POST operation may include other MIME
    wrapped with identical content besides an MDN Receipt, Signed MDN, Generalized Report
    Receipt or Signed Report Receipt. If a receipt was
    requested within the POST data, (including
   Message-ID, RefNum, and additional content is to other header elements) should be
    returned, the receipt multipart/report must be combined with the
    other data using some MIME multipart pattern.     
    Real-time EDI processing systems may use MIME
    multipart content-types to include a response EDI message, 
    for example, a Quote in response to a Request-For-Quote transaction.

    Also, if requested, the sender may request an asynchronous mode
    for return of receipt. This mode is indicated by including the metadata
    for Receipt-delivery-option as explained above and choosing a
    URL rather than the value "default".


    2.7  Non-Repudiation of the POST Reply
    
    If the reply to a POST operation needs a MDN receipt for non-
    repudiation (for example, the reply includes content other than
    a receipt), the top-level headers in the response include
    the same headers required for POST data described above:
    Disposition-Notification-To, Message-ID, From, and To. Other
    headers described above used in a MDN should be included,
    for example, Date and Subject.
    
    The MDN receipt of the response data is returned using
    a subsequent POST operation. A POST operation used only
    to transmit an MDN should not include the Disposition-
    Notification-To receipt request, and only a 200 ("OK") response
    would be expected.
    
    An MDN in response to a reply may be combined with a
    subsequent EDI message sent with a POST operation, for example
    a Purchase-Order transaction in response to a Quote. The MIME
    multipart/mixed form is used to combine the MDN with the other
    data, the same as for a POST reply.


   2.8  Error Recovery

   If the HTTP client fails to read the HTTP server
   response data, the POST operation with identical content (including

   Message-ID) should be repeated, if repeated, 
   if the error condition is transient.

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

Moberg, Brooks, Drummond 					[page16]

HTTP Transport for Secure EDI					October 1999

   Details of the retry process -- including time intervals to pause, number of
   retries to attempt, timeouts for retrying -- are implementation dependent.
  
   Servers should be prepared to receive a POST with a repeated Message-ID.
   The MIME reply body previously sent should be resent, including the MDN
   and other MIME parts.  


3. Referenced RFCs and their contribution

     3.1 RFC 2068 [HTTP] : The HyperText Transfer Protocol, HTTP,
     provides an application level protocol for distributed hypermedia
     information systems. This standard specifies the protocol HTTP/1.1.
    
     3.2 RFC 2246 [TLS] : Transport Layer Security 
     Security specifies a protocol similar  Other differences to SSL version 3 that provides
     communications privacy over the Internet.  Applications can
     communicate without eavesdropping, tampering, or message forgery.

     3.3 RFC 1847 [SECURITY] : MIME Security Multiparts 

     This document defines security multiparts for MIME:
     multipart/encrypted notice in HTTP and multipart/signed.

     3.4 RFC 1892 [REPORT] : Multipart/report 

     This RFC defines the use of the multipart/report content type
     that the MDN RFC 2298 [MDN] presupposes.

     3.5 RFC 1767 [MIMEEDI] :  EDI Content 

     This RFC defines SMTP based transport

    For HTTP version 1.1, TCP persistent connections are the use of content type "application" for ANSI
     X12 (application/EDI-X12), EDIFACT (application/EDIFACT) default, 
    ( [HTTP] sections 8.1.2, 8.2, and
     mutually defined EDI (application/EDI-Consent).

     3.6 RFC 2015 [MIMEPGP] : PGP/MIME 

     This RFC defines the use 19.7.1).

    A number of content types
     "multipart/encrypted", "multipart/signed", "application/pgp
     encrypted" and "application/pgp-signature" for defining other differences exist because HTTP does not
    conform to MIME PGP
     content.

     3.7 RFC 2045, 2046, and 2049 [MIME] : MIME 

     These as used in SMTP transport. Relevant
    differences are the basic MIME standards, upon which all summarized below.

  3.1 Unused MIME related RFCs
     build, including this one.  Key contributions include definition of
     "content type", "sub-type" headers and "multipart", as well as encoding

     guidelines,  which establishes 7-bit US-ASCII as the canonical
     character set to be operations

   3.1.1  Content-Transfer-Encoding not used in Internet messaging.

Moberg, Brooks, Drummond 					[page17] HTTP Transport for Secure EDI					October 1999


     3.8 RFC 2298 [MDN] : Message Disposition Notification 

     This RFC defines how a message disposition notification
     (MDN) is requested, transport

    HTTP can handle binary data and so there is no need to use
    the format and syntax Content transfer encodings of the MDN. 
     The MDN is the basis upon which receipts and signed receipts
     are defined in this and in [AS1].
        
     3.9 RFC 2311 [SMIMEV2] : S/MIME Version 2 Message Specification 
     This specification describes how MIME shall carry PKCS7 1.5
     envelopes.
    
     3.10 RFC 2633 [SMIMEV3] : This specification updates formats
     and procedures for combining cryptographic encryption and 
     signature services with MIME processing. See also [CMS].

     3.11 RFC XXXX X [AS1] : MIME-based Secure EDI 
     This applicability statement describes security patterns,
     MIME content types, and acknowledgement policies and
     mechanisms for EDI or business data transport.
    
     3.12  RFC 2388 [FORMDATA] : This specifies a standard Internet Media Type
     useful for returning a set of values as the result of a user filling out a form.


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

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

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

  4.1 Unused MIME headers and operations

   4.1.1  Content-Transfer-Encoding not used in HTTP transport

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

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

   4.1.3

   3.1.3  Lengthy message bodies
Moberg, Brooks, Drummond 					[page18] 		  			[page 16]

HTTP Transport for Secure EDI					October 1999					March 1, 2000 

    In [AS1], section 5.4.1, options for large file processing are
    discussed for SMTP transport. For HTTP, large files should
    be handled correctly by the TCP layer. However, [HTTP] sections
    3.5 and 3.6 discuss some options for compressing or chunking
    entities to be transferred. Section 8.1.2.2 discusses a
    pipelining option that is useful for segmenting large
    amounts of data. 

  4.2 

  3.2 Differences in MIME or other headers or parameters used

   4.2.1

   3.2.1  Content-Length

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

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

   4.2.3

   3.2.3 Message-Id and Original-Message-Id

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

   4.2.4

   3.2.4 Host header

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

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

6. References

[MIME]  N. Borenstein,  N.Freed, "Multipurpose Internet Mail Extensions (MIME)
     Part One: Format



Appendices


A.  AS 2 MIME templates

Structure 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. an AS2 MIME message - PGP/MIME

No encryption, no signature (analog of 4.2.1)

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

No encryption, signature (analog of 4.2.2)

   -RFC2068/2045
     -RFC1847 (multipart/signed)
       -RFC1767/RFC2376 (application/EDIxxxx or application/xml)
       -RFC2015 (application/pgp-signature)
Moberg, Brooks, Drummond 					[page19] 		  			[page 17]

HTTP Transport for Secure EDI					October 1999


     N. Borenstein, N.Freed, "Multipurpose Internet Mail					March 1, 2000 

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 application/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 application/xml)(encrypted)
           -RFC2015 (application/pgp-signature)(encrypted)

Structure of an AS2 MIME message - S/MIME

No encryption, no signature (analog of 4.3.1)

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

No encryption, signature (analog of 4.3.2)

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

Encryption, no signature (analog of 4.3.3)

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

Encryption, signature (analog of 4.3.4)

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


B.AS2 Extensions (MIME)
     Part Five: Conformance Criteria for the GISB Protocol and Examples", RFC 2049 , December 02,
     1996.

[MIMEEDI]  D. Crocker, "MIME Encapsulation Report-type


GISB AS2 Profile

The United States based Gas Industry Standards Board (GISB) is a consortium
of companies and individuals that operate in the Gas Industry. The
membership is divided into 5 sectors, Producers, Pipelines, Services, End
Moberg, Brooks, Drummond 		  			[page 18]

HTTP Transport for Secure EDI Objects",  RFC 1767,					March
     2, 1995.

[SMTPMSG]  D. Crocker, "Standard for 1, 2000 
Users, Local Distribution Companies, representing the Format various type of ARPA Internet Text
     Messages", STD 11,  RFC 822,  August 13, 1982.
    (Also RFC 1123 provides important updates
organizations within the industry. In 1996 GISB initiated a program to move
from the expensive Value Added Networks they were using, to the Internet. By
October of 1996 GISB had developed and tested a protocol, called GISB
Electronic Delivery Mechanism (EDM), which uses HTTP and is based on date RFC
1867 (Form-based File Upload in HTML). By April 1997 this protocol was being
used by Enron and time formats
    as well others to send/receive live, mission critical business
transactions over the Internet.  Additional companies followed suit and a
large percentage of todays business transactions in the Gas Industry are
transmitted over the Internet using the GISB EDM protocol. In 1998 the
Automobile Industry Action Group (AIAG) adopted the GISB EDM protocol and in
1999 the local electric companies serving the state of Pennsylvania declared
the GISB protocol as email addresses.)

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

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

[SECURITY]  J. Galvin, S. Murphy, S. Crocker, N. Freed,  "Security Multiparts their standard for MIME: Multipart/Signed transmitting business transactions
via the Internet.

In May of 1999 the AIAG, GISB and Multipart/Encrypted", RFC 1847, Oct.    
     3, 1995

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

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

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

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

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

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

[AS1] T. Harding, R. Drummond, "MIME-based Secure EDI", Internet draft: 
     draft-ietf-ediint-as1-10.txt.

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

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

[HTML]  D. Raggett, A. Le Hors, I. Jacobs. "HTML 4.0
      Specification", World Wide Web Consortium Technical Report

Moberg, Brooks, Drummond 					[page20]

HTTP Transport for Secure EDI					October 1999


      "REC-html40", December, 1997. <http://www.w3.org/TR/REC-html40/>

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

[MIME-TYPES] "Media Types," http://www.isi.edu/in-notes/iana/assignments/media-types/media-types.
    
[EDIINT] T. Harding, R. Drummond , "Requirements for Interoperable Internet EDI",
     Internet draft: draft-ietf-ediint-req06.txt.

7.  Authors' Addresses


Dale Moberg
dale_moberg@stercomm.com
Sterling Commerce
4600 Lakehurst Ct.
Dublin, OH 43016 USA

Dick Brooks
Group 8760
110 12th Street North
Suite F103
Birmingham, Alabama 35203
Tel: 205-250-8053
E-mail: dick@8760.com

Rik Drummond
drummond@onramp.net
The Drummond Group
5008 Bentwood Ct.
Ft. Worth, TX 76132 USA

Chuck Shih


Appendix A. Example Exchanges.

   NOTE:  Examples are provided as illustration only.
   If the example conflicts with the previous text, IETF EDIINT workgroup
initiated an effort to converge their independent specifications, the example result
of which is wrong.

Example A.1 

Sending a multipart signed for trading partner 1 back this specification. In order to 
trading partner 2. "#" indicates bring the GISB EDM into
compliance with this specification GISB initiated a comment line.

POST https://tp2server.company2.com/cgi-bin/tp1drawer.pl HTTP/1.1
Host: tp2server.company2.com

Moberg, Brooks, Drummond 					[page21]

HTTP Transport for Secure EDI					October 1999


From: tp1@company1.com
To: tp2@company2.com
Date: Tue, 06 Nov 2001 12:53:01 UT
Subject: Purchase orders for 6 November 2001
Message-Id: <20011106@company1.com>
Disposition-Notification-To: tp1@company1.com
# continuation lines not used in actual HTTP protocol data unit
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
Content-Length: 2605

ISA ...
# EDI transaction data
IEA  ...
--20011106RsXgYlvCNW
Content-Type: application/pkcs7-signature
Content-Length: 804

# omitted binary formal change to the EDM
specification. The following information, referred to as the "GISB AS2
Profile", reflects the planned utilization of this specification by the GISB
membership.

The GISB membership will utilize PGP to meet all P.A.I.N. requirements. All
data
--20011106RsXgYlvCNW--

Example A.2
Returning a exchanges will utilize the multipart/form-data enveloping method and
two generalized receipts, GISB-Acknowledgement-Receipt and
GISB-Error-Notification. All original business transactions must be
digitally signed MDN (using encapsulated signatures) and encrypted using RSA
algorithms. Upon successful transfer of an original business transaction the previously established TLS security) 
from trading partner 2 back
receiver is required to trading partner 1.
"#" indicates send a comment line.

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

--boundary1
Content-type: multipart/report
Content-length: 1133

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

Message <20011106@company1.com> was authenticated;
EDI GISB-Acknowledgement-Receipt indicating that
the transfer has completed successfully. If, upon further processing was initiated. 
--boundary2
Content-type: message/disposition-notification
Content-length: 213

Reporting-UA: Company2UA

Moberg, Brooks, Drummond 					[page22]

HTTP Transport for Secure EDI					October 1999


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

--boundary2--

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

# Signature data omitted
--boundary1--


Example A.3  PGP ENCRYPTED/SIGNED EDI Object of the
business document and error is encountered a GISB-Error-Notification is sent
to the original sender using HTTP POST (ref [AS1],
section 4.2.4 enveloping using multipart/form-data).
The entire payload contained within the multipart/encrypted part multipart/form-data enveloping.

It is
treated as one opaque object.


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

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

GISB has decided to use the following core headers:

FROM:     
Contains the DUNS number of the sending party

TO:
Contains the DUNS number of the intended recipient

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

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

Moberg, Brooks, Drummond 		  			[page 19]

HTTP Transport for Secure EDI					March 1, 2000 
Version:
The GISB version number (currently 1.3)

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

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


Optional headers also available:

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

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



Example of a GISB data exchange:

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

POST c:\execute HTTP/1.0
Referer: http://www.get.a.life/upl.htm
Connection: Keep-Alive
User-Agent: Group 8760 WinBB  (Win98; I) brow v0.1 XYZ Corp.
Host: localhost:2600 localhost
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Content-type: multipart/form-data;
boundary=---------------------------222875935764
boundary=---------------------------87453838942833
Content-Length: 1373

-----------------------------222875935764 5379

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

FROM1234
-----------------------------222875935764

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

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

x12
-----------------------------222875935764
Content-Disposition: form-data; name="Receipt-report-type"

GISB-acknowledgement-receipt
-----------------------------222875935764

234567890
-----------------------------87453838942833
Moberg, Brooks, Drummond 					[page23] 		  			[page 20]

HTTP Transport for Secure EDI					October 1999					March 1, 2000 
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="D:\GISBLite\as2testtextfile.aes" filename=	
c:\temp\smallnom.bin	
Content-Type: multipart/encrypted; boundary=8760;
protocol="application/pgp-encrypted"

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

Version: 1

--8760
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
cp2IWClxKOGUbxpVNOnNTqWHS/GntegvDE/7/ewCxDxsnmQS95pOl141QZ1RQbeN
aqx2Dq/ra9g65HNchOCzjul5Vi8HHf6Yhg2WnROe+npByyCue6rihqgNVOJwj0cV
zpb4JE+gMDf3q4ISUb1Fv7/+SSFHDdnhdC5YTpqf1Bc3B07hiLmtTXqNit31EbX9
UVElObzSa9ZhxbC6/eSl7Nuf5ZTDsh9nrk+QQJ6FeC9W4cqXLj7IZySaRO8Vtff+
4ktqeuhYusT4kSpnk027aw4O/5jomUkfb22CAe4=
=Oiuo
-----END PGP MESSAGE-----
--8760
-----------------------------222875935764--

Example A.4  An Acknowledgement Receipt Indicating Errors.
--8760--
-----------------------------87453838942833	




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

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

--GISB7866
Content-type: text/html

<HTML><HEAD><TITLE>Acknowledgement Receipt Error</TITLE></HEAD> <BODY><P>
time-c=19960619082855*
request-status=EEDM106: Invalid To Common Code Identifier*
server-id=coolhost*
trans-id=234423897*
</P> </BODY></HTML>
--GISB7866
Content-type: text/plain

time-c=19960619082855*
request-status=EEDM106: Invalid To Common Code Identifier*
boundary="GISB7867"

--GISB7867
Moberg, Brooks, Drummond 					[page24] 		  			[page 21]

HTTP Transport for Secure EDI					October 1999


server-id=coolhost*
trans-id=234423897*
--GISB7866--

Example A.5  An Acknowledgement Receipt Indicating Success

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

--GISB7867					March 1, 2000 
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

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


Example A.6


C. Samples of AS 2 Protocol Data Units

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

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



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

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

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

123456789
-----------------------------87453838942833 3056

--20011106RsXgYlvCNW
Content-Type: application/edi-x12
Content-Disposition: form-data; name="input-format" Attachment; filename=rfc1767.dat
Content-Length: 2605

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

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

C.2 This second example illustrates returning a signed MDN 
    that corresponds to the request for a MDN found in C.1.
Moberg, Brooks, Drummond 					[page25]

HTTP Transport for Secure EDI					October 1999


error
-----------------------------87453838942833
Content-Disposition: form-data; name="input-data"; filename=c:\temp\error.not
Content-Type: multipart/report;  report-type="GISB-Error-Notification"; 
 boundary="GISB7868"

--GISB7868
Content-type: text/html

<HTML><HEAD><TITLE>Error Notification</TITLE></HEAD> <BODY><P>
orig-from=123456789*
orig-to=234567890*
orig-input-format=X12*
resp-time-c=19960619102855*
resp-server-id=coolhost*
resp-trans-id=234423897*
request-status=EEDM601: Public Key Invalid*
comments=Please contact 1-800-555-1212 for correct public key*
</P> </BODY></HTML>

--GISB7868
Content-Type: text/plain

orig-from=123456789*
orig-to=234567890*
orig-input-format=X12*
resp-time-c=19960619102855*
resp-server-id=coolhost*
resp-trans-id=234423897*
request-status=EEDM601: Public Key Invalid*
comments=Please contact 1-800-555-1212 for correct public key*
--GISB7868--
-----------------------------87453838942833--


Error Notification Standard Error Codes and Messages

Codes beginning with EEDM### indicate standard error format with ###
representing a numeric value.

Codes beginning with WEDM### standard warning format with ### representing
a numeric value.

The string 		  			[page 22]

HTTP Transport for Secure EDI					March 1, 2000 


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

--boundary1
Content-type: multipart/report
Content-length: 1133

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

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

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

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

--boundary2--

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

[ Signature data omitted]
--boundary1--


   
D. Acknowledgments

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

E. References

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

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

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

Moberg, Brooks, Drummond 		  			[page 23]

HTTP Transport for Secure EDI					March 1, 2000 
[MIMEEDI]  D. Crocker, "MIME Encapsulation of EDI Objects",  RFC 1767,  March
     2, 1995.

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

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

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

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

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

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

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

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

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

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

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

[AS1] T. Harding, R. Drummond, "MIME-based Secure EDI", Internet draft: 
     draft-ietf-ediint-as1-10.txt.

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

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

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

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

[MIME-TYPES] "Media Types," http://www.isi.edu/in-notes/iana/assignments/media-types/media-types.
    
[EDIINT] T. Harding, R. Drummond , "Requirements for the error or warning should appear in the following format:

Validation Code: Description; supplemental message to be defined by the
issuing site up to 80 characters.

The supplemental message is senders option, only the Validation Code and
Description are required. Interoperable Internet EDI",
     Internet draft: draft-ietf-ediint-req.txt.
Moberg, Brooks, Drummond 					[page26] 		  			[page 24]

HTTP Transport for Secure EDI					October 1999


Example:

EEDM100:Missing from Common from required Code Identifier

Listing					March 1, 2000 

F. Security Considerations

   This entire document is concerned with secure transport of Standard Error Codes and Messages

CODE			MESSAGE

EEDM100 		Missing from Common from required Code Identifier
EEDM101 		Missing to Common Code to required Identifier
EEDM102 		Missing input format input-format required
EEDM103                       Missing data file input-data required
EEDM104 		Missing transaction set transaction-set mutually agreed
EEDM105 		Invalid from Common from required Code Identifier
EEDM106 		Invalid to Common Code to required Identifier
EEDM107 		Invalid input format input-format required
EEDM108 		Invalid transaction set transaction-set mutually agreed
EEDM109 		No parameters supplied parameter required string
EEDM601 		Public key invalid file itself required - security
EEDM602 		File not encrypted file itself required - security
EEDM603 		Encrypted file truncated file itself required - security
EEDM604 		Encrypted file not signed or signature not matched
EEDM699 		Decryption Error required for general decryption errors
                                       not specifically identified above
EEDM999                      System error (required for general system errors business to
                                      indicate severe errors in processing at
                                      the receiving site)
WEDM100 	            Transaction set sent not transaction-set mutually
                                      agreed mutually agreed 
   business data, and considers both privacy and authentication issues.

G.  Authors' Addresses

Dale Moberg
dale_moberg@stercomm.com
Sterling Commerce
4600 Lakehurst Ct.
Dublin, OH 43016 USA

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

Rik Drummond
drummond@onramp.net
The Drummond Group
5008 Bentwood Ct.
Ft. Worth, TX 76132 USA

----