RFC 4130

MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)

📅 published July 2005, from ietf

RFC 4130 💌 Network Working Group

Okay bestie, this is RFC 4130 and it's giving Standards Track ✨ It was published in July 2005 by the Network Working Group. The authors are D. Moberg from Cyclone Commerce and R. Drummond from Drummond Group Inc. 💅

MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)

Status of This Memo 🌸

So this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 If you want to know where this protocol stands on the standardization ladder, check the current edition of the "Internet Official Protocol Standards" (STD 1). The distribution of this memo is unlimited, so share away 🦋

Copyright (C) The Internet Society (2005). Obsessed with the paperwork being this clean 💜

Abstract 🔮

Okay so this is the part where it explains the vibe. This doc is an applicability statement (RFC 2026, Section 3.2) about exchanging structured business data securely over the HTTP transfer protocol instead of SMTP. The SMTP version lives in RFC 3335 🍓

The structured business data can be XML, Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format, or other structured data formats. The data gets packaged in standard MIME structures 📦

For authentication and data confidentiality, it uses Cryptographic Message Syntax with S/MIME security body parts 🔐 And the authenticated acknowledgements are multipart/signed Message Disposition Notification (MDN) responses sent back to the original HTTP message 💅

It's informally called "AS2" because it's the second applicability statement, right after "AS1", which is RFC 3335. Iconic naming, no notes 👑

Table of Contents 📑

   1. Introduction ....................................................3
      1.1. Applicable RFCs ............................................3
      1.2. Terms ......................................................3
   2. Overview ........................................................5
      2.1. Overall Operation ..........................................5
      2.2. Purpose of a Security Guideline for MIME EDI ...............5
      2.3. Definitions ................................................5
      2.4. Assumptions ................................................7
   3. Referenced RFCs and Their Contributions .........................9
      3.1. RFC 2616 HTTP v1.1 [3] .....................................9
      3.2. RFC 1847 MIME Security Multiparts [6] ......................9
      3.3. RFC 3462 Multipart/Report [8] .............................10
      3.4. RFC 1767 EDI Content [2] ..................................10
      3.5. RFC 2045, 2046, and 2049 MIME [1] .........................10
      3.6. RFC 3798 Message Disposition Notification [5] .............10
      3.7. RFC 3851 and 3852 S/MIME Version 3.1 Message
           Specifications and Cryptographic Message Syntax (CMS) [7]..10
      3.8. RFC 3023 XML Media Types [10] .............................10
   4. Structure of an AS2 Message ....................................10
      4.1. Introduction ..............................................10
      4.2. Structure of an Internet EDI MIME Message .................11
   5. HTTP Considerations ............................................12
      5.1. Sending EDI in HTTP POST Requests .........................12
      5.2. Unused MIME Headers and Operations ........................12
      5.3. Modification of MIME or Other Headers or Parameters Used ..13
      5.4. HTTP Response Status Codes ................................14
      5.5. HTTP Error Recovery .......................................14
   6. Additional AS2-Specific HTTP Headers ...........................14
      6.1. AS2 Version Header ........................................15
      6.2. AS2 System Identifiers ....................................15
   7. Structure and Processing of an MDN Message .....................17
      7.1. Introduction ..............................................17
      7.2. Synchronous and Asynchronous MDNs .........................19
      7.3. Requesting a Signed Receipt ...............................21
      7.4. MDN Format and Values .....................................25
      7.5. Disposition Mode, Type, and Modifier ......................30
      7.6. Receipt Reply Considerations in an HTTP POST ..............35
   8. Public Key Certificate Handling ................................35
   9. Security Considerations ........................................36
      9.1. NRR Cautions ..............................................37
      9.2. HTTPS Remark ..............................................38
      9.3. Replay Remark .............................................39
   10. IANA Considerations ...........................................39
       10.1. Registration ............................................39
   11. Acknowledgements ..............................................40
   12. References ....................................................40

       12.1. Normative References ....................................40
       12.2. Informative References ..................................41
   Appendix A: Message Examples ......................................42

1. Introduction ✨

1.1. Applicable RFCs 🧚

Okay so previous Internet EDI work was all about specifying MIME content types for EDI data [2], and then extending that to support secure EC/EDI transport over SMTP [4]. This document builds on RFC 1767 and adds a whole comprehensive set of data security features over HTTP: data confidentiality, data integrity/authenticity, non-repudiation of origin, and non-repudiation of receipt 🔥 It also vibes with the contemporary RFCs and tries really hard not to "re-invent" anything unnecessarily 🫶 Even though the focus is EDI data, any other data type you can describe in a MIME format is supported too 🌈

To do Internet MIME-based EDI, you use and comply with these RFCs:

The goal here is to define clearly and precisely how these all work together, and what user agents are required to do to be compliant 💅

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 [13] 🎀

1.2. Terms 📖

Okay so here's the glossary, bestie 🍓

  • AS2: Applicability Statement 2 (this document); see RFC 2026 [11], Section 3.2
  • EDI: Electronic Data Interchange
  • EC: Business-to-Business Electronic Commerce
  • B2B: Business to Business
  • Receipt: The functional message that a receiver sends to a sender to acknowledge receipt of an EDI/EC interchange. It can be synchronous or asynchronous in nature 💌
  • Signed Receipt: A receipt with a digital signature ✍️
  • Synchronous Receipt: A receipt returned to the sender during the same HTTP session as the sender's original message ⚡
  • Asynchronous Receipt: A receipt returned to the sender on a different communication session than the sender's original message session 🌙
  • Message Disposition Notification (MDN): The Internet messaging format used to convey a receipt. This term is used interchangeably with receipt, so an MDN is a receipt 💜
  • Non-repudiation of receipt (NRR): A "legal event" that happens when the original sender of a signed EDI/EC interchange has verified the signed receipt coming back from the receiver. The receipt has data identifying the original message it's a receipt for, including the message-ID and a cryptographic hash (MIC). The original sender must keep suitable records about the message content, its message-ID, and its hash value. The sender checks that the retained hash value matches the digest of the original message, as reported in the signed receipt. NRR isn't treated as a technical message. It's more of an outcome of having the relevant evidence 🧾 💀
  • S/MIME: A format and protocol for adding cryptographic signature and/or encryption services to Internet MIME messages 🔐
  • Cryptographic Message Syntax (CMS): An encapsulation syntax used to digitally sign, digest, authenticate, or encrypt arbitrary messages 🦋
  • SHA-1: A secure, one-way hash algorithm used alongside a digital signature. This is the recommended algorithm for AS2 👑
  • MD5: A secure, one-way hash algorithm used alongside a digital signature. This algorithm is allowed in AS2 ✨
  • MIC: The message integrity check (MIC), also called the message digest, is the digest output of the hash algorithm used by the digital signature. The digital signature is computed over the MIC 🌸
  • User Agent (UA): The application that handles and processes the AS2 request 🤖

2. Overview 🌈

2.1. Overall Operation 🚀

So an HTTP POST operation [3] sends appropriately packaged EDI, XML, or other business data 📮 The Request-URI ([3], Section 9.5) points to a process that unpacks and handles the message data, then generates a reply for the client containing a message disposition acknowledgement (MDN), either signed or unsigned 🫶 The MDN either comes back in the HTTP response message body, or in a new HTTP POST operation sent to a URL for the original sender 💖

This request/reply transactional exchange can provide secure, reliable, and authenticated transport for EDI or other business data over HTTP. It's giving reliable delivery energy 🔥

The security protocols and structures used also support auditable records of these data transmissions, acknowledgements, and authentication 🧾 Receipts for days 😭

2.2. Purpose of a Security Guideline for MIME EDI 🎀

