doc: Add RFC documents

1 files changed, 2243 insertions, 0 deletions

diff --git a/doc/rfc/rfc4823.txt b/doc/rfc/rfc4823.txt
new file mode 100644
index 0000000..9b16ac4
--- /dev/null
+++ b/doc/rfc/rfc4823.txt
@@ -0,0 +1,2243 @@
+
+
+
+
+
+
+Network Working Group                                         T. Harding
+Request for Comments: 4823                                      R. Scott
+Category: Informational                                            Axway
+                                                              April 2007
+
+
+                 FTP Transport for Secure Peer-to-Peer
+              Business Data Interchange over the Internet
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   This Applicability Statement (AS) describes how to exchange
+   structured business data securely using the File Transfer Protocol
+   (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or
+   UN/EDIFACT), or other data used for business-to-business data
+   interchange for which MIME packaging can be accomplished using
+   standard MIME content types.  Authentication and data confidentiality
+   are obtained by using Cryptographic Message Syntax (S/MIME) security
+   body parts.  Authenticated acknowledgements employ multipart/signed
+   replies to the original message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harding & Scott              Informational                      [Page 1]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Overview ........................................................4
+      2.1. Overall Operations .........................................4
+      2.2. Purpose of a Security Guideline for MIME EDI ...............5
+      2.3. Definitions ................................................5
+           2.3.1. Terms ...............................................5
+           2.3.2. The Secure Transmission Loop ........................6
+           2.3.3. Definition of Receipts ..............................7
+      2.4. Operational Assumptions and Options ........................8
+           2.4.1. EDI/EC Process Assumptions ..........................8
+           2.4.2. Process Options .....................................8
+                  2.4.2.1. Security Options ...........................8
+                  2.4.2.2. Compression Options .......................10
+   3. Referenced RFCs and Their Contribution .........................10
+      3.1. RFC 959: File Transfer Protocol [3] .......................10
+      3.2. RFC 2228: FTP Security Extensions [4] .....................10
+      3.3. RFC 1847: MIME Security Multiparts [7] ....................10
+      3.4. RFC 3462: Multipart/Report [12] ...........................11
+      3.5. RFC 1767: EDI Content [2] .................................11
+      3.6. RFCs 2045, 2046, and 2049: MIME [1] .......................11
+      3.7. RFC 3798: Message Disposition Notification [6] ............11
+      3.8. RFC 3852: CMS [9] and RFC 3851: S/MIME Version 3.1
+           Message Specification [10] ................................11
+      3.9. RFC 3850: S/MIME Version 3.1 Certificate Handling [11] ....11
+      3.10. RFC 3274: Compressed Data Content Type for
+            Cryptographic Message Syntax (CMS) [17] ..................11
+      3.11. RFC 3023: XML Media Types [16] ...........................12
+   4. Structure of an AS3 Message ....................................12
+      4.1. Introduction ..............................................12
+      4.2. Structure of an Internet EDI MIME Message .................12
+   5. AS3-Specific Headers ...........................................13
+      5.1. AS3-From and AS3-To Headers ...............................13
+      5.2. AS3-Version Header ........................................14
+   6. FTP Considerations .............................................15
+      6.1. FTP Security Requirements .................................15
+      6.2. Large File Transfers ......................................15
+      6.3. MIME Considerations for FTP ...............................15
+           6.3.1. Required/Optional Headers ..........................15
+           6.3.2. Content-Transfer-Encoding ..........................16
+           6.3.3. Epilogue Must Be Empty .............................16
+           6.3.4. Message-Id and Original-Message-Id .................16
+   7. Structure and Processing of an MDN Message .....................17
+      7.1. Introduction ..............................................17
+      7.2. Message Disposition Notifications (MDN) ...................19
+      7.3. Requesting a Signed Receipt ...............................19
+           7.3.1. Signed Receipt Considerations ......................22
+
+
+
+Harding & Scott              Informational                      [Page 2]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+      7.4. MDN Format and Value ......................................23
+           7.4.1. AS3-MDN General Formats ............................23
+           7.4.2. AS3-MDN Construction ...............................24
+           7.4.3. AS3-MDN Fields .....................................25
+           7.4.4. Additional AS3-MDN Programming Notes ...............26
+      7.5. Disposition Mode, Type, and Modifier ......................29
+           7.5.1. Disposition Mode Overview ..........................29
+           7.5.2. Successful Processing Status Indication ............29
+           7.5.3. Unsuccessful Processed Content .....................29
+           7.5.4. Unsuccessful Non-Content Processing ................30
+           7.5.5. Processing Warnings ................................31
+   8. Public Key Certificate Handling ................................32
+   9. Security Considerations ........................................33
+   10. References ....................................................34
+      10.1. Normative References .....................................34
+      10.2. Informative References ...................................36
+   Appendix A. Message Examples ......................................37
+      A.1. Signed Message Requesting a Signed Receipt ................37
+      A.2. MDN for Message A.1 Above .................................37
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harding & Scott              Informational                      [Page 3]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+1.  Introduction
+
+   Previous work on Internet EDI focused on specifying MIME content
+   types for EDI data [2] and extending this work to support secure
+   EC/EDI transport over SMTP [5].  This document expands on RFC 1767 to
+   specify a comprehensive set of data security features, specifically,
+   data privacy, data integrity, authenticity, non-repudiation of
+   origin, and non-repudiation of receipt over FTP.  This document also
+   recognizes contemporary RFCs and is attempting to "re-invent" as
+   little as possible.  While this document focuses on EDI data, any
+   other data type describable in a MIME format is also supported.
+
+   Internet MIME-based EDI can be accomplished by using and complying
+   with the following documents:
+
+         - RFC 959: File Transfer Protocol
+         - RFC 2228: FTP Security Extensions
+         - RFC 1767: EDI Content Type
+         - RFC 3023: XML Media Types
+         - RFC 1847: Security Multiparts for MIME
+         - RFC 3462: Multipart/Report
+         - RFCs 2045 to 2049: MIME
+         - RFC 3798: Message Disposition Notification
+         - RFCs 3850, 3851, and 3852: S/MIME v3.1 Specifications
+         - RFC 3274: Compressed Data Content for Cryptographic Message
+           Syntax
+         - RFC 4217: Securing FTP with TLS
+         - "Compressed Data for EDIINT" by T. Harding
+
+   Our intent here is to define clearly and precisely how these are used
+   together, and what is required by user agents to be compliant with
+   this document.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and  "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [19].
+
+2.  Overview
+
+2.1.  Overall Operations
+
+   An FTP upload operation is used to send appropriately packaged EDI,
+   XML, or other business data.  The receiving application will poll the
+   FTP server for inbound messages, unpackage and handle the message
+   data, and generate a reply for the originator that contains a message
+   disposition acknowledgement within a multipart/report that is signed
+   or unsigned.  This request/reply transactional interchange provides
+   secure, reliable, and authenticated transport for EDI or other
+
+
+
+Harding & Scott              Informational                      [Page 4]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+   business data using FTP.  The security protocols and structures used
+   also support auditable records of these transmissions.
+
+2.2.  Purpose of a Security Guideline for MIME EDI
+
+   The purpose of these specifications is to ensure interoperability
+   between B2B Electronic Commerce user agents, invoking some or all of
+   the commonly expected security features.  This document is also NOT
+   limited to strict EDI use, but applies to any electronic commerce
+   application where business data needs to be exchanged over the
+   Internet in a secure manner.
+
+2.3.  Definitions
+
+2.3.1.  Terms
+
+   AS3                  Applicability Statement 3.  This is the third
+                        applicability statement produced by the IETF
+                        EDIINT working group.
+
+   EDI                  Electronic Data Interchange
+
+   EC                   Business-to-Business Electronic Commerce
+
+   B2B                  Business to Business
+
+   Receipt              The functional message that is sent from a
+                        receiver to a sender to acknowledge receipt of
+                        an EDI/EC interchange.
+
+   Signed Receipt       A receipt containing a digital signature.
+
+   Message Disposition  The Internet messaging format used to convey a
+   Notification (MDN)   receipt.  This term is used interchangeably with
+                        receipt.  An MDN is a receipt.
+
+   Non-repudiation of NRR is a "legal event" that occurs when the
+   receipt (NRR)        original sender of an EDI/EC interchange has
+                        verified the signed receipt coming back from the
+                        receiver.  NRR IS NOT a functional or a
+                        technical message.
+
+   S/MIME               A format and protocol for adding Cryptographic
+                        signature and/or encryption services to Internet
+                        MIME messages.
+
+
+
+
+
+
+Harding & Scott              Informational                      [Page 5]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+                        NOTE: While the S/MIME specification describes
+                              more than one format for a signed message,
+                              all signed messages or receipts used with
+                              AS3 MUST utilize the multipart/signed
+                              format.
+
+   SHA-1                A secure, one-way hash algorithm used in
+                        conjunction with digital signature.  SHA-1 is
+                        the recommend algorithm for AS3.
+
+   MD5                  A secure, one-way hash algorithm used in
+                        conjunction with digital signature.  This
+                        algorithm is acceptable but not recommended due
+                        to its short key length and known weaknesses.
+
+   MIC                  The message integrity check (MIC) is a
+                        representation of the message digest, which
+                        results from the application of the selected
+                        hash algorithm to the content to be signed.  Of
+                        particular interest is the digital signature,
+                        which includes an encrypted copy of the digest.
+                        Additionally, an MDN containing a Received-
+                        content-MIC header will also contain (as that
+                        header's value) a base-64-encoded representation
+                        of the digest.
+
+   User Agent (UA)      The application that handles and processes the
+                        AS3 request.
+
+   STL                  Secure Transmission Loop, described in the next
+                        section.
+
+2.3.2.  The Secure Transmission Loop
+
+   This document's focus is on the formats and protocols for exchanging
+   EDI/EC content to which security services have been applied using the
+   File Transmission Protocol (FTP) as the transport.
+
+   The "Secure Transmission Loop" (STL) comprises the following two
+   steps:
+
+   a) The originator sends a signed and encrypted document with a
+      request for a signed receipt.
+
+   b) The recipient decrypts the document, verifies the signature, and
+      returns a signed receipt to the sender.
+
+
+
+
+
+Harding & Scott              Informational                      [Page 6]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+   In other words, the following events occur during the execution of
+   the STL:
+
+   - The organization sending EDI/EC data signs and encrypts the data
+     using S/MIME.  In addition, the message will request a signed
+     receipt to be returned to the sender of the message.
+
+   - The receiving organization decrypts the message and verifies the
+     signature, resulting in verified integrity of the data and
+     authenticity of the sender.
+
+   - The receiving organization then returns a signed receipt, as
+     requested to the sending organization in the form of a message
+     disposition notification.  This signed receipt will contain the
+     hash of the signature from the received message, indicating to the
+     sender that the received message was verified and/or decrypted
+     properly.
+
+   The above describes functionality that, if implemented, will satisfy
+   all security requirements and provide non-repudiation of receipt for
+   the exchange.  While trading partners will usually want to utilize
+   the STL, this specification does not require it.
+
+2.3.3.  Definition of Receipts
+
+   The term used for both the functional activity and the message for
+   acknowledging delivery of an EDI/EC interchange is "receipt" or
+   "signed receipt".  The term receipt is used if the acknowledgment is
+   for an interchange resulting in a receipt that is NOT signed.  The
+   term signed receipt is used if the acknowledgment is for an
+   interchange resulting in a receipt that IS signed.  A term often used
+   in combination with receipts is non-repudiation of receipt.  NRR
+   refers to a legal event that occurs only when the original sender of
+   an interchange has verified the signed receipt coming back from the
+   recipient of the message.  Note that NRR is not possible without
+   signatures.
+
+   For additional information on formatting and processing receipts in
+   AS3, refer to Section 7.
+
+
+
+
+
+
+
+
+
+
+
+
+Harding & Scott              Informational                      [Page 7]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+2.4.  Operational Assumptions and Options
+
+2.4.1.  EDI/EC Process Assumptions
+
+   - Encrypted object is an EDI/EC Interchange.
+
+     This specification assumes that a typical EDI/EC interchange is the
+     lowest level object that will be subject to the application of
+     security services.
+
+     Specifically, for EDI ANSI X12, the entire document (including the
+     ISA and IEA segments) is the atom to which security is applied.
+     For EDIFACT, the corresponding definition includes the segments
+     UNA/UNB and UNZ.  In other words, EDI/EC interchanges including
+     envelope segments remain intact and unreadable during secure
+     transport.
+
+   - EDI envelope headers are encrypted.
+
+     Congruent with the above statement, EDI envelope headers are NOT
+     visible in the MIME package.  In order to optimize routing from
+     existing commercial EDI networks (called Value Added Networks or
+     VANs) to the Internet, work may need to be done in the future to
+     define ways to extract some elements of the envelope to make them
+     visible; however, that is beyond the scope of this specification.
+
+   - X12.58 and UN/EDIFACT security considerations
+
+     The most common EDI standards bodies, ANSI X12 and EDIFACT, have
+     defined internal provisions for security.  X12.58 is the security
+     mechanism for ANSI X12, and AUTACK provides security for EDIFACT.
+     This specification DOES NOT dictate use or non-use of these
+     security standards.  They are both fully compatible, though
+     possibly redundant, with this specification.
+
+2.4.2.  Process Options
+
+2.4.2.1.  Security Options
+
+   - Encrypted or un-encrypted data
+
+     This specification allows for EDI/EC message exchange where the
+     EDI/EC data can be either un-protected or protected by means of
+     encryption.
+
+
+
+
+
+
+
+Harding & Scott              Informational                      [Page 8]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+   - Signed or unsigned data
+
+     This specification allows for EDI/EC message exchange with or
+     without digital signature of the original EDI transmission.
+
+   - Use of receipt or not
+
+     This specification allows for EDI/EC message transmission with or
+     without a request for receipt notification.  If a signed receipt
+     notification is requested, however, a MIC value is REQUIRED as part
+     of the returned receipt, unless an error condition occurs that
+     results in the inability to compute a valid digest.  (Such a case
+     would result, for instance, if an encrypted message could not be
+     decrypted.) Under such circumstances, an unsigned receipt (MDN)
+     SHOULD be returned with the correct "disposition modifier" error
+     value.
+
+   - Security formatting
+
+     This specification relies on the guidelines set forth in RFCs 3852
+     [9] and 3851 [10].  The first of these RFCs describes the
+     Cryptographic Message Syntax (CMS), and the second contains the
+     S/MIME Version 3.1 Message Specification describing a MIME
+     container for CMS objects.  Whenever the term S/MIME is used in
+     this document, it refers to Version 3.1 as described therein.
+
+   - Hash function, message digest choices
+
+     When a signature is used, it is RECOMMENDED that the SHA-1 hash
+     algorithm be used for all outgoing messages; however, both MD5 and
+     SHA-1 MUST be supported for incoming messages.
+
+   - Permutation summary
+
+     In summary, the following twelve security permutations are possible
+     in any given trading relationship:
+
+     1.  Sender sends un-encrypted data, does NOT request a receipt.
+
+     2.  Sender sends un-encrypted data, requests an unsigned receipt.
+         The receiver sends back the unsigned receipt.
+
+     3.  Sender sends un-encrypted data, requests a signed receipt.  The
+         receiver sends back the signed receipt.
+
+     4.  Sender sends encrypted data, does NOT request a receipt.
+
+
+
+
+
+Harding & Scott              Informational                      [Page 9]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+     5.  Sender sends encrypted data, requests an unsigned receipt.  The
+         receiver sends back the unsigned receipt.
+
+     6.  Sender sends encrypted data, requests a signed receipt.  The
+         receiver sends back the signed receipt.
+
+     7.  Sender sends signed data, does NOT request a receipt.
+
+     8.  Sender sends signed data, requests an unsigned receipt.
+         Receiver sends back the unsigned receipt.
+
+     9.  Sender sends signed data, requests a signed receipt.  Receiver
+         sends back the signed receipt.
+
+     10. Sender sends encrypted and signed data, does NOT request a
+         receipt.
+
+     11. Sender sends encrypted and signed data, requests an unsigned
+         receipt.  Receiver sends back the unsigned receipt.
+
+     12. Sender sends encrypted and signed data, requests a signed
+         receipt.  Receiver sends back the signed receipt.  This case
+         represents the Secure Transmission Loop described above.
+
+2.4.2.2.  Compression Options
+
+   The AS3 specification supports compression of transmitted data
+   directly through the application of RFC 3274.  Implementation details
+   may be found in that RFC and in Harding's document, "Compressed Data
+   for EDIINT".
+
+3.  Referenced RFCs and Their Contribution
+
+3.1.  RFC 959: File Transfer Protocol [3]
+
+   RFC 959 specifies how data is transferred using the File Transfer
+   Protocol (FTP)
+
+3.2.  RFC 2228: FTP Security Extensions [4]
+
+   This RFC describes a framework for providing security services to
+   FTP.
+
+3.3.  RFC 1847: MIME Security Multiparts [7]
+
+   This document defines security multiparts for MIME:
+   multipart/encrypted and multipart/signed.
+
+
+
+
+Harding & Scott              Informational                     [Page 10]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+3.4.  RFC 3462: Multipart/Report [12]
+
+   RFC 3462 defines the use of the multipart/report content type, upon
+   which RFC 3798 builds to define the Message Disposition Notification.
+
+3.5.  RFC 1767: EDI Content [2]
+
+   This RFC defines the use of content type "application" for ANSI X12
+   (application/EDI-X12), EDIFACT (application/EDIFACT), and mutually
+   defined EDI (application/EDI-Consent).
+
+3.6.  RFCs 2045, 2046, and 2049: MIME [1]
+
+   These are the basic MIME standards, upon which all MIME-related RFCs
+   build, including this one.  Key contributions include definitions of
+   "content type", "sub-type", and "multipart", as well as encoding
+   guidelines, which establish 7-bit US-ASCII as the canonical character
+   set to be used in Internet messaging.
+
+3.7.  RFC 3798: Message Disposition Notification [6]
+
+   This Internet RFC defines how a Message Disposition Notification
+   (MDN)is requested, as well as the format and syntax of the MDN.  The
+   MDN is the vehicle used by this specification to provide both signed
+   and unsigned receipts.
+
+3.8.  RFC 3852: CMS [9] and RFC 3851: S/MIME Version 3.1 Message
+      Specification [10]
+
+   This specification describes how MIME shall carry Cryptographic
+   Message Syntax (CMS) Objects.
+
+3.9.  RFC 3850: S/MIME Version 3.1 Certificate Handling [11]
+
+   RFC 3850 describes certificate handling in the context of CMS and
+   S/MIME.
+
+3.10.  RFC 3274: Compressed Data Content Type for Cryptographic Message
+       Syntax (CMS) [17]
+
+   This specification provides a mechanism to wrap compressed data
+   within a CMS object.
+
+
+
+
+
+
+
+
+
+Harding & Scott              Informational                     [Page 11]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+3.11.  RFC 3023: XML Media Types [16]
+
+   This RFC defines the use of content type "application" for XML.  Note
+   that while conforming implementations SHOULD support the expanded
+   syntax that RFC 3023 introduces for the "+xml" suffix, no support for
+   external parsed entity types is anticipated (as it adds significant
+   complexity to signature processing).
+
+4.  Structure of an AS3 Message
+
+4.1.  Introduction
+
+   The basic structure of AS3 messages comprises MIME encapsulated data
+   with both customary MIME headers and a few additional AS3-specific
+   outer headers.  The structures below are described hierarchically in
+   terms of which RFCs have been applied to form the specific structure.
+   The reader is referred directly to the referenced RFCs for
+   implementation details.
+
+   Any additional restrictions imposed by this AS are specifically
+   discussed in the sections that follow.
+
+4.2.  Structure of an Internet EDI MIME Message
+
+   No encryption, no signature
+
+     -RFC822/2045
+       -RFC1767/RFC2376 (application/EDIxxxx or /xml)
+
+   No encryption, signature
+
+     -RFC822/2045
+       -RFC1847 (multipart/signed)
+         -RFC1767/RFC2376 (application/EDIxxxx or /xml)
+         -RFC3851 (application/pkcs7-signature)
+
+   Encryption, no signature
+
+     -RFC822/2045
+       -RFC3851 (application/pkcs7-mime)
+         -RFC1767/RFC2376  (application/EDIxxxx or /xml)(encrypted)
+
+
+
+
+
+
+
+
+
+
+Harding & Scott              Informational                     [Page 12]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+   Encryption, signature
+
+     -RFC822/2045
+       -RFC3851 (application/pkcs7-mime)
+         -RFC1847 (multipart/signed)(encrypted)
+           -RFC1767/RFC2376  (application/EDIxxxx or /xml)(encrypted)
+           -RFC3851 (application/pkcs7-signature)(encrypted)
+
+   MDN, no signature
+
+     -RFC822/2045
+       -RFC3798 (message/disposition-notification)
+
+   MDN, signature
+
+     -RFC822/2045
+       -RFC1847 (multipart/signed)
+         -RFC3798 (message/disposition-notification)
+         -RFC3851 (application/pkcs7-signature)
+
+   While all MIME content types SHOULD be supported,
+   the following MIME content types MUST be supported:
+
+     Content-Type: multipart/signed
+     Content-Type: multipart/report
+     Content-type: message/disposition-notification
+     Content-Type: application/PKCS7-signature
+     Content-Type: application/PKCS7-mime
+     Content-Type: application/EDI-X12
+     Content-Type: application/EDIFACT
+     Content-Type: application/edi-consent
+     Content-Type: application/XML
+
+5.  AS3-Specific Headers
+
+5.1.  AS3-From and AS3-To Headers
+
+   The AS3-From and AS3-To headers have been provided to assist the
+   sender and the recipient of an EC document to identify each other:
+
+      AS3-From: < AS3-name >
+      AS3-To:   < AS3-name >
+
+   These headers contain textual values, described by the ABNF [22]
+   below, identifying the sender/receiver of a data exchange.  A value
+   may be company specific (e.g., a Data Universal Numbering System
+   (DUNS) number), or it may be simply some string mutually acceptable
+   to both trading partners used to identify each to the other.
+
+
+
+Harding & Scott              Informational                     [Page 13]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+    AS3-text = "!" /           ; printable ASCII characters
+               %d35-91 /       ; except double-quote (%d34)
+               %d93-126        ; or backslash (%d92)
+
+    AS3-qtext = AS3-text / SP  ; allow space only in quoted text
+
+    AS3-quoted-pair = "\" DQUOTE /  ; \" or
+                      "\" "\"       ; \\
+
+    AS3-quoted-name = DQUOTE 1*128( AS3-qtext /
+                      AS3-quoted-pair) DQUOTE
+
+    AS3-atomic-name = 1*128AS3-text
+
+    AS3-name = AS3-atomic-name / AS3-quoted-name
+
+    Note: SP and DQUOTE are defined in [ABNF]RFC 4234.
+
+   The AS3-From header value and the AS3-To header value MUST each be an
+   AS3-name comprising 1 to 128 printable ASCII characters.  The header
+   MUST NOT be folded, and the value for each of these headers is case-
+   sensitive.
+
+   The AS3-quoted-name SHOULD be used only if the AS3-name does not
+   conform to AS3-atomic-name.
+
+   The AS3-To and AS3-From header fields MUST be present in all AS3
+   messages and AS3 MDNs.
+
+   Implementations that map entities such as EDI identifiers/qualifiers
+   to AS3 identifiers may choose to constrain the set of AS3-To/AS3-From
+   text values to a subset of the full set defined above, but they may
+   not extend that set.
+
+   If the AS3-From or the AS3-To or the association of the two header
+   values is determined to be invalid or unknown to the receiving
+   system, the receiving system MAY respond with an unsigned MDN
+   containing an explanation of the error if the sending system
+   requested an MDN, but it is not required to return an MDN under those
+   circumstances.
+
+5.2.  AS3-Version Header
+
+   The AS3-Version header is a header that is required only if the value
+   of the header is not "1.0".  Its purpose is to allow systems to
+   determine which version of this specification (should the
+   specification evolve over time) the sender of a document has used to
+
+
+
+
+Harding & Scott              Informational                     [Page 14]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+   package the document.  A user agent MUST NOT reject a message if the
+   version header is missing.
+
+   AS3-Version: 1*DIGIT . 1*DIGIT
+
+   A version header value of "1.1" indicates an implementation can
+   support EDIINT data compression [20].  A user agent MUST NOT send
+   compressed messages to trading partners who do not use a version
+   header of "1.1" or greater.
+
+6.  FTP Considerations
+
+6.1.  FTP Security Requirements
+
+   FTP has long been viewed as an insecure protocol primarily because of
+   its use of cleartext authentication [3].  This is addressed by RFC
+   2228 [4], and the use of one of the security mechanisms described
+   therein is strongly encouraged.  Specifically, conforming
+   implementations of AS3 SHALL employ FTP client/servers that support
+   the AUTH command described within [4].  While any authentication
+   mechanism based upon [4] MAY be utilized, AUTH TLS (as described in
+   [18]) MUST be supported. (Note that [18] relies on TLS Version 1.0
+   [13], not Version 1.1 [23].)
+
+6.2.  Large File Transfers
+
+   Large files are handled correctly by the TCP layer.  However, the
+   mechanism for compressing data, referenced in Section 2.4.2.2,
+   efficiently reduces transmission requirements for many data types
+   (including both XML and traditional EDI data).  Additionally, some
+   FTP implementations support compression as well.
+
+6.3.  MIME Considerations for FTP
+
+6.3.1.  Required/Optional Headers
+
+   An AS3 message MUST contain the following outer headers:
+
+        AS3-To
+        AS3-From
+        Date
+        Message-ID
+        Content-Type
+
+
+
+
+
+
+
+
+Harding & Scott              Informational                     [Page 15]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+   An AS3 message OPTIONALLY MAY contain the following outer headers:
+
+        Subject
+        AS3-Version (assumed to be 1.0 if not present)
+        Content-Length
+
+   An AS3 message requesting a receipt MUST contain a Disposition-
+   Notification-To header and MAY contain a Disposition-Notification-
+   Options header (if the receipt is to be signed).
+
+   Additional headers MAY be present but are ignored.
+
+6.3.2.  Content-Transfer-Encoding
+
+   FTP defines several data structures and character encodings via the
+   STRU[cture] and TYPE commands.  AS3 requires the file-structure
+   (default) and the image type.  The Content-Transfer-Encoding header
+   SHOULD NOT be used; if the header is present, it SHOULD have a value
+   of binary or 8-bit.  The absence of this header or the use of
+   alternate values such as "base64" or "quoted-printable" MUST NOT
+   result in transaction failure.  Content transfer encoding of MIME
+   parts within the AS3 message are similarly constrained.
+
+6.3.3.  Epilogue Must Be Empty
+
+   A MIME message containing an epilogue [1] SHALL NOT be used.
+
+6.3.4.  Message-Id and Original-Message-Id
+
+   Message-Id and Original-Message-Id are formatted as defined in
+   Section 3.6.4 of RFC 2822 [15]: "<" id-left "@" id-right ">".
+   Message-Id length is a maximum of 998 characters.  Message-Id SHOULD
+   be globally unique; id-right should be something unique to the
+   sending host environment (e.g., a host name).  When sending a
+   message, always include the angle brackets.  Angle brackets are not
+   part of the Message-Id value.
+
+   NOTE: When creating the Original-Message-Id header in an MDN, always
+         use the exact syntax contained in the original message: do not
+         strip or add "angle brackets".
+
+
+
+
+
+
+
+
+
+
+
+Harding & Scott              Informational                     [Page 16]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+7.  Structure and Processing of an MDN Message
+
+7.1.  Introduction
+
+   In order to support non-repudiation of receipt, a signed receipt,
+   based on digitally signing a message disposition notification, is to
+   be implemented by a receiving trading partner's UA.  The message
+   disposition notification specified by RFC 3798 is digitally signed by
+   a receiving trading partner as part of a multipart/signed MIME
+   message.
+
+   The following support for signed receipts is REQUIRED:
+
+   1) The ability to create a multipart/report; where the report-type =
+      disposition-notification.
+
+   2) The ability to calculate a message integrity check (MIC) on the
+      received message.  The calculated MIC value will be returned to
+      the sender of the message inside the signed receipt.
+
+   3) The ability to create a multipart/signed content with the message
+      disposition notification as the first body part, and the signature
+      as the second body part.
+
+   4) The ability to return the signed receipt to the sending trading
+      partner.
+
+   The signed receipt is used to notify a sending trading partner that
+   requested the signed receipt that:
+
+   1) The receiving trading partner acknowledges receipt of the sent EC
+      Interchange.
+
+   2) If the sent message was signed, then the receiving trading partner
+      has authenticated the sender of the EC Interchange.
+
+   3) If the sent message was signed, then the receiving trading partner
+      has verified the integrity of the sent EC Interchange.
+
+   Regardless of whether the EDI/EC Interchange was sent in S/MIME
+   format or not, the receiving trading partner's UA MUST provide the
+   following basic processing:
+
+   1) If the sent EDI/EC Interchange is encrypted, then the encrypted
+      symmetric key, and initialization vector (if applicable) is
+      decrypted using the receiver's private key.
+
+
+
+
+
+Harding & Scott              Informational                     [Page 17]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+   2) The decrypted symmetric encryption key is then used to decrypt the
+      EDI/EC Interchange.
+
+   3) The receiving trading partner authenticates signatures in a
+      message using the sender's public key.
+
+      The authentication algorithm performs the following:
+
+      a) The message integrity check (MIC or Message Digest) is
+         decrypted using the sender's public key.
+
+      b) A MIC on the signed contents (the MIME header and encoded EDI
+         object, as per RFC 1767) in the message received is calculated
+         using the same one-way hash function that the sending trading
+         partner used.
+
+      c) The MIC extracted from the message that was sent and the MIC
+         calculated using the same one-way hash function that the
+         sending trading partner used are compared for equality.
+
+   4) The receiving trading partner formats the MDN and sets the
+      calculated MIC into the "Received-content-MIC" extension field.
+
+   5) The receiving trading partner creates a multipart/signed MIME
+      message according to RFC 1847.
+
+   6) The MDN is the first part of the multipart/signed message, and the
+      digital signature is created over this MDN, including its MIME
+      headers.
+
+   7) The second part of the multipart/signed message contains the
+      digital signature.  The "protocol" option specified in the second
+      part of the multipart/signed is as follows: S/MIME: protocol =
+      "application/pkcs7-signature".
+
+   8) The signature information is formatted according to S/MIME
+      specifications.  The EC Interchange and the RFC 1767 MIME EDI
+      content header can actually be part of a multipart MIME content
+      type.  When the EDI Interchange is part of a multipart MIME
+      content type, the MIC MUST be calculated across the entire
+      multipart content, including the MIME headers.
+
+   The signed MDN, when received by the sender of the EDI Interchange
+   can be used by the sender:
+
+   1) As an acknowledgment that the EDI Interchange was sent, and then
+      was delivered and acknowledged by the receiving trading partner.
+
+
+
+
+Harding & Scott              Informational                     [Page 18]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+      The receiver does this by returning the original-message-id of the
+      sent message in the MDN portion of the signed receipt.
+
+   2) As an acknowledgment that the integrity of the EDI Interchange was
+      verified by the receiving trading partner.  The receiver does this
+      by returning the calculated MIC of the received EC Interchange
+      (and 1767 MIME headers) in the "Received-content-MIC" field of the
+      signed MDN.
+
+   3) As an acknowledgment that the receiving trading partner has
+      authenticated the sender of the EDI Interchange.
+
+   4) As a non-repudiation of receipt when the signed MDN is
+      successfully verified by the sender with the receiving trading
+      partner's public key and the returned MIC value inside the MDN is
+      the same as the digest of the original message.
+
+7.2.  Message Disposition Notifications (MDN)
+
+   The AS3-MDNs are returned on a separate FTP TCP/IP connection and are
+   a response to an AS3 message.
+
+   The following diagram illustrates the delivery of an AS3-MDN
+   delivery:
+
+          AS3-MDN
+         [S] ----( connect )----> [R]   [FTP Server]
+         [S] ----( send )-------> [R]   [AS3-Message]
+         [S] ----( disconnect )-> [R]   [FTP Server]
+
+         [S] <---( connect )----- [R]   [FTP Server]
+         [S] <---( send )-------- [R]   [AS3-MDN]]
+         [S] <---( disconnect )-- [R]   [FTP Server]
+
+         Note: Refer to Section 7.4.4 for additional
+               programming notes.
+
+7.3.  Requesting a Signed Receipt
+
+   Message Disposition Notifications are requested as per RFC 3798.  A
+   request that the receiving user agent issue a message disposition
+   notification is made by placing the following header into the message
+   to be sent:
+
+   MDN-request-header = "Disposition-notification-to" ":" ftpurl
+
+   This syntax is a residual of the use of MDN's in an SMTP transfer.
+   Since this specification is adjusting the functionality from SMTP to
+
+
+
+Harding & Scott              Informational                     [Page 19]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+   FTP and retaining as much as possible from the [5] functionality, the
+   ftpurl must be present.
+
+   The ftpurl field is specified as an RFC 1738 <URL:"ftp://" login [
+   "/" fpath [ ";type=" ftptype ]]>, and while it MUST be present, it
+   may be ignored if the ftpurl points to an unknown location.  If the
+   ftpurl points to an unknown location, it is RECOMMENDED that the mdn
+   is returned back to a known ftpurl for the sender of the received
+   message.
+
+   For requesting MDN-based receipts, the originator supplies the
+   required extension headers that precede the message body.
+
+   The header "tags" are as follows:
+
+   A Disposition-notification-to header is added to indicate that a
+   message disposition notification is requested.  This header is
+   specified in [6].
+
+   A Message-ID header is added to support message reconciliation, so
+   that an Original-Message-Id value can be returned in the body part of
+   the MDN.
+
+   Other headers, especially "Date", SHOULD be supplied; the values of
+   these headers are often mentioned in the human-readable section of an
+   MDN to aid in identifying the original message.
+
+   Disposition-notification-options identifies characteristics of the
+   message.
+
+   The following Disposition notification is in accordance with [6].
+
+       EXAMPLE:
+         Disposition-notification-to:       // Requests the MDN
+           ftp://host:port/inbox            // Location to return MDN
+         Disposition-notification-options:  // The signing options for
+                                               MDN
+           signed-receipt-protocol=optional, pkcs7-signature;
+           signed-receipt-micalg=optional, sha1, md5
+
+   Disposition-notification-options syntax:
+
+   Disposition-notification-options =
+          "Disposition-Notification-Options:"
+           disposition-notification-parameters
+
+   disposition-notification-parameters =
+               parameter *(";" parameter)
+
+
+
+Harding & Scott              Informational                     [Page 20]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+   parameter = attribute "=" importance ", " value *("," value)
+
+   importance = "required" / "optional"
+
+   attribute = "signed-receipt-protocol" / "signed-receipt-micalg"
+
+   So the Disposition-notification-options string could be:
+
+     signed-receipt-protocol=optional, <protocol symbol>;
+     signed-receipt-micalg=optional, <micalg1>, <micalg2>,...;
+
+   The currently supported value for <protocol symbol> is "pkcs7-
+   signature" for the S/MIME detached signature format.
+
+   The currently supported values for MIC algorithm <micalg> values are:
+
+          Algorithm   Value
+           Used
+        --------   -------
+           MD5         md5
+           SHA-1       sha1
+
+   Receiving agents SHOULD be able to recover gracefully from a <micalg>
+   parameter value that they do not recognize.
+
+   The semantics of the "signed-receipt-protocol" parameter is as
+   follows:
+
+   1) The "signed-receipt-protocol" parameter is used to request a
+      signed receipt from the recipient trading partner.  The "signed-
+      receipt-protocol" parameter also specifies the format in which the
+      signed receipt should be returned to the requester.
+
+      The "signed-receipt-micalg" parameter is a list of MIC algorithms
+      preferred by the requester for use in signing the returned receipt
+      and calculating the micalg in the Received-content-MIC header.
+
+      The list of MIC algorithms should be honored by the recipient from
+      left to right.  Both the "signed-receipt-protocol" and the
+      "signed-receipt-micalg" option parameters are REQUIRED when
+      requesting a signed receipt.
+
+   2) The "importance" attribute of "Optional" is defined in RFC 3798,
+      Section 2.2, and has the following meaning:
+
+      Parameters with an importance of "Optional" permit a UA that does
+      not understand the particular options parameter to still generate
+      an MDN in response to a request for an MDN.  A UA that does not
+
+
+
+Harding & Scott              Informational                     [Page 21]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+      understand the "signed-receipt-protocol" parameter, or the
+      "signed-receipt-micalg" parameter, will obviously not return a
+      signed receipt.
+
+      The importance of "Optional" is used for the signed receipt
+      parameters because it is RECOMMENDED that an MDN be returned to
+      the requesting trading partner even if the recipient could not
+      sign it.
+
+      The returned MDN will contain information on the disposition of
+      the message as well as on why the MDN could not be signed.  See
+      the Disposition field in Section 7.5 for more information.
+
+   Within an EDI trading relationship, if a signed receipt is expected
+   and is not returned, then the validity of the transaction must be
+   determined by the trading partners.  Typically, if a signed receipt
+   is required by the trading relationship and is not received, the
+   transaction will likely not be considered valid.
+
+7.3.1.  Signed Receipt Considerations
+
+   The method used to request a receipt or a signed receipt is defined
+   in RFC 3798, "An Extensible Message Format for Message Disposition
+   Notifications".
+
+   The "rules" for processing a receipt-request follow:
+
+   1) When a receipt is requested, explicitly specifying that the
+      receipt be signed, then the receipt MUST be returned with a
+      signature unless conditions (2) or (3) below are applicable.
+
+   2) When a receipt is requested, explicitly specifying that the
+      receipt be signed, but the recipient cannot support either the
+      requested protocol format, or requested MIC algorithms, then
+      either a signed or unsigned receipt SHOULD be returned.
+
+   3) When a receipt is requested, explicitly specifying that the
+      receipt be signed, but the recipient is unable to compute the
+      digest (e.g., message was encrypted, and recipient unable to
+      decrypt), then the recipient SHOULD NOT return "Received-content-
+      MIC" in the MDN to the requestor.  If the MDN sets the disposition
+      (e.g., "processed/error: decryption-failed") appropriately, then
+      the "Received-content-MIC" may be returned, but the value must be
+      discarded.
+
+
+
+
+
+
+
+Harding & Scott              Informational                     [Page 22]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+   4) When a signature is not explicitly requested, or if the signed
+      receipt request parameter is not recognized by the UA, then no
+      receipt, an unsigned receipt, or a signed receipt MAY be returned
+      by the recipient.
+
+   5) If a message is received without a request for a receipt, then a
+      receipt (signed or unsigned) MAY be returned.
+
+      The "Received-content-MIC" MUST be calculated as follows:
+
+      - For any signed messages, the MIC to be returned is calculated on
+        the RFC 1767 MIME header and content.  Canonicalization as
+        specified in RFC 1848 MUST be performed before the MIC is
+        calculated, since the sender requesting the signed receipt was
+        also REQUIRED to canonicalize.
+
+      - For encrypted, unsigned messages, the MIC to be returned is
+        calculated on the decrypted RFC 1767 MIME header and content.
+        The content after decryption MUST be canonicalized before the
+        MIC is calculated.
+
+      - For unsigned, un-encrypted messages, the MIC MUST be calculated
+        over the message contents prior to Content-Transfer-Encoding and
+        without the MIME or any other RFC 822 [14] headers, since these
+        are sometimes altered or reordered by message transfer agents
+        (MTAs).
+
+7.4.  MDN Format and Value
+
+   This section defines the format of the AS3 Message Disposition
+   Notification (AS3-MDN).
+
+7.4.1.  AS3-MDN General Formats
+
+   The AS3-MDN follows the MDN specification [6] except where noted in
+   this section.  The modified entity definitions in this document use
+   the vertical-bar character, '|', to denote a logical "OR"
+   construction.  Refer to RFC 2045 for the format of MIME-message-
+   headers.
+
+     The format of the AS3-MDN is
+
+     MDN, no signature
+
+       -RFC822/2045
+         -RFC3798 (message/disposition-notification)
+
+
+
+
+
+Harding & Scott              Informational                     [Page 23]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+     MDN, signature
+
+       -RFC822/2045
+         -RFC1847 (multipart/signed)
+           -RFC3798 (message/disposition-notification)
+           -RFC3851 (application/pkcs7-signature)
+
+7.4.2.  AS3-MDN Construction
+
+   The AS3-MDN-body is formatted as a MIME multipart/report with a
+   report-type of "disposition-notification".
+
+   When unsigned, the transfer-layer ("outermost") entity-headers of the
+   AS3-MDN contain the Content-Type header that specifies a content type
+   of "multipart/report", parameters indicating the report-type, and the
+   value of the outermost multipart boundary.
+
+   When the AS3-MDN is signed, the transfer-layer ("outermost") entity-
+   headers of the AS3-MDN contain a Content-Type header that specifies a
+   content type of "multipart/signed", parameters indicating the
+   algorithm used to compute the message digest, the signature
+   formatting protocol (e.g., pkcs7-signature), and the value of the
+   outermost multipart boundary.  The first part of the MIME
+   multipart/signed message is an imbedded MIME multipart/report of type
+   "disposition-notification".  The second part of the multipart/signed
+   message contains a MIME application/pkcs7-signature message.
+
+   The first part of the MIME multipart/report is a "human-readable"
+   portion that contains a general description of the message
+   disposition.  The second part of the MIME multipart/report is a
+   "machine-readable" portion that is defined as
+
+     AS3-disposition-notification-content =
+               [ reporting-ua-field CRLF ]
+               [ mdn-gateway-field CRLF ]
+               [ original-recipient-field CRLF ]
+               final-recipient-field CRLF
+               [ original-message-id-field CRLF ]
+               AS3-disposition-field CRLF
+               *( failure-field CRLF )
+               *( error-field CRLF )
+               *( warning-field CRLF )
+               *( extension-field CRLF )
+               [ AS3-received-content-MIC-field CRLF ]
+
+   It is noted that several of the optional fields defined by RFC 3798
+   and shown above are not relevant to a point-to-point transport such
+   as FTP and would not normally appear in an AS3 MDN.
+
+
+
+Harding & Scott              Informational                     [Page 24]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+7.4.3.  AS3-MDN Fields
+
+   The rules for constructing the AS3-disposition-notification-content
+   are identical to the rules for constructing the disposition-
+   notification-content as defined in Section 7 of RFC 3798 [6] except
+   that the RFC 3798 disposition-field has been replaced with the AS3-
+   disposition-field and that the AS3-received-content-MIC field has
+   been added.  The differences between the RFC 3798 disposition-field
+   and the AS3-disposition-field are described below.  Where there are
+   differences between this document and RFC 3798, those entity names
+   have been changed by prepending "AS3-".  Entities below that do not
+   differ from RFC 3798 are not necessarily further defined in this
+   document.
+
+   Refer to RFC 3798 [6] and RFC 4234 [22] for entities that are not
+   further defined in this document.
+
+     AS3-disposition-field = "Disposition:" disposition-mode ";"
+                    AS3-disposition-type [ "/" AS3-disposition-modifier]
+
+     disposition-mode = action-mode "/" sending-mode
+
+     action-mode = "manual-action" / "automatic-action"
+
+     sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
+
+     AS3-disposition-type = "processed" / "failed"
+
+     AS3-disposition-modifier = ( "error" / "warning" ) /
+                                AS3-disposition-modifier-extension
+
+     AS3-disposition-modifier-extension =
+                "error: authentication-failed" /
+                "error: decompression-failed" /
+                "error: decryption-failed" /
+                "error: insufficient-message-security" /
+                "error: integrity-check-failed" /
+                "error: unexpected-processing-error" /
+                "warning: " AS3-MDN-warning-description /
+                "failure: " AS3-MDN-failure-description
+
+     AS3-MDN-warning-description = *( TEXT )
+
+     AS3-MDN-failure-description = *( TEXT )
+
+     AS3-received-content-MIC-field =
+                 "Received-content-MIC:" encoded-message-digest
+                 "," digest-alg-id CRLF
+
+
+
+Harding & Scott              Informational                     [Page 25]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+     encoded-message-digest =
+                1*( ALPHA / DIGIT / "/" / "+" ) *3"="
+                ;( i.e. base64( message-digest ) )
+
+     digest-alg-id = "sha1" / "md5"
+
+   The "Received-content-MIC" extension field is set after the integrity
+   of the received message is verified.  The MIC is the base64-encoded
+   message-digest computed over the received message with a hash
+   function.  This field is required for signed receipts but optional
+   for unsigned receipts.  For details defining the specific content
+   over which the message-digest is to be computed, see Section 7.3.1 of
+   this document.
+
+   The algorithm used to calculate the message digest MUST be the same
+   as the "micalg" value used by the sender in the multipart/signed
+   message.  When no signature is received, the message-digest MUST be
+   calculated using the algorithm specified by the "micalg" value in the
+   Disposition-Notification-Options header.  When no signature is
+   received and no micalg parameter is provided, then the SHA-1
+   algorithm MUST be used to calculate the digest.  This field is set
+   only when the contents of the message are processed successfully.
+   This field is used in conjunction with the recipient's signature on
+   the MDN in order for the sender to verify non-repudiation of receipt.
+
+   AS3-MDN field names (e.g., "Disposition:", "Final-Recipient:") are
+   case-insensitive (cf. RFC 3798, Section 3.1.1).
+
+   AS3-MDN action-modes, sending-modes, AS3-disposition-types, and AS3-
+   disposition-modifier values that are defined above, and user-supplied
+   *( TEXT ) values are also case-insensitive.  AS3 implementations MUST
+   NOT make assumptions regarding the values supplied for AS3-MDN-
+   warning-description or AS3-MDN-failure-description or for the values
+   of any (optional) error, warning, or failure fields.
+
+7.4.4.  Additional AS3-MDN Programming Notes
+
+   1.  Unlike SMTP, for FTP transactions, Original-Recipient and Final
+       Recipient SHOULD NOT be different.  The value in Original-
+       Message-ID MUST match the original Message-ID header value.
+
+   2.  Refer to RFC 3462 and RFC 3798 for the formatting of the
+       Content-Type entity-headers for the MDN.
+
+   3.  Use an action-mode of "automatic-action" when the disposition
+       described by the disposition type was a result of an automatic
+       action, rather than an explicit instruction by the user for this
+       message.
+
+
+
+Harding & Scott              Informational                     [Page 26]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+   4.  Use an action-mode of "manual-action" when the disposition
+       described by the disposition type was a result of an explicit
+       instruction by the user rather than some sort of automatically
+       performed action.
+
+   5.  Use a sending-mode of "MDN-sent-automatically" when the MDN is
+       sent because the UA had previously been configured to do so.
+
+   6.  Use a sending-mode of "MDN-sent-manually" when the user
+       explicitly gave permission for this particular MDN to be sent.
+
+   7.  The sending-mode "MDN-sent-manually" is ONLY meaningful with
+       "manual-action", not with "automatic-action".
+
+   8.  The "failed" disposition type MAY NOT be used for the situation
+       in which there is some problem in processing the message other
+       than interpreting the request for an MDN.  The "processed" or
+       other disposition type with appropriate disposition modifiers is
+       to be used in such situations.
+
+   9.  An AS3 implementation MUST present to its trading partners an
+       FTP-compliant server interface where inbound documents and MDNs
+       are received.
+
+   10. An AS3 implementation MUST be able to retrieve inbound messages
+       from its currently configured FTP server interface.
+
+   Note: Programming Notes 9 and 10 do not imply any specific method for
+         supplying the FTP server interface.  But, they do allow for
+         several different types of implementations.  Some vendors may
+         choose to imbed an FTP-compliant server interface within their
+         product, and others may choose to utilize off-the-shelf FTP
+         servers to supply the required FTP server interface.  Some may
+         choose to utilize hosting services provided by their trading
+         partner or by a third-party hosting service.  Whichever method
+         is utilized, an AS3 implementation MUST support rules 9 and 10.
+
+   11. AS3 implementations MAY imbed an FTP server interface within
+       their product.
+
+   12. AS3 implementations MUST be configurable to allow the use of an
+       external FTP hosting service.
+
+   Note: An external FTP hosting service may be hosted by a third-party
+         or possibly hosted by your trading partner.
+
+
+
+
+
+
+Harding & Scott              Informational                     [Page 27]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+   13. An AS3 implementation MUST be able to send business documents and
+       MDNs to a trading partner's currently configured FTP server
+       interface.
+
+   14. An AS3 implementation may imbed FTP client code into their
+       product or use a third-party FTP client.
+
+   15. Example Configurations
+
+       1. Peer to Peer
+          Trading Partner A (TPA) is using a local FTP server, and
+          Trading Partner B (TPB) is using an imbedded FTP server.
+
+       [A Client] ----( connect )----> [B Server]
+       [A Client] ----( send )-------> [B Server] [AS3-Message]
+       [A Client] ----( disconnect )-> [B Server]
+
+       [A Server] <---( connect )----- [B Client]
+       [A Server] <---( send )-------- [B Client] [AS3-MDN]]
+       [A Server] <---( disconnect )-- [B Server]
+       [A Client] <---( GET )--------- [A Server]
+
+       2. Third-Party Hosting
+          Both parties are using the same third-party-hosted FTP server.
+
+       [A Client] ----( connect )----> [Hosted Server]
+       [A Client] ----( send )-------> [Hosted Server] [AS3-Message]
+       [A Client] ----( disconnect )-> [Hosted Server]
+       [Hosted Server]( GET )--------> [B Client]
+
+       [Hosted Server] <---( connect )----- [B Client]
+       [Hosted Server] <---( send )-------- [B Client] [AS3-MDN]]
+       [Hosted Server] <---( disconnect )-- [B Client]
+       [A Client]      <---( GET )--------- [Hosted Server]
+
+       3. Trading Partner Hosting
+          TPA is using the imbedded FTP server hosted by TPB.
+
+       [A Client] ----( connect )----> [B Server]
+       [A Client] ----( send )-------> [B Server] [AS3-Message]
+       [A Client] ----( disconnect )-> [B Server]
+
+       [B Server] <---( connect )----- [B Client]
+       [B Server] <---( send )-------- [B Client] [AS3-MDN]]
+       [B Server] <---( disconnect )-- [B Client]
+       [A Client] <---( GET )--------- [B Server]
+
+
+
+
+
+Harding & Scott              Informational                     [Page 28]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+7.5.  Disposition Mode, Type, and Modifier
+
+7.5.1.  Disposition Mode Overview
+
+   This section will provide a brief overview of how processed, error,
+   failure, or warning notifications are used.
+
+7.5.2.  Successful Processing Status Indication
+
+   When a receipt or signed receipt is requested, and the received
+   message contents are successfully processed by the receiving EDI UA,
+   a receipt or MDN SHOULD be returned with the "disposition-type" set
+   to "processed".  When the MDN is sent automatically by the EDI UA,
+   and there is no explicit way for a user to control the sending of the
+   MDN, then the first part of the "disposition-mode" should be set to
+   "automatic-action".
+
+   When the MDN is being sent under user-configurable control, then the
+   first part of the "disposition-mode" should be set to "manual-
+   action".  Since a request for a signed receipt should always be
+   honored, the user MUST not be allowed to configure the UA not to send
+   a signed receipt when the sender requests one.
+
+   The second part of the "disposition-mode" is set to "MDN-sent-
+   manually" if the user gave explicit permission for the MDN to be
+   sent.  Again, the user MUST not be allowed to explicitly refuse to
+   send a signed receipt when the sender requests one.  The second part
+   of the "disposition-mode" is set to "MDN-sent-automatically" whenever
+   the EDI UA sends the MDN automatically, regardless of whether the
+   sending was under a user's, an administrator's, or software control.
+
+   Since EDI content is generally handled automatically by the EDI UA, a
+   request for a receipt or signed receipt will generally return the
+   following in the "disposition-field":
+
+   Disposition: automatic-action/MDN-sent-automatically; processed
+
+   Note this specification does not restrict the use of the
+   "disposition-mode" to just automatic actions.  Manual actions are
+   valid as long as it is kept in mind that a request for a signed
+   receipt MUST be honored.
+
+7.5.3.  Unsuccessful Processed Content
+
+   The request for a signed receipt requires the use of two
+   "disposition-notification-options", which specify the protocol format
+   of the returned signed receipt, and the MIC algorithm used to
+   calculate the MIC over the message contents.  The "disposition-field"
+
+
+
+Harding & Scott              Informational                     [Page 29]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+   values that should be used in the case where the message content is
+   being rejected or ignored should be specified in the MDN
+   "disposition-field" as below.  (An example of this case is when the
+   EDI UA determines that a signed receipt cannot be returned because it
+   does not support the requested protocol format, so the EDI UA chooses
+   not to process the message contents itself.)
+
+   Disposition: "disposition-mode"; failed/Failure: unsupported Format
+
+   The "failed" AS3-disposition-type should be used when a failure
+   occurs that prevents the proper generation of an MDN.
+
+   For example, this disposition-type would apply if the sender of the
+   message requested the application of an unsupported message-
+   integrity-check (MIC) algorithm.
+
+   The "failure:" AS3-disposition-modifier-extension should be used with
+   an implementation-defined description of the failure.
+
+   Further information about the failure may be contained in a failure-
+   field.  The syntax of the "failed" "disposition-type" is general,
+   allowing the sending of any textual information along with the
+   "failed"  "disposition-type".  Implementations WILL support any
+   printable textual characters after the Failure disposition-type.
+
+   For use in Internet EDI, the following "failed" values are pre-
+   defined and MUST be supported:
+
+        "Failure: unsupported format"
+        "Failure: unsupported MIC-algorithms"
+
+7.5.4.  Unsuccessful Non-Content Processing
+
+   When errors occur in processing the received message, other than
+   content, the "disposition-field" should be set to the "processed"
+   "disposition-type" value and the "error" "disposition-modifier"
+   value.
+
+   The "error" AS3-disposition-modifier with the "processed"
+   disposition-type should be used to indicate that an error of some
+   sort occurred that prevented successful processing of the message.
+
+   Further information may be contained in an error-field.
+
+   An "error:" AS3-disposition-modifier-extension should be used to
+   combine the indication of an error with a pre-defined description of
+   a specific, well-known error.  Further information about the error
+   may be contained in an error-field.
+
+
+
+Harding & Scott              Informational                     [Page 30]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+   For use in Internet EDI, the following "error" "disposition-modifier"
+   values are defined:
+
+   "Error: decryption-failed"
+      The receiver could not decrypt the message contents.
+
+   "Error: authentication-failed"
+      The receiver could not authenticate the sender.
+
+   "Error: integrity-check-failed"
+      The receiver could not verify content integrity.
+
+   "Error: insufficient-message-security"
+      The security level of the message did not match the agreed level
+      between TPs.
+
+   "Error: decompression-failed"
+      The receiver could not decompress the message contents.
+
+   "Error: unexpected-processing-error"
+      A catch-all for any additional processing errors.
+
+   An example of how the "disposition-field" would look when processing
+   errors, other than content, are detected is as follows:
+
+   EXAMPLE
+        Disposition: "disposition-mode";
+          processed/Error: decryption-failed
+
+7.5.5.  Processing Warnings
+
+   Situations arise in EDI where even if a trading partner cannot be
+   authenticated correctly, the trading partners still agree to continue
+   processing the EDI transactions.  Transaction reconciliation is done
+   between the trading partners at a later time.  In the content
+   processing warning situations described above, the "disposition-
+   field" SHOULD be set to the "processed" "disposition-type" value, and
+   the "warning" "disposition-modifier" value.
+
+   The "warning" AS3-disposition-modifier should be used with the
+   "processed" disposition-type to indicate that the message was
+   successfully processed but that an exceptional condition occurred.
+
+   Further information may be contained in a warning-field.
+
+
+
+
+
+
+
+Harding & Scott              Informational                     [Page 31]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+   A "warning:" AS3-disposition-modifier-extension should be used to
+   combine the indication of a warning with an implementation-defined
+   description of the warning.  Further information about the warning
+   may be contained in a warning-field.
+
+   For use in Internet EDI, the following "warning" "disposition-
+   modifier" values are defined:
+
+   "Warning: authentication-failed, processing continued"
+
+   An example of how the "disposition-field" would look when processing
+   warnings, other than content, are detected is as follows:
+
+   EXAMPLE
+       Disposition: "disposition-mode"; processed/Warning:
+         authentication-failed, processing continued
+
+8.  Public Key Certificate Handling
+
+   In the near term, the exchange of public keys and certification of
+   these keys must be handled as part of the process of establishing a
+   trading partnership.  The UA and/or EDI application interface must
+   maintain a database of public keys used for encryption or signatures,
+   in addition to the mapping between EDI trading partner ID and FTP
+   URL/URI.  The procedures for establishing a trading partnership and
+   configuring the secure EDI messaging system might vary among trading
+   partners and software packages.
+
+   X.509 certificates are REQUIRED.  It is RECOMMENDED that trading
+   partners self-certify each other if an agreed-upon certification
+   authority is not used.  This applicability statement does NOT require
+   the use of a certification authority.
+
+   The use of a certification authority is therefore OPTIONAL.
+   Certificates may be self-signed.  It is RECOMMENDED that when trading
+   partners are using S/MIME, that they also exchange public key
+   certificates using the recommendations specified in the S/MIME
+   Version 3.1 Message Specification.
+
+   The message formats and S/MIME conformance requirements for
+   certificate exchange are specified in this document.  In the long
+   term, additional Internet-EDI standards may be developed to simplify
+   the process of establishing a trading partnership, including the
+   third-party authentication of trading partners, as well as attributes
+   of the trading relationship.
+
+
+
+
+
+
+Harding & Scott              Informational                     [Page 32]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+9.  Security Considerations
+
+   This entire document is concerned with secure transport of business-
+   to-business data, and it considers both privacy and authentication
+   issues.
+
+   Extracted from S/MIME Version 2 Message Specification [21]:
+
+      40-bit encryption is considered weak by most cryptographers.
+      Using weak cryptography in S/MIME offers little actual security
+      over sending plaintext.  However, other features of S/MIME, such
+      as the specification of tripleDES and the ability to announce
+      stronger cryptographic capabilities to parties with whom you
+      communicate, allow senders to create messages that use strong
+      encryption.  Using weak cryptography is never recommended unless
+      the only alternative is no cryptography.  When feasible, sending
+      and receiving agents should inform senders and recipients the
+      relative cryptographic strength of messages.
+
+   Extracted from S/MIME Version 3.1 Certificate Handling [11]:
+
+      When processing certificates, there are many situations where the
+      processing might fail.  Because the processing may be done by a
+      user agent, a security gateway, or other program, there is no
+      single way to handle such failures.  Just because the methods to
+      handle the failures has not been listed, however, the reader
+      should not assume that they are not important.  The opposite is
+      true: if a certificate is not provably valid and associated with
+      the message, the processing software should take immediate and
+      noticeable steps to inform the end user about it.
+
+      Some of the many places where signature and certificate checking
+      might fail include:
+
+      -  no Internet mail addresses in a certificate matches the sender
+         of a message, if the certificate contains at least one mail
+         address
+      -  no certificate chain leads to a trusted CA
+      -  no ability to check the Certificate Revocation List (CRL) for a
+         certificate
+      -  an invalid CRL was received
+      -  the CRL being checked is expired
+      -  the certificate is expired
+      -  the certificate has been revoked
+
+
+
+
+
+
+
+Harding & Scott              Informational                     [Page 33]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+      There are certainly other instances where a certificate may be
+      invalid, and it is the responsibility of the processing software
+      to check them all thoroughly, and to decide what to do if the
+      check fails.
+
+   The following certificate types MUST be supported.
+          With URL
+          Without URL
+          Self Certified
+          Certification Authority Certified
+
+   The complete certification chain MUST be included in all
+   certificates.  All certificate verifications MUST "chain to root".
+   Additionally, the certificate hash should match the hash recomputed
+   by the receiver.
+
+10.  References
+
+10.1.  Normative References
+
+   [1]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+         Extensions (MIME) Part One: Format of Internet Message Bodies",
+         RFC 2045, November 1996.
+
+         Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+         Extensions (MIME) Part Two: Media Types", RFC 2046, November
+         1996.
+
+         Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+         Extensions (MIME) Part Five: Conformance Criteria and
+         Examples", RFC 2049, November 1996.
+
+   [2]   Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767,
+         March 1995.
+
+   [3]   Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
+         RFC 959, October 1985.
+
+   [4]   Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 2228,
+         October 1997.
+
+   [5]   Harding, T., Drummond, R., and C. Shih, "MIME-based Secure
+         Peer-to-Peer Business Data Interchange over the Internet", RFC
+         3335, September 2002.
+
+   [6]   Hansen, T. and G. Vaudreuil, "Message Disposition
+         Notification", RFC 3798, May 2004.
+
+
+
+
+Harding & Scott              Informational                     [Page 34]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+   [7]   Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security
+         Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
+         RFC 1847, October 1995.
+
+   [8]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
+         2001.
+
+   [9]   Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
+         July 2004.
+
+   [10]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
+         (S/MIME) Version 3.1 Message Specification", RFC 3851, July
+         2004.
+
+   [11]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
+         (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July
+         2004.
+
+   [12]  Vaudreuil, G., "The Multipart/Report Content Type for the
+         Reporting of Mail System Administrative Messages", RFC 3462,
+         January 2003.
+
+   [13]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+         2246, January 1999.
+
+   [14]  Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT
+         MESSAGES", STD 11, RFC 822, August 1982.
+
+   [15]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.
+
+   [16]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
+         RFC 3023, January 2001.
+
+   [17]  Gutmann, P., "Compressed Data Content Type for Cryptographic
+         Message Syntax (CMS)", RFC 3274, June 2002.
+
+   [18]  Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, October
+         2005.
+
+   [19]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+Harding & Scott              Informational                     [Page 35]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+10.2.  Informative References
+
+   [20]  Harding, T., "Compressed Data for EDIINT", Work in Progress,
+         January 2007.
+
+   [21]  Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L.
+         Repka, "S/MIME Version 2 Message Specification", RFC 2311,
+         March 1998.
+
+   [22]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+         Specifications: ABNF", RFC 4234, October 2005.
+
+   [23]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
+         Protocol Version 1.1", RFC 4346, April 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harding & Scott              Informational                     [Page 36]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+Appendix 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"
+   Message-Id: <200207310834482A70BF63@host.com>
+   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
+   AS3-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
+
+
+
+
+Harding & Scott              Informational                     [Page 37]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+   & 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@host.com>
+   &  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
+   &
+   &   Reporting-UA: AS3 Server
+   &   Original-Recipient: rfc822; "trading partner"
+   &   Final-Recipient: rfc822; "trading partner"
+   &   Original-Message-ID: <200207310834482A70BF63@host.com>
+   &   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 "&" are what the signature is
+         calculated over.
+
+      2. For details on how to prepare the multipart/signed with
+         protocol="application/pkcs7-signature", see RFC 3851 [10],
+         "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version
+         3.1 Message Specification".
+
+
+
+Harding & Scott              Informational                     [Page 38]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+      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 3462 [12], 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.
+
+Authors' Addresses
+
+   Terry Harding
+   Axway
+   8388 E. Hartford Drive, Suite 100
+   Scottsdale, AZ  85255 USA
+
+   EMail: tharding@us.axway.com
+
+
+   Richard Scott
+   Axway
+   8388 E. Hartford Drive, Suite 100
+   Scottsdale, AZ  85255 USA
+
+   EMail: rscott@us.axway.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harding & Scott              Informational                     [Page 39]
+
+RFC 4823            AS3 Data Interchange for EDIINT           April 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Harding & Scott              Informational                     [Page 40]
+