AS3 Discusion - Appendices

["Terry Harding" <tharding@xxxxxxxxxxxxxxxxxxx>]

Open for discussion

Appendices

A.   Message Examples

NOTE: All examples are provided as an illustration only, and are not   
      considered part of the protocol specification. If an example 
      conflicts with the protocol definitions specified above or with
      that of a referenced RFC, the example is wrong.

A.1  Signed message requesting a signed receipt

      Date: Wed, 31 Jul 2002 13:34:50 GMT
      AS3-Version: 1.0
      AS3-From:  cyclone
      AS3-To: "trading partner"

Harding, Scott                                                 [Page 27]


INTERNET DRAFT       FTP Transport Data for EDIINT           April 2005

      Message-Id: <200207310834482A70BF63@xxxxxxxx>
      Disposition-Notification-To: ftp://host:port/mdnbox
      Disposition-Notification-Options: signed-receipt- 
        protocol=optional,pkcs7-signature; 
        signed-receipt-micalg=optional,sha1
      Content-Type: multipart/signed; boundary="as3BouNdary1as3";
         protocol="application/pkcs7-signature"; micalg=sha1
      Content-Length: 3075

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

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

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

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

A.2   MDN for Message A.1 Above
             
      Date: Wed, 31 Jul 2002 13:34:50 GMT
      From: "trading partner"
      AS3-To: cyclone 
      AS3-Version: 1.0
      Message-ID: <709700825.1028122454671.JavaMail@ediXchange>
      Content-Type: multipart/signed; micalg=sha1; 
        protocol="application/pkcs7-signature"; 
        boundary="----=_Part_57_648441049.1028122454671"
      Content-Length: 1024

      ------=_Part_57_648441049.1028122454671

     & Content-Type: multipart/report; 
     &   Report-Type=disposition-notification; 
     &   boundary="----=_Part_56_1672293592.1028122454656"
     &
     &------=_Part_56_1672293592.1028122454656
     &Content-Type: text/plain
     &Content-Transfer-Encoding: 7bit
     &
     &MDN for -
     & Message ID: <200207310834482A70BF63@xxxxxxxx>
     &  From: cyclone 
     &  To: "trading partner"
     &  Received on: 2002-07-31 at 09:34:14 (EDT)
     &  Status: processed
     &  Comment: This is not a guarantee that the message has been
     &  completely processed or understood by the receiving translator
     &
     &------=_Part_56_1672293592.1028122454656
     &   Content-Type: message/disposition-notification
     &   Content-Transfer-Encoding: 7bit
     &

Harding, Scott                                                 [Page 28]


INTERNET DRAFT       FTP Transport Data for EDIINT           April 2005

     &   Reporting-UA: AS3 Server
     &   Original-Recipient: rfc822; "trading partner"
     &   Final-Recipient: rfc822; "trading partner"
     &   Original-Message-ID: <200207310834482A70BF63@xxxxxxxx>
     &   Received-content-MIC: 7v7F++fQaNB1sVLFtMRp+dF+eG4=, sha1
     &   Disposition: automatic-action/MDN-sent-automatically; processed
     &
     &------=_Part_56_1672293592.1028122454656--

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

     MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQ
     cp24hMJNbxDKHnlB9jTiQzLwSwo+/90Pc87x+Sc6EpFSUYWGAAAAAAAA
     ------=_Part_57_648441049.1028122454671--
      
Notes:

  1. The lines proceeded with "&" is what the signature is calculated 
     over.

  2. For details on how to prepare the multipart/signed with  protocol =
     "application/pkcs7-signature" see the "S/MIME  Message 
     Specification, PKCS Security Services for MIME".)

  3. Note that the textual first body part of the multipart/report can
be
     used to include a more detailed explanation of the error conditions

     reported by the disposition headers. The first body part of the 
     multipart/report when used in this way, allows a person to better 
     diagnose a problem in detail.

  4. As specified by RFC 1892 [10], returning the original or portions
of 
     the original message in the third body part of the multipart/report

     is not required. This is an optional body part. However, it is 
     RECOMMENDED that this body part be omitted or left blank.
*****************************************************

Terry Harding
Cyclone Commerce Inc.