The point of these specifications is to make sure B2B EC user agents can interoperate, while invoking some or all of the commonly expected security features 💅 This document is also NOT limited to strict EDI use. It applies to any electronic commerce application where business data needs to be exchanged securely over the Internet 🌍

2.3. Definitions 📚

2.3.1. The Secure Transmission Loop

okay bestie, this is the main event 🦋 this doc is all about how EDI/EC content gets exchanged securely over HTTP on the Internet 🌐✨

In the "secure transmission loop" for EDI/EC, one organization sends a signed and encrypted EDI/EC interchange to another organization and asks for a signed receipt 💌 Later, the receiving organization sends that signed receipt back to the sender. So the whole thing goes like this:

  • The organization sending EDI/EC data signs and encrypts the data using S/MIME 🔐 The message also asks for a signed receipt to be sent back to the sender. To support NRR, the original sender keeps records of the message, the message-ID, and the digest (MIC) value 📝
  • The receiving organization decrypts the message and verifies the signature. That gives verified integrity of the data and authenticity of the sender 🫶
  • The receiving organization then sends back a signed receipt, either in the HTTP reply body or in a separate HTTP POST operation, to the sending organization as a signed message disposition notification 💅 This signed receipt contains the hash of the received message, so the original sender has evidence that the message was authenticated and/or decrypted properly by the receiver 🌸

The stuff above is the functionality that, if it gets implemented, will satisfy all security requirements and implement non-repudiation of receipt for the exchange ✨ This spec, though, leaves full flexibility for users to decide how much of those security features they want to deploy with their trading partners 🎀

2.3.2. Definition of Receipts

Okay so the word for both the activity and the message that acknowledges delivery of an EDI/EC interchange is "receipt" or "signed receipt" 💜 The first term is used if the acknowledgment is for an interchange that results in a receipt that is NOT signed. The second term is used if the acknowledgement is for an interchange that results in a receipt that IS signed.

The term non-repudiation of receipt (NRR) gets used a lot together with receipts 👀 NRR is a legal event that happens only when the original sender of an interchange has verified the signed receipt coming back from the recipient of the message, and has verified that the returned MIC value inside the MDN matches the value that was recorded earlier for the original message 🧾

NRR is best established when both the original message and the receipt use digital signatures 🔏 Check the Security Considerations section for some cautions about NRR ⚠️

For info on how to format and process receipts in AS2, refer to Section 7 📖

2.4. Assumptions

2.4.1. EDI/EC Process Assumptions

  • Encrypted object is an EDI/EC Interchange.

This spec assumes that a typical EDI/EC interchange is the lowest-level object that gets security services applied to it 🧩

Specifically, in EDI ANSI X12, that means anything between and including the ISA and IEA segments is secured. In EDIFACT, that means anything between and including the UNA/UNB and UNZ segments is secured. In other words, the EDI/EC interchanges, envelope segments included, stay intact and unreadable during fully secured transport 🔒✨

  • EDI envelope headers are encrypted.

Congruent with the above statement, EDI envelope headers are NOT visible in the MIME package 🙈

To optimize routing from existing commercial EDI networks (called Value Added Networks or VANs) to the Internet, it would be useful to make some envelope information visible. This spec, though, provides no support for this optimization 🤷‍♀️

  • X12.58 and UN/EDIFACT Security Considerations

The most common EDI standards bodies, ANSI X12 and EDIFACT, have defined their own 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 with this specification, though possibly redundant 💖

2.4.2. Flexibility Assumptions

Encrypted or Unencrypted Data

This spec allows for EDI/EC message exchange in which the EDI/EC data can be either unprotected or protected by means of encryption 🎀

Signed or Unsigned Data

This spec allows for EDI/EC message exchange with or without a digital signature on the original EDI transmission ✍️

Optional Use of Receipt

This spec allows for EDI/EC message transmission with or without a request for receipt notification. A signed receipt notification is requested; however, a MIC value is REQUIRED as part of the returned receipt, except when a severe error condition prevents computation of the digest value. In the exceptional case, a signed receipt should be returned with an error message that effectively explains why the MIC is absent 🥺

Use of Synchronous or Asynchronous Receipts

On top of a receipt request, this spec lets you specify the type of receipt that should come back. It supports synchronous or asynchronous receipts in the MDN format specified in Section 7 of this document ⏱️

Security Formatting

This spec relies on the guidelines set forth in RFC 3851/3852 [7] "S/MIME Version 3.1 Message Specification; Cryptographic Message Syntax" 📚

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, and that both MD5 and SHA-1 be supported for incoming messages 🔑

Permutation Summary

Okay here's the fun part: the twelve security permutations possible in any given trading relationship 💅

  1. Sender sends un-encrypted data and does NOT request a receipt.
  2. Sender sends un-encrypted data and requests an unsigned receipt. Receiver sends back the unsigned receipt.
  3. Sender sends un-encrypted data and requests a signed receipt. Receiver sends back the signed receipt.
  4. Sender sends encrypted data and does NOT request a receipt.
  5. Sender sends encrypted data and requests an unsigned receipt. Receiver sends back the unsigned receipt.
  6. Sender sends encrypted data and requests a signed receipt. Receiver sends back the signed receipt.
  7. Sender sends signed data and does NOT request a signed or unsigned receipt.
  8. Sender sends signed data and requests an unsigned receipt. Receiver sends back the unsigned receipt.
  9. Sender sends signed data and requests a signed receipt. Receiver sends back the signed receipt.
  10. Sender sends encrypted and signed data and does NOT request a signed or unsigned receipt.
  11. Sender sends encrypted and signed data and requests an unsigned receipt. Receiver sends back the unsigned receipt.
  12. Sender sends encrypted and signed data and requests a signed receipt. Receiver sends back the signed receipt.

Users can pick any of the twelve, but only the last one (12), where a signed receipt is requested, gives you the whole suite of security features described in Section 2.3.1, "The Secure Transmission Loop" 👑

Also, the receipts above can be either synchronous or asynchronous depending on the type requested. Using synchronous or asynchronous receipts doesn't change the nature of the secure transmission loop that supports NRR 💫

3. Referenced RFCs and Their Contributions

3.1. RFC 2616 HTTP v1.1 [3]

This document specifies how data is transferred using HTTP 🚚

3.2. RFC 1847 MIME Security Multiparts [6]

This document defines security multipart for MIME: multipart/encrypted and multipart/signed 🧁

3.3. RFC 3462 Multipart/Report [8]

This RFC defines the use of the multipart/report content type, which the MDN RFC 3798 builds upon 🌈

3.4. 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.5. RFC 2045, 2046, and 2049 MIME [1]

These are the basic MIME standards that all MIME related RFCs build on, this one included 🧱 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.6. RFC 3798 Message Disposition Notification [5]

This Internet RFC defines how an MDN is requested, plus the format and syntax of the MDN 📬 The MDN is the basis upon which receipts and signed receipts are defined in this spec 💜

3.7. RFC 3851 and 3852 S/MIME Version 3.1 Message Specifications and Cryptographic Message Syntax (CMS) [7]

This spec describes how S/MIME will carry CMS Objects 🎁

3.8. RFC 3023 XML Media Types [10]

This RFC defines the use of content type "application" for XML (application/xml) 🧡

4. Structure of an AS2 Message ✨

4.1. Introduction

The basic structure of an AS2 message is MIME format inside an HTTP message, with a few extra AS2-specific headers 💌 The structures below are described hierarchically, in terms of which RFCs get applied to form each specific structure. For details on how to code in compliance with all the RFCs involved, go straight to the RFCs referenced 📚 Any difference between AS2 implantations and the RFCs gets mentioned specifically in the sections below 🙈

4.2. Structure of an Internet EDI MIME Message

