5.2. Unused MIME Headers and Operations
5.2.1. Content-Transfer-Encoding Not Used in HTTP Transport
HTTP can handle binary data and so there is no need to use the
content transfer encodings of MIME [1]. This difference is discussed
in [3], Section 19.4.5. However, a content transfer encoding value
of binary or 8-bit is permissible but not required. The absence of
this header MUST NOT result in transaction failure. 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 is 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 discuss some options for compressing or chunking entities to
be transferred. In [3], Section 8.1.2.2 discusses a pipelining
option that is useful for segmenting large amounts of data.
5.3. Modification of MIME or Other Headers or Parameters Used
5.3.1. Content-Length
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 is 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.
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
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.
5. The ability to return either a synchronous or an asynchronous
receipt as the sending party requests.
The signed receipt is used to notify a sending trading partner that
requested the signed receipt that:
1. The receiving trading partner acknowledges receipt of the sent
EC Interchange.
2. If the sent message was signed, then the receiving trading
partner has authenticated the sender 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, 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.
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/pkcs-7-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 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, including the
MIME headers.
The signed MDN, when received by the sender of the EDI Interchange,
can be used by the sender as follows:
o As an acknowledgement that the EDI Interchange sent 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.
o As an acknowledgement 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.
o As an acknowledgement that the receiving trading partner has
authenticated the sender of the EDI Interchange.
o 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. Synchronous and Asynchronous MDNs
The AS2-MDN exists in two varieties: 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. This form of AS2-MDN is
called synchronous because the AS2-MDN is returned 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. However, at the transfer-protocol layer, assuming
that no HTTP pipelining is utilized, the asynchronous AS2-MDN is
delivered on a unique TCP/IP connection, distinct from that used to
deliver 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 an asynchronous AS2-MDN is requested by the sender of an AS2
message, the synchronous HTTP or HTTPS response returned to the
sender prior to terminating the connection MUST be a transfer-layer
response indicating the success or failure of the data transfer. The
format of such a synchronous response MAY be the same as that
response returned when no AS2-MDN is requested.
The following diagram illustrates the synchronous versus asynchronous
varieties of AS2-MDN delivery using 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 advantage of the synchronous MDN is that it can provide the
sender of the AS2 Message with a verifiable confirmation of message
delivery within a synchronous logic flow. However, if the message is
relatively large, the time required to process this message and to
return an AS2-MDN to the sender on the same TCP/IP connection may
exceed the maximum configured time permitted for an IP connection.
The advantage of the asynchronous MDN is that it provides for the
rapid return of a transfer-layer response from the receiver,
confirming the receipt of data, therefore not requiring that a TCP/IP
connection necessarily remain open for very long. However, this
design requires that the asynchronous AS2-MDN contain enough
information to identify the original message uniquely so that, when
received by the AS2 Message originator, the status of the original
AS2 Message can be properly updated based on the contents of the
AS2-MDN.
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
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"
":" mail-address
The following example is for requesting an MDN:
Disposition-notification-to: xxx@example.com
This syntax is a residue of the use of MDNs using SMTP transfer.
Because this specification is adjusting the functionality from SMTP
to HTTP while retaining as much as possible from the [4]
functionality, the mail-address MUST be present. The mail-address
field is specified as an RFC 2822 localpart@domain [addr-spec]
address. However, the address is not used to identify where to
return the MDN. Receiving applications MUST ignore the value and
MUST not complain about RFC 2822 address syntax violations.
When requesting MDN-based receipts, the originator supplies
additional extension headers that precede the message body. These
header "tags" are as follows:
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
MDN. Other headers, especially "Subject" and "Date", SHOULD be
supplied; the values of these headers are often mentioned in the
human-readable section of a MDN to aid in identifying the original
message.
MDNs will be returned in the HTTP response when requested, unless an
asynchronous return is requested.
To request an asynchronous message disposition notification, the
following header is placed into the message that is sent:
Receipt-Delivery-Option: return-URL
Here is an example requesting that the MDN be asynchronous:
Receipt-Delivery-Option: http://www.example.com/Path
Receipt-delivery-option syntax allows return-url to use some schemes
other than HTTP using the POST method.
The "receipt-delivery-option: return-url" string indicates 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 is not used in this specification because it was
limited to RFC 2822 addresses; the extension header "Receipt-
delivery-option" has been introduced to provide a URL for the MDN
return by several transfer options.
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 information on requesting SMTP MDNs, refer to RFC 3335 [4].
Finally, the header, Disposition-notification-options, identifies
characteristics of message disposition notification as in [5]. The
most important of these options is for indicating the signing options
for the MDN, as in the following example:
Disposition-notification-options:
signed-receipt-protocol=optional,pkcs7-signature;
signed-receipt-micalg=optional,sha1,md5
For signing options, consider the disposition-notification-options
syntax:
Disposition-notification-options =
"Disposition-Notification-Options" ":"
disposition-notification-parameters
where
disposition-notification-parameters =
parameter *(";" parameter)
where
parameter = attribute "=" importance ", " 1#value"
where
importance = "required" | "optional"
So the Disposition-notification-options string could be:
signed-receipt-protocol=optional,<protocol symbol>;
signed-receipt-micalg=optional,<micalg1>,<micalg2>,...;
The currently 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 the "signed-
receipt-micalg" parameters are 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. 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"
indicates that a receipt is synchronous in nature. The presence
of the "Receipt-Delivery-Option: return-url" indicates that an
asynchronous receipt is requested and SHOULD be sent to the
"return-url".
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 a MDN.
A UA that does not 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 could not
sign it.
The returned MDN will contain information on the disposition of
the message and on why the MDN could not be signed. See the