Okay, these diagrams are literally the whole structure, so let's look at them all together 🦋

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

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

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

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

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

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

   MDN over SMTP, no signature
   MDN over SMTP, signature
     Refer to the EDI over SMTP standard [4].

Although 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. HTTP Considerations 🌷

5.1. Sending EDI in HTTP POST Requests 📮

okay bestie, let's talk about how you actually send EDI over HTTP 💌 The request line is going to look like POST Request-URI HTTP/1.1 (with spaces, and then a CRLF to end it) 💅 The Request-URI usually gets swapped out of band, like when you're setting up a bilateral trading partner agreement 🤝 Applications SHOULD be prepared to deal with an initial reply that says you need authentication, the usual kinds used for authorizing access to the Request-URI ([3], Section 10.4.2 and elsewhere) 🔐

After the request line come the entity headers: content length ([3], Section 14.14) and content type ([3], Section 14.18) 🎀 The Host request header ([3], Sections 9 and 14.23) is included too ✨

When you're using Transport Layer Security [15] or SSLv3, the request-URI SHOULD indicate the appropriate scheme value, HTTPS 🔒 Usually only a multipart/signed message body gets sent over TLS, since encrypted bodies would be redundant 🙄 But encrypted message bodies are not prohibited, so you're not breaking any rules 💜

The receiving AS2 system MAY disconnect from the sending AS2 system before finishing the whole entity if it decides the entity is too large to process 😬

For HTTP version 1.1, TCP persistent connections are the default ([3] Sections 8.1.2, 8.2, and 19.7.1) 🦋 There are a bunch of other differences because HTTP doesn't conform to MIME [1] as used in SMTP transport, so here are the relevant ones, summarized below 👇

5.2. Unused MIME Headers and Operations 🧹

5.2.1. Content-Transfer-Encoding Not Used in HTTP Transport 🧚

HTTP can handle binary data, so there's no need for the content transfer encodings of MIME [1] 🙌 This difference is discussed in [3], Section 19.4.5 💅 A content transfer encoding value of binary or 8-bit is permissible but not required, so you can use it, but you don't have to 🌸 The absence of this header MUST NOT result in transaction failure 🙅 (phew!) Content transfer encoding of MIME bodyparts within the AS2 message body is also allowed 🎀

5.2.2. Message Bodies 📝

In [3], Section 3.7.2, it's explicitly noted that multiparts MUST have null epilogues 💖

In [4], 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, in [3], Sections 3.5 and 3.6, there are some options for compressing or chunking entities to be transferred 📦 And in [3], Section 8.1.2.2, there's a pipelining option that's useful for segmenting large amounts of data 🧩

5.3. Modification of MIME or Other Headers or Parameters Used ✏️

5.3.1. Content-Length 📏

The use of the content-length header MUST follow the guidelines of [3], specifically Sections 4.4 and 14.13 💫

5.3.2. Final Recipient and Original Recipient 👯

The final and original recipient values SHOULD be the same value 💕 These values MUST NOT be aliases or mailing lists 🚫📬

5.3.3. Message-Id and Original-Message-Id 🆔

Message-Id and Original-Message-Id are formatted as defined in RFC 2822 [9]:

"<" id-left "@" id-right ">"        (RFC 2822, 3.6.4)

Message-Id length is a maximum of 998 characters 📏 For maximum backward compatibility, Message-Id length SHOULD be 255 characters or less 🫶 Message-Id SHOULD be globally unique, and 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 🤓 For maximum backward compatibility, when receiving a message, do not check for angle brackets 🙈 When creating the Original-Message-Id header in an MDN, always use the exact syntax as received on the original message; don't strip or add angle brackets 💅

bestie, the Original-Message-Id rule is the one to remember 😭 Copy it exactly as it came in, brackets and all!

5.3.4. Host Header 📮

The host request header field MUST be included in the POST request made when sending business data 📬 This field is intended to allow one server IP address to service multiple hostnames, and potentially to conserve IP addresses 🧠 See [3], Sections 14.23 and 19.5.1 ✨

5.4. HTTP Response Status Codes 🚦

The status codes return status concerning HTTP operations 📊 For example, the status code 401, together with the WWW-Authenticate header, is used to challenge the client to repeat the request with an Authorization header 🔑 Other explicit status codes are documented in [3], Section 6.1.1 and throughout Section 10 📚

For errors in the request-URI, 400 ("Bad Request"), 404 ("Not Found"), and similar codes are appropriate status codes 🙃 These codes and their semantics are specified by [3] 📖 A careful examination of these codes and their semantics should be made before implementing any retry functionality 🧐 Retries SHOULD NOT be made if the error is not transient or if retries are explicitly discouraged 🛑

5.5. HTTP Error Recovery 🔁

If the HTTP client fails to read the HTTP server response data, the POST operation with identical content, including same Message-ID, SHOULD be repeated, if the condition is transient 🔄

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

Details of the retry process (including time intervals to pause, number of retries to attempt, and timeouts for retrying) are implementation dependent ⏱️ These settings are selected as part of the trading partner agreement 🤝

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 💌

6. Additional AS2-Specific HTTP Headers 🎀

The following headers are to be included in all AS2 messages and all AS2 MDNs, except for asynchronous MDNs that are sent using SMTP and that follow the AS1 semantics[4] 🌈

6.1. AS2 Version Header 🏷️

To promote backward compatibility, AS2 includes a version header 💜

AS2-Version: 1.0  - Used in all implementations of this
                    specification.  1.x will be interpreted as 1.0 by
                    all implementations with the "AS2 Version: 1.0"
                    header.  That is, only the most significant digit
                    is used as the version identifier for those not
                    implementing additional non-AS2-specified
                    functionality. "AS2-Version: 1.0 through 1.9" MAY
                    be used.  All implementations MUST interpret "1.0
                    through 1.9" as implementing this specification.
                    However, an implementation MAY extend this
                    specification with additional functionality by
                    specifying versions 1.1 through 1.9.  If this
                    mechanism is used, the additional functionality
                    MUST be completely transparent to implementations
                    with the "AS2-Version:  1.0" designation.

AS2-Version: 1.1  - Designates those implementations that support
                    compression as defined by RFC 3274.

Receiving systems MUST NOT fail due to the absence of the AS2-Version header 🙏 Its absence would indicate that the message is from an implementation based on a previous version of this specification 🕰️

6.2. AS2 System Identifiers 🪪

To aid the receiving system in identifying the sending system, AS2-From and AS2-To headers are used 🔍

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

These AS2 headers contain textual values, as described below, identifying the sender/receiver of a data exchange 💬 Their values may be company specific, such as Data Universal Numbering System (DUNS) numbers, or they may be simply identification strings agreed upon between the trading partners 🏢

AS2-text = "!" /           ; printable ASCII characters
           %d35-91 /       ; except double-quote (%d34)
           %d93-126        ; or backslash (%d92)

AS2-qtext = AS2-text / SP  ; allow space only in quoted text

AS2-quoted-pair = "\" DQUOTE /  ; \" or
                  "\" "\"       ; \\

AS2-quoted-name = DQUOTE 1*128( AS2-qtext /
                                AS2-quoted-pair) DQUOTE

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

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

The AS2-From header value and the AS2-To header value MUST each be an AS2-name, MUST each be comprised of from 1 to 128 printable ASCII characters, and MUST NOT be folded 📏 The value in each of these headers is case-sensitive 🔠 The string definitions given above are in ABNF format [14] 🧾

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

The AS2-To and AS2-From header fields MUST be present in all AS2 messages and AS2 MDNs, whether asynchronous or synchronous in nature, except for asynchronous MDNs, which are sent using SMTP 📬

The AS2-name for the AS2-To header in a response or MDN MUST match the AS2-name of the AS2-From header in the corresponding request message 🪞 Likewise, the AS2-name for the AS2-From header in a response or MDN MUST match the AS2-name of the AS2-To header in the corresponding AS2 request message 🪞

The sending system may choose to limit the possible AS2-To/AS2-From textual values but MUST not exceed them 🚧 The receiving system MUST make no restrictions on the textual values and SHOULD handle all possible implementations 🌟 However, implementers must be aware that older AS2 products may not adhere to this convention 🕵️ Trading partner agreements should be made to ensure that older products can support the system identifiers that are used 🤝

There is no required response to a client request containing invalid or unknown AS2-From or AS2-To header values 🤷 The receiving AS2 system MAY return an unsigned MDN with an explanation of the error, if the sending system requested an MDN 💌

7. Structure and Processing of an MDN Message 💅

7.1. Introduction ✨

okay bestie, so for non-repudiation of receipt the receiving trading partner's UA needs to build a signed receipt 🔏. That's a message disposition notification (the one from RFC 3798) that the receiver digitally signs as part of a multipart/signed MIME message. It's giving legal-proof energy 💅

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 gets sent back to the sender inside the signed receipt 💌.
  3. The ability to create 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 send the signed receipt back to the sending trading partner 🚀.
  5. The ability to return either a synchronous or an asynchronous receipt, whichever the sending party asks for ⏱️.

The signed receipt tells a sending trading partner who asked for it that:

  1. The receiving trading partner acknowledges receipt of the sent EC Interchange 🙌.
  2. If the sent message was signed, the receiving trading partner has authenticated the sender of the EC Interchange 🕵️‍♀️.
  3. If the sent message was signed, 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, the receiving trading partner's UA MUST provide the following basic processing 🧠:

  1. If the sent EDI/EC Interchange is encrypted, the encrypted symmetric key and initialization vector (if applicable) get decrypted using the receiver's private key 🔑.
  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 does 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 received message is calculated using the same one-way hash function that the sending trading partner used 🧁. c. The MIC extracted from the sent message and the MIC calculated with that same one-way hash function 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 in that second part is as follows:
S/MIME: protocol = "application/pkcs-7-signature"
  1. 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 multi-part MIME content-type 🧩. When the EDI Interchange is part of a multi-part MIME content-type, the MIC MUST be calculated across the entire multi-part content, MIME headers included 🫶.

When the sender of the EDI Interchange gets the signed MDN back, it can use it like this 📬:

  • As an acknowledgement that the EDI Interchange was delivered and acknowledged by the receiving trading partner ✅. The receiver does this by returning the original-message-id of the sent message in the MDN portion of the signed receipt.
  • As an acknowledgement that the receiving trading partner verified the integrity of the EDI Interchange 🛡️. 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.
  • As an acknowledgement that the receiving trading partner has authenticated the sender of the EDI Interchange 🤝.
  • As 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. Synchronous and Asynchronous MDNs

The AS2-MDN comes in two flavours: synchronous and asynchronous 🌸.

The synchronous AS2-MDN is sent as an HTTP response to an HTTP POST, or as an HTTPS response to an HTTPS POST 🦋. It's called synchronous because the AS2-MDN goes back to the originator of the POST on the same TCP/IP connection 🔗.

The asynchronous AS2-MDN is sent on a separate HTTP, HTTPS, or SMTP TCP/IP connection 🧚. Logically, the asynchronous AS2-MDN is a response to an AS2 message. But at the transfer-protocol layer, assuming no HTTP pipelining is used, the asynchronous AS2-MDN gets delivered on a unique TCP/IP connection, separate from the one that carried the original AS2 message 🎀. When handling an asynchronous request, the HTTP response MUST be sent back before the MDN is processed and sent on the separate connection 🏃‍♀️.

When the sender of an AS2 message asks for an asynchronous AS2-MDN, the synchronous HTTP or HTTPS response returned to the sender before the connection closes MUST be a transfer-layer response that says whether the data transfer succeeded or failed 📦. The format of that synchronous response MAY be the same as the response returned when no AS2-MDN is requested 🍓.

Here's the diagram showing synchronous vs asynchronous AS2-MDN delivery over HTTP 🖼️:

Synchronous AS2-MDN

[Peer1] ----( connect )----> [Peer2]
[Peer1] -----( send )------> [Peer2]   [HTTP Request [AS2-Message]]
[Peer1] <---( receive )----- [Peer2]   [HTTP Response [AS2-MDN]]

Asynchronous AS2-MDN

[Peer1] ----( connect )----> [Peer2]
[Peer1] -----( send )------> [Peer2]   [HTTP Request [AS2-Message]]
[Peer1] <---( receive )----- [Peer2]   [HTTP Response]

[Peer1]*<---( connect )----- [Peer2]
[Peer1] <--- ( send )------- [Peer2]   [HTTP Request [AS2-MDN]]
[Peer1] ----( receive )----> [Peer2]   [HTTP Response]
* Note: An AS2-MDN may be directed to a host different from that of
the sender of the AS2 message.  It may utilize a transfer protocol
different from that used to send the original AS2 message.

The big advantage of the synchronous MDN is that it gives the sender of the AS2 Message a verifiable confirmation of delivery within one synchronous flow 💖. But if the message is pretty large, processing it and sending the AS2-MDN back on the same TCP/IP connection might take longer than the maximum time an IP connection is allowed to stay open 😭.

The asynchronous MDN is the glow-up for big messages 💅. It lets the receiver send a quick transfer-layer response confirming the data arrived, so the TCP/IP connection doesn't have to stay open for very long ✨. The catch is that the asynchronous AS2-MDN has to carry enough information to identify the original message uniquely 🔎. That way, when the AS2 Message originator gets it, the status of the original AS2 Message can be updated properly based on what the AS2-MDN says 🧾.

Synchronous or asynchronous HTTP or HTTPS MDNs are handled according to the requirements of this specification 🫧.

However, SMTP MDNs are formatted according to the requirements of RFC 3335 [4] 📮.

7.3. Requesting a Signed Receipt ✨

okay so message disposition notifications (MDNs 📬) get requested the way RFC 3798 says 💅. To ask the receiving user agent to send one, you slap this header onto the message you're sending:

MDN-request-header = "Disposition-notification-to"
                    ":"  mail-address

Here's an example of asking for one:

Disposition-notification-to: xxx@example.com

ngl this is a leftover from when MDNs went over SMTP 🙈. This spec is moving things from SMTP over to HTTP and keeping as much of the [4] functionality as it can, so the mail-address MUST be present. The mail-address field is written as an RFC 2822 localpart@domain [addr-spec] address. BUT the address isn't actually used to figure out where the MDN goes back to 🙃. Receiving applications MUST ignore the value and MUST not complain about RFC 2822 address syntax violations. not me going "why is this even here" 😭

When you're requesting MDN-based receipts, the originator adds some extra extension headers that come before the message body. These header "tags" are:

A Message-ID header gets added so message reconciliation can happen, which means an Original-Message-Id value can come back in the body part of the MDN 🎀. Other headers, especially "Subject" and "Date", SHOULD be supplied, since their values often get mentioned in the human-readable section of an MDN to help identify the original message 🧚.

MDNs come back in the HTTP response when that's what's requested, unless an asynchronous return is asked for.

To request an asynchronous message disposition notification, you put this header in the message you send:

Receipt-Delivery-Option: return-URL

Here's an example asking for the MDN to be asynchronous:

Receipt-Delivery-Option: http://www.example.com/Path

Receipt-delivery-option syntax lets return-url use some schemes other than HTTP, as long as they use the POST method 🦋.

The "receipt-delivery-option: return-url" string tells you the URL to use for an asynchronous MDN. This header is NOT present if the receipt is to be synchronous 🫶. The email value in Disposition-notification-to isn't used in this spec because it was limited to RFC 2822 addresses, so the extension header "Receipt-delivery-option" was introduced to give a URL for the MDN return across several transfer options. main character energy 👑

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

An example request for an asynchronous MDN via an HTTP transport:

Receipt-delivery-option: http://www.example.com

An example request for an asynchronous MDN via an HTTP/S transport:

Receipt-delivery-option: https://www.example.com

An example request for an asynchronous MDN via an SMTP transport:

Receipt-delivery-option: mailto:as2@example.com

For more info on requesting SMTP MDNs, refer to RFC 3335 [4] 📚.

Finally, there's the header Disposition-notification-options, which identifies the characteristics of the message disposition notification as in [5]. The most important of these is the signing options for the MDN, like this example:

Disposition-notification-options:
     signed-receipt-protocol=optional,pkcs7-signature;
     signed-receipt-micalg=optional,sha1,md5

For signing options, here's the syntax for disposition-notification-options:

Disposition-notification-options =
         "Disposition-Notification-Options" ":"
          disposition-notification-parameters

where
     disposition-notification-parameters =
                       parameter *(";" parameter)

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

where
     importance = "required" | "optional"

So the Disposition-notification-options string could be:

signed-receipt-protocol=optional,<protocol symbol>;
signed-receipt-micalg=optional,<micalg1>,<micalg2>,...;

The currently used 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
---------    -------
 SHA-1        sha1
 MD5          md5

The semantics of the "signed-receipt-protocol" and "signed-receipt-micalg" parameters go like this:

  1. The "signed-receipt-protocol" parameter is used to request a signed receipt from the recipient trading partner. It also specifies the format the signed receipt SHOULD be returned in to the requester.

The "signed-receipt-micalg" parameter is a list of MIC algorithms the requester prefers for signing the returned receipt. 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.

The lack of the presence of the "Receipt-Delivery-Option" means a receipt is synchronous in nature. The presence of "Receipt-Delivery-Option: return-url" means an asynchronous receipt is requested and SHOULD be sent to the "return-url".

  1. The "importance" attribute of "Optional" is defined in RFC 3798, Section 2.2, and has the following meaning:

Parameters with an importance of "Optional" let a UA that doesn't understand the particular options parameter still generate an MDN in response to a request for a MDN.

A UA that doesn't understand the "signed-receipt-protocol" parameter or the "signed-receipt-micalg" 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 couldn't sign it.

The returned MDN will contain info on the disposition of the message and on why the MDN couldn't be signed. See the Disposition field in Section 7.5 for more details.

Within an EDI trading relationship, if a signed receipt is expected and isn't returned, then it's up to the trading partners to sort out whether the transaction is valid.

In general, if a signed receipt is required in the trading relationship and isn't received, the transaction will likely not be considered valid 💀.

7.3.1. Signed Receipt Considerations ✨

The method for requesting a receipt or a signed receipt is defined in RFC 3798, "An Extensible Message Format for Message Disposition Notifications" 🎀.

The "rules" are:

  1. When a receipt is requested and it explicitly specifies that the receipt be signed, then the receipt MUST be returned with a signature.
  2. When a receipt is requested and it explicitly specifies that the receipt be signed, but the recipient can't support either the requested protocol format or the requested MIC algorithms, then either a signed or unsigned receipt SHOULD be returned.
  3. When a signature isn't explicitly requested, or if the signed receipt request parameter isn't recognized by the UA, then no receipt, an unsigned receipt, or a signed receipt MAY be returned by the recipient.

NOTE: For Internet EDI, it is RECOMMENDED that when a signature isn't explicitly requested, or if parameters aren't recognized, the UA sends back, at a minimum, an unsigned receipt. If, however, a signed receipt was always returned as a policy, whether requested or not, then any false unsigned receipts can be repudiated 🧾.

When a request for a signed receipt is made but there's an error processing the contents of the message, a signed receipt MUST still be returned. The request for a signed receipt SHALL still be honored, though the transaction itself may not be valid. The reason why the contents couldn't be processed MUST be set in the "disposition-field" 😭.

When a signed receipt request is made, the "Received-content-MIC" MUST always be returned to the requester (except when corruption prevents computing the digest in accordance with the following specification). The "Received-content-MIC" MUST be calculated as follows:

  • For any signed messages, the MIC to be returned is calculated on the RFC1767/RFC3023 MIME header and content. Canonicalization on the MIME headers 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/RFC3023 MIME header and content. The content after decryption MUST be canonicalized before the MIC is calculated.
  • For unsigned, unencrypted messages, the MIC MUST be calculated over the message contents without the MIME or any other RFC 2822 headers, since these are sometimes altered or reordered by Mail Transport Agents (MTAs) 🙈.

7.4. MDN Format and Values 💖

This section defines the format of the AS2 Message Disposition Notification (AS2-MDN) 📋.

7.4.1. AS2-MDN General Formats 🌈

The AS2-MDN follows the MDN specification [5] except where noted in this section. The modified ABNF definitions in this document use the vertical-bar character, '|', to mean a logical "OR" construction. This usage follows RFC 2616 [3]. HTTP entities referred to below aren't further defined in this document, so refer to RFC 2616 [3] for complete definitions of HTTP entities. The format of the AS2-MDN is:

AS2-MDN = AS2-sync-MDN | AS2-async-http-MDN |
    AS2-async-smtp-MDN

AS2-sync-MDN =
    Status-Line
    *(( general-header | response-header | entity-header )
    CRLF )
    CRLF
    AS2-MDN-body

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

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

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

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

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

7.4.2. AS2-MDN Construction ✨

okay so the AS2-MDN-body is formatted as a MIME multipart/report with a report-type of "disposition-notification" 💅 when the message is unsigned, the transfer-layer ("outermost") entity-headers hold a content-type header saying "multipart/report", plus parameters for the report-type and the value of the outermost multipart boundary 🎀

when the AS2-MDN is signed, the outermost entity-headers get a content-type of "multipart/signed" 🔐 with parameters for 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 multipart/signed message is an embedded MIME multipart/report of type "disposition-notification", and the second part is a MIME application/pkcs7-signature message 🦋

the first part of the MIME multipart/report is the "human-readable" bit, which gives a general description of the message disposition 🌸 the second part is the "machine-readable" bit, defined as:

AS2-disposition-notification-content =
    [ reporting-ua-field CRLF ]
    [ mdn-gateway-field CRLF ]
    final-recipient-field CRLF
    [ original-message-id-field CRLF ]
    AS2-disposition-field CRLF
    *( failure-field CRLF )
    *( error-field CRLF )
    *( warning-field CRLF )
    *( extension-field CRLF )
    [ AS2-received-content-MIC-field CRLF ]

7.4.3. AS2-MDN Fields 🧚

the rules for building the AS2-disposition-notification content are identical to the disposition-notification-content rules in Section 7 of RFC 3798 [5] 🫶 the two differences are that the RFC 3798 disposition-field got swapped out for the AS2-disposition-field, and the AS2-received-content-MIC field got added. the differences between the RFC 3798 disposition-field and the AS2-disposition-field are described below. wherever this document and RFC 3798 disagree, the entity names got an "AS2-" prefix. entities that don't differ from RFC 3798 aren't necessarily defined again here, so go check RFC 3798, Section 7, "Collected Grammar" for the original grammar 📖

AS2-disposition-field =
    "Disposition" ":" disposition-mode ";"
    AS2-disposition-type [ '/' AS2-disposition-modifier ]

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

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

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

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

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

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

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

AS2-MDN-failure-description = *( TEXT )
AS2-received-content-MIC-field =
    "Received-content-MIC" ":" encoded-message-digest ","
    digest-alg-id CRLF

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

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

"Insufficient-message-security" and "decompression-failed" are brand-new error codes 🙈 they aren't mentioned in the AS1 RFC 3335, and they may not be compatible with earlier implementations of AS2. 💀

the "Received-content-MIC" extension field gets set when the integrity of the received message is verified ✅ the MIC is the base64-encoded message-digest computed over the received message with a hash function. this field is required for signed receipts but optional for unsigned receipts. for the details on exactly what content the message digest is computed over, see Section 7.3.1 of this document.

for signed messages, the algorithm used to calculate the MIC MUST be the same as the one used on the message that was signed 🔥 if the message isn't signed, the SHA-1 algorithm SHOULD be used. this field only gets set when the contents of the message are processed successfully. and it's used together with the recipient's signature on the MDN, so the sender can verify non-repudiation of receipt. iconic, honestly 👑

AS2-MDN field names (e.g., "Disposition:", "Final-Recipient:") are case insensitive (cf. RFC 3798, Section 3.1.1) 💖 the AS2-MDN action-modes, sending-modes, AS2-disposition-types, and AS2-disposition-modifier values defined above, plus the user-supplied *( TEXT ) values, are case insensitive too. AS2 implementations MUST NOT make assumptions about the values supplied for AS2-MDN-warning-description or AS2-MDN-failure-description, or about the values of any (optional) error, warning, or failure fields. no guessing, bestie 🙅‍♀️

7.4.4. Additional AS2-MDN Programming Notes 💅

  • Unlike SMTP, for HTTP transactions, Original-Recipient and Final-Recipient SHOULD not be different. The value in Original-Message-ID SHOULD match the original Message-ID header value. 🌈
  • Refer to RFC 3798 for the formatting of the MDN, except for the specific deviations mentioned above. 📝
  • Refer to RFC 3462 and RFC 3798 for the formatting of the content-type entity-headers for the MDN. 🎀
  • Use an action-mode of "automatic-action" when the disposition described by the disposition type was a result of an automatic action rather than that of an explicit instruction by the user for this message. 🤖
  • 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. 🧑‍💻
  • Use a sending-mode of "MDN-sent-automatically" when the MDN is sent because the UA had previously been configured to do so. ⭐
  • Use a sending-mode of "MDN-sent-manually" when the user explicitly gave permission for this particular MDN to be sent. 🦋
  • The sending-mode "MDN-sent-manually" is meaningful ONLY with "manual-action", not with "automatic-action". 🙈
  • The "failed" disposition type MUST NOT be used for the situation in which there is some problem in processing the message other than interpreting the request for an MDN. The "processed" or other disposition type with appropriate disposition modifiers is to be used in such situations. 🚫

7.5. Disposition Mode, Type, and Modifier 🌸

7.5.1. Disposition Mode Overview 🧚

this part gives a quick overview of how "processed", "error", "failure", and "warning" get used. think of it as the cheat sheet before the main event 📋

7.5.2. Successful Processing Status Indication ✨

when there's a request for a receipt or signed receipt, and the received message contents are successfully processed by the receiving EDI UA, a receipt or MDN SHOULD be returned with the disposition-type set to "processed" 🎉 when the EDI UA sends the MDN automatically and there's no explicit way for a user to control the sending of it, the first part of the "disposition-mode" SHOULD be set to "automatic-action". when the MDN is being sent under user-configurable control, the first part of the "disposition-mode" SHOULD be set to "manual-action". and 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. no vibes-based exceptions here 🔒

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 the control of a user, administrator, or software.

because 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

quick note: this spec doesn't restrict the "disposition-mode" to just automatic actions 💖 manual actions are valid too, as long as you remember that a request for a signed receipt MUST be honored. 🫶

7.5.3. Unsuccessful Processed Content 💀

the request for a signed receipt needs two "disposition-notification-options", which specify the protocol format of the returned signed receipt and the MIC algorithm used to calculate the MIC over the message contents. the "disposition-field" values to use if the message content is being rejected or ignored MUST be specified in the MDN "disposition-field" like this. (for example, the EDI UA might decide a signed receipt can't be returned because it doesn't support the requested protocol format, so it chooses not to process the message contents itself.)

    Disposition: "disposition-mode";  failed/Failure:
     unsupported format

the "failed" AS2-disposition-type MUST be used when a failure happens that prevents the proper generation of an MDN. for example, this disposition-type would apply if the sender of the message requested an unsupported message-integrity-check (MIC) algorithm. 🙃

the "failure:" AS2-disposition-modifier-extension SHOULD be used with an implementation-defined description of the failure. more info about the failure can go in a failure-field. 🔍

the syntax of the "failed" disposition-type is general, so it allows sending any textual information along with it. implementations MUST support any printable textual characters after the Failure disposition-type. for use in Internet EDI, these "failed" values are pre-defined and MUST be supported:

    "Failure: unsupported format"

    "Failure: unsupported MIC-algorithms"

7.5.4. Unsuccessful Non-Content Processing

Okay bestie, so when something goes wrong while processing the message (and it's not about the content itself 💀), the "disposition-field" MUST be set to the "processed" value for disposition-type and the "error" value for disposition-modifier. ✨

The "error" AS2-disposition-modifier paired with the "processed" disposition-type MUST be used to say that some kind of error happened and stopped the message from being processed successfully. 🚫 More details can go in an error-field, so you can spill the tea there. 🫖

An "error:" AS2-disposition-modifier-extension SHOULD be used to pair the error with a predefined description of a specific, well-known error. Extra info about the error can go in an error field too. 💅

For internet EDI, these "error" AS2-disposition-modifier values are defined:

  • "Error: decryption-failed" → the receiver could not decrypt the message contents. 🔐
  • "Error: authentication-failed" → the receiver could not authenticate the sender. 🕵️‍♀️
  • "Error: integrity-check-failed" → the receiver could not verify content integrity. 🧩
  • "Error: unexpected-processing-error" → a catch-all for any other processing errors. 🗑️

Here's what the "disposition-field" looks like when errors outside of content processing are detected:

    Disposition: "disposition-mode"; processed/Error:
      decryption-failed

7.5.5. Processing Warnings

Situations come up in EDI where trading partners can't be authenticated correctly, but they still agree to keep processing the EDI transactions anyway. 🤝 Transaction reconciliation happens between them later on. In the content processing warning situations described above, the "disposition-field" MUST be set to the "processed" disposition-type value, and the "warning" to the "disposition-modifier" value. ⚠️

The "warning" AS2-disposition-modifier MUST be used with the "processed" disposition-type to show that the message was successfully processed, but that something exceptional happened. 🌈 More information may go in a warning-field.

A "warning:" AS2-disposition-modifier-extension SHOULD be used to pair the warning with an implementation-defined description of it. More info about the warning may be put in a warning-field. 🎀

For use in Internet EDI, this "warning" disposition-modifier-extension value is defined:

"Warning: authentication-failed, processing continued"

Here's how the "disposition-field" looks when warnings outside of content processing are detected:

Example:

    Disposition: "disposition-mode"; processed/Warning:
      authentication-failed, processing continued

7.5.6. Backward Compatibility with Disposition Type, Modifier, and Extension

This next set of examples shows typical Disposition field constructions that AS2 implementations have been using. 🦋 This is not an exhaustive list of every possible construction, but AS2 implementations MUST accept these constructions so they stay backward compatible with earlier AS2 versions. 🫶

   Disposition: automatic-action/MDN-sent-automatically; processed

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

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

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

Next up are the allowable constructions that combine those historic forms with the optional RFC 3798 error, warning, and failure fields. AS2 implementations MAY produce these constructions. 🌸 However, AS2 servers are not required to recognize or process optional error, warning, or failure fields at this time. Also, the multiple error fields in the second example below show how you can indicate more than one error condition at once. 👑

   Disposition: automatic-action/MDN-sent-automatically; processed

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

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

   Disposition: automatic-action/MDN-sent-automatically;
     failed/failure: sender-equals-receiver
   Failure: The AS2-To name is identical to the AS2-From name.

Last, here are allowable constructions that use pure RFC 3798 Disposition-modifiers along with optional error, warning, and failure fields. These are informational only, so treat them as a heads up, not a rule. 🙈 These constructions are not guaranteed to be backward compatible with AS2 implementations before version 1.1. 💀

   Disposition: automatic-action/MDN-sent-automatically; processed

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

   Disposition: automatic-action/MDN-sent-automatically;
     processed/warning
   Warning: duplicate-document
   Disposition: automatic-action/MDN-sent-automatically; failed
   Failure: sender-equals-receiver

7.6. Receipt Reply Considerations in an HTTP POST

The details of the response to the POST command depend on whether a receipt has been requested. 🎟️

If there's no extended header requesting a receipt, and there were no errors accessing the request-URI specified processing, the status line in the Response to the POST request SHOULD be in the 200 range. Status codes in the 200 range SHOULD also be used when an entity is returned (a signed receipt in a multipart/signed content type, or an unsigned receipt in a multipart/report). ✨ Even when the disposition of the data was an error at the authentication, decryption, or other higher level, the HTTP status code SHOULD indicate success at the HTTP level. It's giving "the HTTP layer is fine, the message is the problem" energy. 💅

The HTTP server-side application may respond with an unsolicited multipart/report as a message body that the HTTP client might not have asked for, but the client may discard it. 🗑️ Applications SHOULD avoid sending unsolicited receipt replies, because bandwidth or processing limits might have led admins to stop asking for acknowledgements. 🙏

When Message Disposition Notifications are used in the HTTP reply context, they closely parallel an SMTP MDN. 🦋 For example, the disposition field is a required element in the machine-readable second part of a multipart/report for an MDN. The final-recipient-field ([5], Section 3.1) value SHOULD be derived from the entity headers of the request. 📬

In an MDN, the first part of the multipart/report (the human-readable part) SHOULD include things like the subject, the date, and other info when those fields are present in the entity header fields following the POST request. 📝 An application MUST report the Message-ID of the request in the second part of the multipart/report (the machine-readable part). Also, an MDN SHOULD have its own unique Message-ID HTTP header. 🆔 The HTTP reply SHOULD normally omit the third optional part of the multipart/report (the part used to return the original message or its headers in the SMTP context). 🌷

8. Public Key Certificate Handling 🔐

In the near term, exchanging public keys and certifying them MUST be handled as part of setting up a trading partnership. 🤝 The UA and/or EDI application interface must maintain a database of the public keys used for encryption or signatures, plus the mapping between the EDI trading partner ID and the RFC 2822 [9] email address and HTTP URL/URI. Procedures for establishing a trading partnership and configuring the secure EDI messaging system might vary between 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, so using one is OPTIONAL. Certificates may be self-signed. 🎀

It is RECOMMENDED that when trading partners are using S/MIME, they also exchange public key certificates, considering the advice provided in [12]. 🧚

The message formats useful for certificate exchange are found in [7] and [13]. 📄

In the long term, additional standards may be developed to make it easier to set up a trading partnership. That could include third-party authentication of trading partners, as well as the attributes of the trading relationship. 🌈

9. Security Considerations 🔐

okay bestie, this whole doc is about getting business data from one place to another securely 🔒. That means keeping it private AND proving who actually sent it 🫶

Some stuff was pulled in from RFC 3851 [7]:

40-bit encryption is considered weak by most cryptographers 💀. Using weak crypto in S/MIME gives you basically no more security than sending plaintext in the open 😭. BUT S/MIME also has stuff like Triple DES and a way to announce stronger crypto to the people you talk to, so senders can totally make messages that use strong encryption ✨. Using weak cryptography is never recommended unless the only other option is no cryptography at all. When it's feasible, sending and receiving agents SHOULD tell senders and recipients how strong the crypto in a message is 🔥.

Some stuff was pulled in from RFC 3850 [12]:

there are SO many ways certificate processing can fail 😩, and since it might be a user agent, a security gateway, or some other program doing the work, there's no single way to handle every failure. Just because the methods haven't been listed doesn't mean the failures aren't important, so don't assume they're not 👀. The opposite is true: if a certificate isn't provably valid and attached to the message, the processing software should take immediate and noticeable steps to tell the end user 🚨.

Some of the many situations where signature and certificate checking might fail include the following:

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

There are definitely other ways a certificate can be invalid, and it's the responsibility of the processing software to check them all thoroughly and decide what to do if a check fails. See RFC 3280 for additional information on certificate path validation 📜.

The following are additional security considerations to those listed in [7] and [12] 🧚

9.1. NRR Cautions 🧾

This spec gives you multiple mechanisms that can be combined according to local policies, so you can hit a wide range of security needs based on threat and risk analyses of your business peers 💅. It is required that all these mechanisms be implemented by AS2 software, so the software has capabilities that promote strong interoperability, no matter what policies get adopted 🤝.

One strong cluster of mechanisms (the secure transmission loop) can give good support for the evidence needed for non-repudiation of receipt by the original sender and by a third party supplied with all the stated evidence 🔥. However, this spec doesn't define non-repudiation of receipt itself or list its essential properties, because NRR is a business analysis and/or legal requirement, not something a technical applicability statement can really define 🙈.

Some analyses point out that non-repudiation of receipt assumes non-repudiation of the sender of the original message is already obtained, and that it should be implemented with a digital signature on the original message 🖋️. To satisfy strict NRR evidence, authentication and integrity MUST be provided by some mechanism, and the RECOMMENDED mechanism is digital signatures on both the original message and the receipt message 👑.

Since this spec lets you pick several mechanisms and combine them in several ways, it's important to realize that if a digital signature is left off the original message, some authentication mechanism MUST accompany the request for a signed receipt and its included Received-content-MIC value 😳. That authentication might come from using client-side SSL, authentication via IPsec, or HTTP authentication (while using SSL). In any case, records of the message content, its security basis, and the digest value need to be kept for the NRR process 🗂️.

So if NRR is one of the goals of the policy you adopt, then by using the mechanisms of the secure transmission loop mentioned above and keeping good records of authentication at the original message sender's site, the strong evidentiary requirements proposed for NRR can be fulfilled ✨.

Other ways of doing things may fall short of the most stringent sets of evidence required for NRR, but they can still be part of a commercial trading agreement and, as such, be good enough for the parties involved 🤷‍♀️. However, if MDNs are returned unsigned, the evidentiary requirements for NRR are weak, and some authentication of the receiver's identity is needed 🥺.

9.2. HTTPS Remark 🔒

The following certificate types MUST be supported for SSL server-side certificates:

  • with URL in the Distinguished Name Common Name attribute
  • without URL in the Distinguished Name Common Name attribute
  • self-signed (self-issued)
  • certification authority certified

The URL, which matches the source server identity, SHOULD be carried in the certificate. However, it's not required that DNS checks or reverse lookups vouch for the accuracy of the URL or server value 🔍.

Because server-side certificates are exchanged, and trust is also established during the configuration of the trading partner relationship, runtime checks are not required by implementations of this spec 🙌.

The complete certification chain MUST be included in all certificates. All certificate verifications MUST "chain to root" or to an accepted trust anchor. Additionally, the certificate hash SHOULD match the hash recomputed by the receiver 💅.

9.3. Replay Remark 🔁

Because business data documents normally contain transaction ids, replays (such as resends of not-yet-acknowledged messages) are discarded as part of the normal process of duplicate detection 🧹. Detection of duplicates by Message-Id or by business transaction identifiers is recommended 💜.

10. IANA Considerations 📋

RFC 3335 registered two Disposition-Notification-Options parameters:

Parameter-name: signed-receipt-protocol
Parameter-name: signed-receipt-micalg

and these are also used by this specification (see Section 7.3) ✨.

RFC 3335 also registered an MDN Extension field name:

Extension field name: Received-content-MIC

and that's also used by this specification (see Section 7.4.3) 🎀. Registration of the above is therefore NOT needed 🙅‍♀️.

10.1. Registration 🌸

This specification defines an extension to the Message Disposition Notification (MDN) protocol for a disposition-modifier in the Disposition field of a body of content-type message/disposition-notification 🦋.

10.1.1. Disposition Modifier 'warning' ⚠️

Parameter-name:  warning
Semantics: See Sections 7.4.3 and 7.5.5 of this document.

11. Acknowledgements 🫶

Carl Hage, Karen Rosenfeld, Chuck Fenton, and many others gave valuable suggestions that improved this applicability statement 🌈. The authors would also like to thank the vendors who took part in the Drummond Group Inc. AS2 interoperability testing. Their contributions led to a great improvement in the clarity of this document 👑.

12. References 📚

12.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] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
  • [4] Harding, T., Drummond, R., and C. Shih, "MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet", RFC 3335, September 2002.
  • [5] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
  • [6] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
  • [7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
  • [8] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
  • [9] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
  • [10] Murata, M., Laurent, S. St., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
  • [11] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [12] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
  • [13] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
  • [14] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

12.2. Informative References

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

Appendix A: Message Examples 💌

NOTE: All examples are provided for illustration only, and are not considered part of the protocol specification. If an example conflicts with the protocol definitions specified above or in the other referenced RFCs, the example is wrong 🙈.

A.1. Signed Message Requesting a Signed, Synchronous Receipt ✍️

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

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

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

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

A.2. MDN for Message A.1, Above 🧾✨

okay so this is the receipt that comes back for message A.1 💌 the server replies with a multipart/signed MDN, and the signed part is the & lines 🔏

HTTP/1.0 200 OK
AS2-From: 0123456780000
AS2-To: "\"  as2Name  \""
AS2-Version: 1.1
Message-ID: <709700825.1028122454671.JavaMail@ediXchange>
Content-Type: multipart/signed; micalg=sha1;
     protocol="application/pkcs7-signature";
     boundary="----=_Part_57_648441049.1028122454671"
Connection: Close
Content-Length: 1980

------=_Part_57_648441049.1028122454671

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

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

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

Notes:

  1. The lines starting with & are 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 3462 [8], returning the original or portions of the original message in the third body part of the multipart/report is not required. This is an optional body part. However, it is RECOMMENDED that this body part be omitted or left blank. 🙈

A.3. Signed, Encrypted Message Requesting a Signed, Asynchronous Receipt 🔐🎀

this one is signed AND encrypted, and it asks for a signed receipt that comes back later, asynchronously 🦋 the body is encrypted, so the original bytes are left out here

Message-ID: <#as2_company#01#a4260as2_companyout#>
Date: Thu, 19 Dec 2002 15:04:18 GMT
From: me@example.com
Subject: Async MDN request
Mime-Version: 1.0
Content-Type: application/pkcs7-mime;
  smime-type=enveloped-data; name=smime.p7m
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename=smime.p7m
Recipient-Address: 10.240.1.2//
Disposition-Notification-To:
  http://10.240.1.2:8201/exchange/as2_company
Disposition-Notification-Options: signed-receipt-protocol=optional,
 pkcs7-signature; signed-receipt-micalg=optional,sha1
Receipt-Delivery-Option:
  http://10.240.1.2:8201/exchange/as2_company
AS2-From: as2_company
AS2-To: "AS2 Test"
AS2-Version: 1.1
Host: 10.240.1.2:8101
Connection: close
Content-Length: 3428

  [omitted binary encrypted data]

A.4. Asynchronous MDN for Message A.3, Above 📬💖

and here's the async MDN that answers A.3 🧚 it's a signed multipart message, with the report and the signature in their own parts

POST / HTTP/1.1
Host: 10.240.1.2:8201
Connection: close, TE
TE: trailers, deflate, gzip, compress
User-Agent: RPT-HTTPClient/0.3-3I (Windows 2000)
Date: Thu, 19 Dec 2002 15:03:38 GMT
Message-ID: <AS2-20021219_030338@as2_company.dgi_th>
AS2-Version: 1.1
Mime-Version: 1.0
Recipient-Address:
http://10.240.1.2:8201/exchange/as2_company
AS2-To: as2_company
AS2-From: "AS2 Test"
Subject: Your Requested MDN Response
From: as2debug@example.com
Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress
Content-Type: multipart/signed; micalg=sha1;
  protocol="application/pkcs7-signature";
  boundary="----=_Part_337_6452266.1040310218750"
Content-Length: 3103

------=_Part_337_6452266.1040310218750
Content-Type: multipart/report;
  report-type=disposition-notification;
  boundary="----=_Part_336_6069110.1040310218718"

------=_Part_336_6069110.1040310218718
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The message <x12.edi> sent to Recipient <AS2 Test> on Thu, 19 Dec
2002 15:04:18 GMT with Subject <async MDN request> has been received.
The EDI Interchange was successfully decrypted, and its integrity was
verified.  In addition, the sender of the message, Sender
<as2_company> at Location http://10.240.1.2:8201/exchange/as2_company
was authenticated as the originator of the message.  There is no
guarantee, however, that the EDI interchange was syntactically
correct, or that it was received by the EDI application/translator.

------=_Part_336_6069110.1040310218718
Content-Type: message/disposition-notification
Content-Transfer-Encoding: 7bit

Reporting-UA: AS2@test:8101
Original-Recipient: rfc822; "AS2 Test"
Final-Recipient: rfc822; "AS2 Test"
Original-Message-ID: <#as2_company#01#a4260as2_companyout#>
Disposition: automatic-action/MDN-sent-automatically;
  processed
Received-Content-MIC: Hes6my+vIxIYxmvsA+MNpEOTPAc=, sha1

------=_Part_336_6069110.1040310218718--

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

BhbWjEfbyXoTAS/H0zpnEqLqbaBh29y2v82b8bdeGw8pipBQWmf53hIcqHGM
4ZBF3CHw5Wrf1JIE+8TwOzdbal30zeChw88WfRfD7c/j1fIA8sxsujvf2d9j
UxCUga8BVdVB9kH0Geexytyt0KvWQXfaEEcgZGUAAAAAAAA=

------=_Part_337_6452266.1040310218750-

Authors' Addresses 🌸

the two authors and where to find them 💅

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

EMail: dmoberg@cyclonecommerce.com


Rik Drummond
Drummond Group Inc.
4700 Bryant Irvin Court, Suite 303
Fort Worth, TX  76107 USA

EMail: rvd2@drummondgroup.com

Copyright (C) The Internet Society (2005).

this document is covered by the rights, licenses and restrictions in BCP 78. except as BCP 78 says otherwise, the authors keep all their rights 🫶

The document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 doesn't take a side on whether any IPR claims covering this technology are valid or how far they reach, and it also doesn't say whether licenses for those rights are available. it hasn't independently searched for any such rights either. info on how rights work for RFC documents is in BCP 78 and BCP 79 📖

copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of trying to get a general license or permission to use those rights, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.

the IETF invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard to let it know. send that info to ietf-ipr@ietf.org 💜

Acknowledgement 🎀

funding for the RFC Editor function is currently coming from the Internet Society 🌈

📦 where this page comes from