Further IESG review of EDIINT documents

<ned.freed <at> mrochek.com>
2002-04-04 17:59:38 GMT

AS1 was on today's IESG agenda, and there were some additional comments. The
good news is that this time they are all minor and entirely editorial in
nature:
(1) The RFC Editor has started pushing back on unexpanded acronyms in
document titles and abstracts. Accordingly, I'd suggest expanding
EDI, EDIFACT, and CMS.
(2) The term VAN is used but not defined. (It was expanded in the now-withdrawn
requirements document.)
(3) In anticipation of moving towards using AES in the future, the
IESG would like to see a note to this effect in this document. The
most reasonable place for it seems to me to be section 3.2.6.
That's it!
Ned

I-D ACTION:draft-ietf-ediint-as1-17.txt

<Internet-Drafts <at> ietf.org>
2002-04-08 13:50:32 GMT

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Electronic Data Interchange-Internet Integration Working Group of the IETF.
Title : MIME-based Secure Peer-to-Peer Business Data
Interchange over the Internet
Author(s) : T. Harding, R. Drummond, C. Shih
Filename : draft-ietf-ediint-as1-17.txt
Pages : 27
Date : 05-Apr-02
This document describes how to exchange structured business data
securely using SMTP transport for Electronic Data Interchange,
(EDI - either the American Standards Committee X12 or UN/EDIFACT,
Electronic Data Interchange for Administration, Commerce and
Transport), XML or other data used for business to business data
interchange. The data is packaged using standard MIME
content-types. Authentication and privacy are obtained by using
Cryptographic Message Syntax (S/MIME) or OpenPGP security body
parts. Authenticated acknowledgements make use of
multipart/signed replies to the original SMTP message.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ediint-as1-17.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then

FW: New AS2-Version Header

David Fischer <david <at> drummondgroup.com>
2002-04-10 19:27:08 GMT

The UCC AS2 Interoperability test is in progress and
some concerns have been raised about backward compatibility to previous test
rounds. Specifically, this round includes the new EDIINT Compression
functionality. The following discussion has been in
progress. We would like to include the EDIINT list in this discussion and
solicit your comments.

We decided
to look ahead to future tests and possible concerns about backward compatibility
to this test. We agreed to add a new header for this test
round:

AS2-Version: 1.1

Yesterday's test to all participants with this new
header did not reveal any failures. Since no system was expecting this
header, and yet no one failed the message, this would indicate that this header
may be safely included in messages sent to older systems.

This
header will be included in the Final Interoperability Report with an explanation
that v1.1 means the sending system supports all of the AS2 basic functionality
and it supports Compression as defined in the EDIINT Compression Draft
specification. The version number MAY be incremented in the future if the
addition of new functionality warrants such an action.

It will be
REQUIRED, for this round and in the future, that this header be included on any
sent message, and any returned MDN (but not with
a single line HTTP status response). Receiving systems MUST NOT
fail due to the absence of this header. The absence of this new
header would nominally indicate a system from a previous test round. At
this time, the presence of this header is informative in nature only and the
receiving system may or may not utilize this information at the discretion of
the implementer.

Before
this new header can be added to the AS2 specification, we will need to request
discussion from the EDIINT list. This header would be included in the AS2
specification with the value of:

AS2-Version: 1.0

This
header would also be inserted into the EDIINT Compression specification with the
value of:

AS2-Version: 1.1

This
header would be for AS2 systems only and would not be included when Compression
is performed on an AS1 message.

Re: FW: New AS2-Version Header

Steve Lowery <Lowerys <at> meijer.com>
2002-04-11 11:35:08 GMT

I apologize if I haven't been following along in the compression discussion but what happens if an older
system (one that doesn't have compression) receives a compressed message. Maybe it doesn't matter, you
should be able to elect if you want compressed messages or not.
Is the AS2-Version field an indication that the message may be compressed?
Again I apologize for not following but what compression engine will be used?
>>> "David Fischer" <david <at> drummondgroup.com> 04/10/02 03:27PM >>>
The UCC AS2 Interoperability test is in progress and some
concerns have been raised about backward compatibility to
previous test rounds. Specifically, this round includes the
new EDIINT Compression functionality. The following
discussion has been in progress. We would like to include
the EDIINT list in this discussion and solicit your
comments.
Best Regards,
David Fischer
Drummond Group.
-----Original Message-----
From: David Fischer [mailto:david <at> drummondgroup.com]
Sent: Wednesday, April 10, 2002 1:45 PM
To: AS2 Interoperability Test
Subject: New AS2-Version Header
We had another long discussion today about backward
compatibility.
We decided to look ahead to future tests and possible
concerns about backward compatibility to this test. We
agreed to add a new header for this test round:
AS2-Version: 1.1
Yesterday's test to all participants with this new header
did not reveal any failures. Since no system was expecting
this header, and yet no one failed the message, this would
indicate that this header may be safely included in messages
sent to older systems.
This header will be included in the Final Interoperability
Report with an explanation that v1.1 means the sending
system supports all of the AS2 basic functionality and it
supports Compression as defined in the EDIINT Compression
Draft specification. The version number MAY be incremented
in the future if the addition of new functionality warrants
such an action.
It will be REQUIRED, for this round and in the future, that
this header be included on any sent message, and any
returned MDN (but not with a single line HTTP status
response). Receiving systems MUST NOT fail due to the
absence of this header. The absence of this new header
would nominally indicate a system from a previous test
round. At this time, the presence of this header is
informative in nature only and the receiving system may or
may not utilize this information at the discretion of the
implementer.
Before this new header can be added to the AS2
specification, we will need to request discussion from the
EDIINT list. This header would be included in the AS2
specification with the value of:
AS2-Version: 1.0
This header would also be inserted into the EDIINT
Compression specification with the value of:
AS2-Version: 1.1
This header would be for AS2 systems only and would not be
included when Compression is performed on an AS1 message.
Does this meet with everyone's approval?
Regards,
David Fischer
Drummond Group.

RE: FW: New AS2-Version Header

David Fischer <david <at> drummondgroup.com>
2002-04-11 14:32:07 GMT

If an older system received a compressed message, it would try to unpackage the
message and fail because it did not understand all the fields in the
Content-Type. They would also not understand the AS2-Version field but if they
follow HTTP rules, they should ignore the AS2-Version header.
Compression is typically a flag in the Trading Partner record of the Trading
Partner database. Whether or not messages are compressed would typically be
negotiated out-of-band. Exactly how this is accomplished is implementation
dependant. When communicating to an older system, don't set this flag.
The AS2-Version header will not help with older versions. We are considering
this header in anticipation of future tests interoperating with the current crop
of system. The value 1.1 will indicate that the sending system supports all the
functionality in this test round -- basic functionality plus compression.
Regards,
David Fischer
Drummond Group.
-----Original Message-----
From: Steve Lowery [mailto:Lowerys <at> meijer.com]
Sent: Thursday, April 11, 2002 6:35 AM
To: david <at> drummondgroup.com; ietf-ediint <at> imc.org
Subject: Re: FW: New AS2-Version Header
I apologize if I haven't been following along in the compression discussion but
what happens if an older system (one that doesn't have compression) receives a
compressed message. Maybe it doesn't matter, you should be able to elect if you
want compressed messages or not.
Is the AS2-Version field an indication that the message may be compressed?
Again I apologize for not following but what compression engine will be used?
>>> "David Fischer" <david <at> drummondgroup.com> 04/10/02 03:27PM >>>
The UCC AS2 Interoperability test is in progress and some
concerns have been raised about backward compatibility to
previous test rounds. Specifically, this round includes the
new EDIINT Compression functionality. The following
discussion has been in progress. We would like to include
the EDIINT list in this discussion and solicit your
comments.
Best Regards,
David Fischer
Drummond Group.
-----Original Message-----
From: David Fischer [mailto:david <at> drummondgroup.com]
Sent: Wednesday, April 10, 2002 1:45 PM
To: AS2 Interoperability Test
Subject: New AS2-Version Header
We had another long discussion today about backward
compatibility.
We decided to look ahead to future tests and possible
concerns about backward compatibility to this test. We
agreed to add a new header for this test round:
AS2-Version: 1.1
Yesterday's test to all participants with this new header
did not reveal any failures. Since no system was expecting
this header, and yet no one failed the message, this would
indicate that this header may be safely included in messages
sent to older systems.
This header will be included in the Final Interoperability
Report with an explanation that v1.1 means the sending
system supports all of the AS2 basic functionality and it
supports Compression as defined in the EDIINT Compression
Draft specification. The version number MAY be incremented
in the future if the addition of new functionality warrants
such an action.
It will be REQUIRED, for this round and in the future, that
this header be included on any sent message, and any
returned MDN (but not with a single line HTTP status
response). Receiving systems MUST NOT fail due to the
absence of this header. The absence of this new header
would nominally indicate a system from a previous test
round. At this time, the presence of this header is
informative in nature only and the receiving system may or
may not utilize this information at the discretion of the
implementer.
Before this new header can be added to the AS2
specification, we will need to request discussion from the
EDIINT list. This header would be included in the AS2
specification with the value of:
AS2-Version: 1.0
This header would also be inserted into the EDIINT
Compression specification with the value of:
AS2-Version: 1.1
This header would be for AS2 systems only and would not be
included when Compression is performed on an AS1 message.
Does this meet with everyone's approval?
Regards,
David Fischer
Drummond Group.

RE: New AS2 Draft

David Fischer <david <at> drummondgroup.com>
2002-04-17 19:48:39 GMT

Sorry,
David.
-----Original Message-----
From: Steve Lowery [mailto:Lowerys <at> meijer.com]
Sent: Wednesday, April 17, 2002 2:23 PM
To: david <at> drummondgroup.com
Subject: Re: New AS2 Draft
was the document to be attached?
>>> "David Fischer" <david <at> drummondgroup.com> 04/17/02 02:33PM >>>
This is the new draft AS2 spec with the new AS2-Version
header.
We also tightened up the definition of Message-Id (section
3.2.3) and AS2-To/AS2-From (section 4) to enhance
interoperability and backward compatibility.
This has not yet been sent to IETF.
Comments?
Regards,
David Fischer
Drummond Group.

EDIINT Working Group Dale Moberg
Internet draft Dick Brooks
Expires: November 2002 Rik Drummond
David Fischer
May 2002
HTTP Transport for Secure Peer-to-Peer
Business Data Interchange over the Internet
draft-ietf-ediint-as2-11.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in an Internet-
Drafts Shadow Directory, see http://www.ietf.org/shadow.html.
Any questions, comments, and reports of defects or ambiguities in
this specification may be sent to the mailing list for the EDIINT
working group of the IETF, using the address
<ietf-ediint <at> imc.org>. Requests to subscribe to the mailing list
should be addressed to <ietf-ediint-request <at> imc.org>.
Abstract
This document describes how to exchange structured business data
securely using HTTP transport for Electronic Data Interchange,
(EDI - either the American Standards Committee X12 or UN/EDIFACT,
Electronic Data Interchange for Administration, Commerce and
Transport), XML or other data used for business to business data
interchange. The data is packaged using standard MIME
content-types. Authentication and privacy are obtained by using
Cryptographic Message Syntax (S/MIME) or OpenPGP security body
parts. Authenticated acknowledgements make use of
multipart/signed replies to the HTTP POST requests.
This document extends the procedures and payload packaging options
of AS1 in the following ways: HTTPS may be used to obtain data,
privacy both synchronous and asynchronous reply procedures are,
described multipart/form-data packaging may be used, a generalized
Moberg, Brooks, Drummond, Fischer [page 1]
HTTP Transport for Secure EDI May 2002
multipart/report format is added to the MDN format of AS1, replies
may include a multipart/mixed payload that contains both the
acknowledgement and an additional EDI payload.
This document is intended to be read in conjunction with AS1 and
the referenced RFCs defining the MIME and cryptographic
packaging that are used to obtain secure, authenticated, and
acknowledged transport.
Feedback Instructions:
NOTE TO RFC EDITOR: This section should be removed
by the RFC editor prior to publication.
If you want to provide feedback on this draft, follow these
guidelines:
- Send feedback via e-mail to the ietf-ediint list for discussion,
with "AS#2" in the Subject field. To enter/follow the
discussion, you need to subscribe at ietf-ediint <at> imc.org.
- Be specific as to what section you are referring to, preferably
quoting the portion that needs modification, after which you
state your comments.
- If you are recommending some text to be replaced with your
suggested text, again, quote the section to be replaced, and be
clear on the section in question.
Table of Contents
1. Introduction
1.1 Purpose and relation to previous work
1.2 Overall operation
2. Stages and Details of HTTP Transmission and Acknowledgment
2.1 Requesting Receipts
2.1.1 Requesting MDN-based receipts
2.1.2 Requesting Generalized receipts
2.1.2.1 Additional Commonly Used Headers
2.1.3 Summary Remarks on Receipt request options
2.2 Sending EDI in HTTP POST Requests
2.3 Using Transport Layer Security
2.4 Response Status Codes in Replies
2.5 Receipt Reply
2.5.1 MDN Receipts and Signed MDN Receipts
2.5.2 Generalized Receipts and Signed Receipts
2.6 Additional Reply Content
2.7 Non-Repudiation of the POST Reply
2.8 Error Recovery
3. Other differences between HTTP and SMTP based transport
3.1 Unused MIME headers and operations
3.1.1 Content-Transfer-Encoding not used
Moberg, Brooks, Drummond, Fischer [page 2]
HTTP Transport for Secure EDI May 2002
3.1.2 Epilogue must be empty
3.1.3 Lengthy message bodies
3.2 Differences in MIME or other headers or parameters used
3.2.1 Content-Length
3.2.2 Final Recipient and Original Recipient
3.2.3 Message-Id and Original-Message-Id
3.2.4 Host header
4. Additional AS2 specific HTTP headers
4.1 AS2 Version Header
4.2 AS2 System Identifiers
4.2.1 Rules for using the AS2-To and AS2-From headers
4.2.2 Unrecognized System Identifiers
A. AS2 MIME templates.
B. Using AS2 Extensions in the GISB Protocol
C. Samples of AS2 Protocol Data Units
D. Acknowledgments
E. References
F. Security Considerations
G. Authors' Addresses
1. Introduction
1.1 Purpose and relation to previous work
Early work on Internet EDI focused on specifying MIME content
types for EDI data [MIMEEDI] The functional requirements
document , "Requirements for Interoperable Internet EDI,"
[EDIINT] provides extensive information on EDI security and the
business and user processes that can benefit from the use of EDI
security. In addition, MIME structures appropriate for SMTP
transport of the packaged EDI data are specified in ([AS1]
"MIME-based Secure EDI") as well as the details needed to
support signed receipts as acknowledgments. The framework of
[AS1] shows how to implement the security features--specifically
data privacy, data integrity/authenticity, non-repudiation of
origin and non-repudiation of receipt --found to be requirements
for secure EDI.
In this document, it is assumed that the reader is familiar
with the SMTP/MIME transport document, the requirements document,
and the RFCs applied or referenced in those documents.
This draft, like the SMTP/MIME transport document, builds on
previous RFCs and is attempting to "re-invent" as little as
possible. The goal here is to specify how previously specified
MIME messaging structures and operations can be adapted for use
with HTTP servers and clients to obtain secure, reliable, and
acknowledged transport for EDI and other business data.
The applicability statement, [AS1] "MIME-based Secure EDI,"
Moberg, Brooks, Drummond, Fischer [page 3]
HTTP Transport for Secure EDI May 2002
explained the basic EDI transaction using the concept of a
"secure transmission loop" for EDI. This loop involves one
organization sending a signed and encrypted EDI interchange to
another organization, requesting a signed receipt, followed by
the receiving organization sending this signed receipt back to
the sending organization. The transmission therefore involves
the following stages:
1. The organization sending business data encrypts the data
and provides a digital signature, using either PGP/MIME or
S/MIME. In addition, they request a signed receipt.
2. The receiving organization decrypts the message and
verifies the signature, resulting in verified integrity of
the data and authenticity of the sender.
3. The receiving organization then sends a signed receipt
using a signature over the hash of a message disposition
notification, which contains a hash of the received message.
The above stages describe the functionality that would
satisfy all security requirements. Applications are expected
to be able to provide full functionality, though users may
agree to exchange data using only a restricted subset of
functionality. For example, businesses may agree to send signed
data using TLS, and only request a simple, unsigned receipt.
Implementations are expected to be configurable so that they may
support business community agreements that use subsets
of the full functionality.
In this document, the goal is to make use of HTTP instead of SMTP
as a transport protocol, and make the changes that are needed to
adapt to protocol packaging differences.
In either transport case, the body of the message is a MIME
structure, using MIME headers ("content-type" and other
"content-X" tags) to convey information about the data
being transported.
Also, one primary use of SMTP RFC 822 headers within SMTP based
transport of secure EDI has been to enable requests for
acknowledgements and to specify options for signatures over
acknowledgements (asymmetric encryption and cryptographic
hash algorithm preferences).
One way to convey this information within the HTTP transport
context is to use either HTTP entity-headers or extension-headers
[11, section 7.1] that have the syntax of SMTP headers. Only the
"From" header is overloaded by possibly different usages in the
SMTP and HTTP contexts. The "From" header normally contains
machine-usable email addresses as defined in [SMTPMSG]. The
Moberg, Brooks, Drummond, Fischer [page 4]
HTTP Transport for Secure EDI May 2002
usage of the "From" header in [HTTP] section 14.22 is to provide
the email address of an administrative contact for the HTTP
client. The function of the "From" header in the SMTP context of
secure EDI transport has been to supply a value used in
constructing the MDN style receipt. But the MDN receipt has been
found to be too restrictive for some commercial EDI transport
scenarios [GISB]. So alternative receipt mechanisms will be
provided that, among other things, will remove any conflicts
arising from trying to reuse the SMTP-MDN roles of
"From" within the context of HTTP reserved usage of "FROM".
Also, it is currently difficult to make use of HTML [HTML]
and simple scripting to send HTTP entity-headers as part of the
HTML FORM tag construct. For HTML-based POST situations [GISB],
it is useful to specify ways to convey 'metadata' needed for the
secure transmission loop that do not make use of HTTP headers.
One way to specify this data is by using the MIME
multipart/form-data packaging specified in [FORMDATA].
For SMTP transport, the receipt and signed receipt functions are
implemented using Message Disposition Notifications [MDN]
and Multipart/signed Message Disposition Notifications [AS1].
For HTTP transport, generalization of the Message Disposition
Notification is useful.
The MDN is a special kind of multipart/report [REPORT]. For
MDNS, specialization is achieved by assigning the "report-type"
parameter in the content-type header the special value,
"disposition-notification" and by having the second body part
(the "machine-readable" body part) have the MIME content-type,
"message/disposition-notification".
To generalize a MDN, all that is needed is to remove the
restrictions that make the underlying multipart/report into a
MDN. In other words, the "report-type" parameter [REPORT,
section 1] is given a new value and the second body part is
changed to a content-type other than "message/disposition-
notification". Acknowledgements defined by these changes will be
referred to as "generalized receipts. Each receipt of this kind
will have its own specific report-type parameter and its own
specifications for the syntax and semantics of the automated
response body part. Implementations are encouraged to be able to
register new report-type handlers using only configuration
changes (not recompiling) that specify how to process new report-
type values.
Nothing else needs to be changed to construct reply
acknowledgements that are not restricted by the semantics of
MDNs. Specifically, a signed reply will still be constructed by
using a multipart/signed package to wrap up generalized receipts
with their signatures.
Finally, within the HTTP transport context, it is useful to make
Moberg, Brooks, Drummond, Fischer [page 5]
HTTP Transport for Secure EDI May 2002
use of Transport Layer Security [TLS] to provide privacy.
Compression can be provided using HTTP content-codings [HTTP],
sections 3.5, 14.3, 14.12]. (Content codings are not to be
confused with the MIME concept of content transfer encodings.)
A variety of other minor differences (for example, absence of
content-transfer-encoding) are noted below and summarized in the
concluding section.
1.2 Overall operation
A HTTP POST operation [HTTP] is used to send appropriately
packaged EDI, XML, or other business data. The Request-URI
([HTTP],section 9.5) identifies a process to unpack and handle
the message data and to generate a reply for the client that
contains a message disposition acknowledgement or a multipart/
report, signed or unsigned, and possibly other turnaround
transactions. This request/reply transactional interchange
provides secure, reliable, and authenticated transport for EDI
or other business data using HTTP; the security protocols and
structures used also support auditable records of these
transmissions, acknowledgements, and authentication.
2. Stages and Details of HTTP Transmission and Acknowledgment
A data file or stream is first structured into one of the
message templates described in [AS1], sections 4.2.1 to 4.2.4 or
4.3.1 to 4.3.4 for PGP/MIME or S/MIME security. In addition
to the content-types of [MIMEEDI], applications should be
prepared for handling other content-types used in business to
business transactions, such as those for XML [MIME-TYPES].
For convenience, these message templates, adapted for the
HTTP transport context, are provided in Appendix A.
If TLS is to be used, the typical packaging will be that
described in sections 4.2.2 or 4.3.2; that is, a multipart/signed
message will be created with no encryption in the message.
Otherwise, if privacy is desired, message templates 4.2.4 or
4.3.4 are used. Content transfer encoding is not used and
a content-length field is to be provided.
If HTML-based POST is used (using the METHOD=POST attribute
within the "FORM" tag) [HTML, 17 Forms], then the message payload
will be packaged in the input-data element of a multipart/form-
data. The metadata needed for application layer routing,
identification, requesting a reply and other transaction
operations can be packaged in message body parts in the
multipart/form-data. The labels for the metadata values are found
in the "name" parameter of the Content-Disposition header in each
form-data part as discussed in [FORMDATA, section 3].
Moberg, Brooks, Drummond, Fischer [page 6]
HTTP Transport for Secure EDI May 2002
In general, both HTTP servers and HTTP clients handling the
message templates of [AS1] should be prepared to process these
basic EDIINT data formats when they are embedded within MIME
multiparts. In addition to the enveloping and MIME media type
options defined in sections 4.2.x and 4.3.x of "MIME-based
Secure Peer-to-Peer Business Data Interchange over the
Internet" [AS1], this specification enables the transport of
payload objects containing other MIME media types. Implementors
are to follow the appropriate specifications identified under
"References" in [MIME-TYPES], for the type of object being
transmitted. For example, to send an XML object, the MIME media
type of application/xml is used in the Content-type MIME header
and the specifications for enveloping the object are contained
in [XMLTYPES]; for example:
Content-type: application/xml; charset="utf-8"
Many of the specifications referenced by [MIME-TYPES] were
designed for SMTP transports. Implementors are advised to make
appropriate adjustments for HTTP transport as indicated in
section 4 of this document.
Finally, several industry groups currently make use of
"encapsulated"(or opaque) signatures within encrypted or
signed objects. Encapsulated signatures should be supported
in order to accommodate these existing practices. Objects
containing encapsulated signatures must be prepared according
to the specifications contained in section 3.4.2 of [SMIMEV2]
or, in the case of PGP, according to the specifications contained
in section 6.2 of "MIME Security with Pretty Good Privacy (PGP)"
[MIMEPGP] and "OpenPGP Message Format" [RFC2440].
2.1 Requesting Receipts
2.1.1 Requesting MDN-based receipts
For requesting MDN based receipts, the originator supplies
metadata using the syntax of extension headers (the [SMTPMSG]
header syntax) that precede the message body.
The header "tags" are as follows:
A Disposition-Notification-To header is added to indicate
that a message disposition notification is requested
in the reply to the POST request. This header is
specified in [MDN]. It may have values other than email
addresses, such as a D-U-N-S number, when it is found as a
name parameter in a form-data body part When this tag is used in
HTTP extension headers, it follows the MDN usage.
A Message-ID header is added to support message reconciliation,
so that an Original-Message-Id value can be returned in the MDN
Moberg, Brooks, Drummond, Fischer [page 7]
HTTP Transport for Secure EDI May 2002
body part of the receipt. (The term "Receipts" is here used
to refer to the signed or unsigned multipart/report content.)
Both "From" and "To" extension headers SHOULD be supplied. The
"From" value needs to have an email address as specified in
[SMTPMSG] and [HTTP]. If other uses of "From" are needed, the
generalized receipts to be next discussed should be used. There
the role of "From" is replaced by symbols not having a reserved
HTTP or SMTP usage.
Other headers, especially "Subject" and "Date", should be
supplied; the values of these headers are often mentioned in the
human-readable section of a MDN to aid in identifying the
original message.
A Disposition-Notification-Options header is used to request
a signed message disposition notification. The parameters
used to select protocols for signed message disposition
notification are found in [AS1].
Disposition-Notification-To is a name that, if present,
indicates that the MDN style of receipt is to be used.
Disposition-notification-options identifies characteristics of
message disposition notification in accordance with [AS1] and
[MDN].
A Receipt-delivery-option is a header whose value is a URL
that indicates how the receipt is to be delivered. This header
is only used within AS2. The default mode of operation is
synchronous within HTTP transport, which means that the receipt
(be it MDN, signed MDN, generalized report receipt, or signed
report receipt) is returned in the reply body. By using the
"receipt-delivery-option," an asynchronous reply mode can be
requested. The values for this option are URLs that indicate the
destination for the reply, and may use any appropriate protocol
("mailto", "http", and "https" will be the more common types)
for this information. If this header/metadata is absent, then
the mode of operation is synchronous, which means that the
receipt is returned in the reply to the current HTTP request.
2.1.2 Requesting Generalized Receipts
In this section, the ways to request generalized receipts
are specified. Generalized receipts are multipart/reports
with a report-type other than "disposition-notification," and
a second automated response with a content type other
than "message/disposition-notification".
For requesting generalized receipts using the MIME template for
multipart/reports [REPORTS], the following metadata elements
will be useful. A specific example of a generalized receipt
Moberg, Brooks, Drummond, Fischer [page 8]
HTTP Transport for Secure EDI May 2002
with report-type "GISB-Acknowledgement-Receipt" will be
presented in appendix B.
When the term "metadata" is used in the following, the term
indicates the information may be supplied in one of two ways:
First, the metadata information may be supplied using the
syntax of HTTP headers. That is, the symbol name is
followed by a colon and its value follows; the header
is subject to processing of structured field bodies
[SMTPMSG, section 3.1.4], also including parameters.
Second, the metadata information may be supplied by using
the syntax of the "name" parameter within the
"Content-Disposition" header of the multipart/form-data
structure, when that MIME packaging [FORMDATA] is used.
For example,
--boundaryformdata
Content-Disposition: form-data; name="Receipt-Report-Type"
GISB-Acknowledgement-Receipt
--boundaryformdata
Within HTML, the symbols used for these names correspond to
the value of the name attribute within the INPUT element,
where the "type" attribute has a "text" value. [HTML],
section 18; for example,
<FORM action="http://somesite.com/responder" method="post">
<INPUT type="text" name="Receipt-Report-Type">
<INPUT type="submit" value="Send"> <INPUT type="reset">
</FORM>
To indicate the various options for generalized receipts, the
basic metadata that the POSTing client needs to convey to the
replying server are: "Receipt-Disposition-To", and
"Receipt-report-type", "Receipt-Security-Selection",
"Receipt-Delivery-Option".
The presence of the metadata value "Receipt-Disposition-To",
using the extension header syntax, indicates a request for a
generalized receipt.
Because HTTP already has a role for the "From" header, the
"Receipt-Disposition-To" header is used to avoid conflicts
with [HTTP], when using the header syntax for metadata.
(Within a multipart/form-data package, the "From" value
can be used to identify the sending party without any
conflict with HTTP headers.) Notice that the value for this
identifier need not be an email address or a URL. In this way,
other systems of identification (such as a DUNS number) may be
Moberg, Brooks, Drummond, Fischer [page 9]
HTTP Transport for Secure EDI May 2002
used, if needed. Notice that the information needed for delivery
of the receipt is found in the receipt-delivery-option element
described below; delivery information is not generally needed
if the default mode of operation occurs. In that case, the
receipt just goes back in the reply to the current HTTP request.
"Receipt-Report-Type" indicates the desired value of the
"report-type" parameter in the multipart/report content type of
a specific version of the generalized receipt. This parameter
must be supplied when "Receipt-Disposition-To" is used to
indicate a request for a generalized receipt because this
indicates what specific type of receipt is desired. An example
for this value (discussed in appendix A) is
"GISB-Acknowledgement-Receipt".
"Receipt-Security-Selection" is a name that indicates the
protocol and algorithm choices for a digital signature
over the receipt. Signatures are always in multipart/signed
packages. The format for protocol and algorithm choices is
that used in [AS1] and [MDN]; for example,
Receipt-Security-Selection:
signed-receipt-protocol=optional,pkcs7-signature;
signed-receipt-micalg=optional,rsa-sha1
"Receipt-Delivery-Option" is used to indicate the
URL for asynchronous delivery of the receipt.
While the default mode of operation within HTTP
transport is to return the receipt(be it MDN, signed
MDN, generalized receipt, or signed generalized receipt)
in the reply body, asynchronous reply is allowed through
use of this symbol. The URLs will typically use the
"MAILTO", "HTTP", and "HTTPS" schemes. For the HTTP and
HTTPS schemes, the POST method is to be used.
2.1.2.1 Additional Commonly Used Headers
The following set of header data elements are also available for
use. Organizations wishing to use this specification for the
secure and reliable transport of business documents are not
required to utilize all of these headers and are free to use
whatever subset they deem appropriate for their business needs.
TO:
The To name contains an identifier identifying the
intended recipient of a data exchange and may be
D&B D-U-N-S number [DUNS] or other agreed upon
identifier system. Applications should allow users to
configure these elements in the automated HTTP agents
Moberg, Brooks, Drummond, Fischer [page 10]
HTTP Transport for Secure EDI May 2002
processing these values. For example, the body
part MIME header line looks like the following line:
Content-Disposition: form-data; name="To"
FROM:
The From name contains a textual value identifying the sender
of a data exchange, such as the a D&B D-U-N-S number [DUNS] as
in [GISB]. Because "From" has a specified use within [HTTP],
the From name parameter is not to be considered equivalent
to the extension header. If an extension header "From" is
to be used within HTTP, it should conform to the usage, syntax,
and semantics of [HTTP] section 14.22. The extension header
counterpart of the sender of a data exchange is the extension
header version of "Receipt-disposition-to"
INPUT-FORMAT:
The Input-format name identifies the type of data contained
in a data file.
AGENT:
The Agent name parameter indicates the network or agent
where the data exchange originated.
APPLICATION:
The Application name identifies the application used to process
the data next (after the URI-request process has finished with
the stream).
DATETIME:
The DateTime name provides the date and time the data was
created and uses the format specified in [SMTPMSG] as updated
by RFC 1123.
REFNUM:
The RefNum is an integer value used to uniquely identify the
communication exchange and is in a textual format. The RefNum is
similar to the Message-ID and Content-Id headers of SMTP that
are used in constructing values in receipts based on MDNs.
USERPARAM:
The UserParam is a user-defined parameter.
Version:
Version is a protocol version number [GISB].
TRANSACTION-SET:
Transaction-set is an optional data element identifying the
EDI transaction.
INPUT-DATA:
Input-data is the sending side's local file system name
Moberg, Brooks, Drummond, Fischer [page 11]
HTTP Transport for Secure EDI May 2002
for the file being sent. The payload is contained as the body
part of this header element.
PRIORITY:
The "Priority" name is used to indicate the processing priority
of each message relative to other messages sent by a given
party. The value "1" indicates highest priority and a value
of "5" indicates the lowest priority.
EXPIRATION:
The "Expiration" name is used to indicate the date and time at
which a message is no longer transportable. No message delivery
should be attempted beyond the date and time specified in
this value. The date/time format must follow the specifications
contained in section 5 of RFC822.
2.1.3 Summary Remarks on Receipt request options
Applications are encouraged to support handling all metadata
values whether they make use of the name parameter syntax
within a multipart/form-data or whether they use the message
header syntax used in SMTP or HTTP headers [SMTPMSG]. If
metadata items are repeated in extension headers and in
form-data parts, but the values are not the same, the
extension header values will be selected for use.
Because the value in Receipt-Disposition-To may have no
significance for how the receipt is transported, the extension
header "Receipt-delivery-option" is to be used to provide
that information.
The receipt-delivery-option's value should be a URL indicating
the delivery transport destination for the receipt.
The Receipt-delivery-option field is used when asynchronous
delivery is desired. It should not be present if the intention
is to deliver the reply synchronously; synchronous delivery of
the reply is the default mode of delivery.
For signed generalized receipts, an extension header of
"Receipt-security-selection" should be added to indicate the
desired security protocol for the multipart/signed over the
multipart/report.
In summary, the receipt request and construction processes now
have the following options:
1. Receipt requests are made by conveying metadata
values using a syntax of either the name parameter in a
multipart/form-data's Content-Disposition headers or by
using a syntax of HTTP extension headers.
Moberg, Brooks, Drummond, Fischer [page 12]
HTTP Transport for Secure EDI May 2002
2. Both MDN and generalized receipts can be requested using
either syntax. However, using an extension header syntax
and requesting a MDN receipt means restricting the "From"
values to email addresses.
3. Either type of receipt comes in signed or unsigned versions.
4. Finally, receipts may be delivered synchronously (delivered
in the HTTP reply) or asynchronously by using the
"Receipt-delivery-option" header.
2.2 Sending EDI in HTTP Client Requests using POST
For sending EDI, the following protocol elements are typically
present: a request line ([HTTP], section 5.1), entity headers, a
CRLF pair to mark the end of the entity headers, followed by the
message-body.
The request line will have the form: "POST Request-URI HTTP/1.1",
with spaces and followed by a CRLF. The Request-URI is typically
exchanged out of band, as part of setting up a bilateral
trading partner agreement. Applications should be prepared
to deal with an initial reply containing a status indicating a
need for authentication of the usual types used for authorizing
access to the Request-URI ([HTTP], section 10.4.2 and elsewhere).
Automation of this process is not discussed in this document
but might involve obtaining a session URL from a page requesting
authentication and possibly other information about proposed
EDI standard versions and other trading conventions to be used.
The request line is followed by entity headers specifying content
length ([HTTP] section 14.14) and content type [HTTP], section
14.18. The Host request header ([HTTP] sections 9 and 14.23)
is also included.
The entity or extension headers used for requesting a MDN
(unsigned or signed) have previously been mentioned,
as have those ("To" "From" "Message-Id") that are needed as
values for MDN fields or for other receipt requests.
For generalized receipts based on the multipart/report content
type, the metadata can be the values found in extension headers,
but can also be placed in body parts of a multipart/form-data
using "name" parameters in the content-disposition header.
Finally, the payload is found in any of the message patterns
of [AS1] sections 4.2.1 to 4.2.4 or 4.3.1 to 4.3.4 for PGP/MIME
or S/MIME security. These payloads may arrive as the "input-data"
part of the multipart/form-data or may even be enclosed in some
other multipart.
Moberg, Brooks, Drummond, Fischer [page 13]
HTTP Transport for Secure EDI May 2002
2.3 Using Transport Layer Security
To use Transport Layer Security [TLS], the request-URI should
indicate the appropriate scheme value, HTTPS. Usually only a
multipart/signed message body would be sent using TLS, as
encrypted message bodies would be redundant. Encrypted message
bodies are not prohibited, however. For asynchronous receipt
delivery requests, use the "Receipt-delivery-option" header with
a URL value making use of the HTTPS scheme to obtain security
privacy.
2.4 Response Status Codes in Replies
The status line for response to errors in the POST request line
will be provided by a status line with the following protocol
elements present ([HTTP], section 6.1): HTTP version (normally,
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 [HTTP], sections 6.1.1 and throughout section 10.
HTTP/1.1), a status code, reason phrase, and CRLF.
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 [HTTP].
A careful examination of these codes and their semantics
should be made before implementing any retry functionality
that is described below; specifically, retries should not
be made if the error is not transient or if retries are
explicitly discouraged (for real authentication failures,
for example.)
If there are no transfer protocol errors and no MDN is
requested, the one line status response should appear as:
HTTP/1.1 200 OK<CRLF>
<CRLF>
Note that the status code 200 might be anything in the 2xx
range, such as 204 No Content.
2.5 Receipt Reply
The details of the response to the POST command vary depending
upon whether a receipt has been requested and upon what kind
of receipt has been requested.
With no extended header requesting a receipt, and no errors
accessing the request-URI specified processing, the status
line in the Response to the POST request should be in the 200
Moberg, Brooks, Drummond, Fischer [page 14]
HTTP Transport for Secure EDI May 2002
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 condition
at the authentication, decryption or other higher level, the
HTTP status code should indicate success at the HTTP level.
The HTTP server-side application may respond with an unsolicited
multipart/report as a message body that the HTTP client
might not have solicited, but this may be discarded by the
client. Applications should avoid emitting unsolicited receipt
replies because bandwidth or processing limitations might
have led administrators to suspend asking for acknowledgements.
When a Disposition-Notification-To extension header is present
in the POST request entity headers, then entity headers for
the MDN should be included. The content type for the MDN receipt
(multipart/report [REPORT] or multipart/signed [SECURITY])
should be included in the Response entity headers.
The basic responsibilities of responding to requests are
discussed in [AS1] section 5, and in detail within section 5.2.1.
2.5.1 MDN based Receipts and Signed MDN Receipts
Message Disposition Notifications, when used in the HTTP
reply context, will closely parallel a SMTP MDN. For
example, the disposition field is a required element in the
machine readable second part of a multipart/report for a
MDN. The final-recipient-field ([MDN] section 3.1) value
should be derived from the entity headers of the request.
If the "To" field is missing, for signed messages, the value for
Original-recipient may be the email address field from the
signer's X.509 attribute for email addresses, if that value is
available. For a MDN, an application must report the Message-ID
of the request. The human readable part (the first part of the
multipart/report) should include items such as the subject, date
and other information when those fields are present in entity
header fields following the POST request.
The HTTP reply should normally omit the third optional part
of the multipart/report (used to return the original message
or its headers in the SMTP context).
2.5.2 Generalized Receipts and Signed Receipts
For generalized receipts, the multipart/report [REPORT]
or a multipart/signed containing a multipart/report
as the signed data is the basic MIME packaging. Each
generalized receipt needs a value for the multipart/report
parameter, "report-type," a selection of a content-type
Moberg, Brooks, Drummond, Fischer [page 15]
HTTP Transport for Secure EDI May 2002
for its second body part, when signed, a hash value over
a defined portion of the original message and,
when asynchronously delivered, information allowing the
identification of the original POSTed message.
The basic structure of the multipart/report is used so that
the first part is a "human-readable" message concerning the
received message. The second part should be for automated process
utilization. It should at least possess some common Internet
syntax for expressing names and values, such as the [SMTPMSG]
header syntax, XML, or some MIME content type correlated with
automated processing.
The MDN requirements, therefore, are removed for this second
part, but information used in MDNs may be used here. The third
part of the multipart report is usually omitted in the HTTP
context, but could include the extension headers, or even the
entire payload, to provide diagnostic information.
A multipart/signed over a multipart/report is constructed
precisely in the same way as a multipart/signed over a MDN [AS1].
One metadata element should be within the automated part.
This is the Received-Content-MIC (also allowing
X-Received-Content-MIC). This value is constructed and formatted
as described in [AS1] and the syntax should be either RFC822:
Received-Content-MIC: w7AguNJEmhF/qIjJw6LnnA==, rsa-md5
or simple XML
<ReceivedContentMic algid=rsa-md5 encode=base64 >
w7AguNJEmhF/qIjJw6LnnA==
</ReceivedContentMic>
Original-Message-ID: <43141asfioufasd <at> somewhere.com>
Otherwise the automated acknowledgement semantics are left open
to further semantic specification by specific electronic commerce
communities, such as in [GISB]. Each specialization of the
generalized receipt should make use of a specific identifying
value to be placed in the parameter "report-type,"
Any original metadata thought useful to include in the automated
part may be reflected back using "Original-X", as in
Content-Type: multipart/report;
report-type="identifying-value";
boundary="=-Trfds88fd99"
Implementations should attempt to be configurable to allow
for new report-type values to be added; communities can then
Moberg, Brooks, Drummond, Fischer [page 16]
HTTP Transport for Secure EDI May 2002
agree to the specific extensions they need to support application
level routing, transaction identification, timestamps, and
other specialized information about the data they have exchanged.
2.6 Additional Reply Content
In general, both HTTP servers and HTTP clients should be prepared
to process the basic EDIINT data formats when they are embedded
within MIME multiparts. This is true for HTTP request payloads
as well as HTTP reply payloads.
So, as previously mentioned, for HTML-based POSTS, any of the
EDIINT templates described in [AS1], sections 4.2.1 to 4.2.4 or
4.3.1 to 4.3.4 for PGP/MIME or S/MIME security, may be found as
parts of a multipart/form-data. [Consult Appendix A for the
templates adapted for this document.]
In addition, the response to the POST operation may include other
MIME wrapped content besides an MDN Receipt, Signed MDN,
Generalized Receipt or Signed Generalized Receipt. If a receipt
was requested within the POST data, and additional content is to
be returned, the receipt multipart/report must be combined with
the other data using some MIME multipart pattern. Real-time EDI
processing systems may use MIME multipart content-types to
include a response EDI message, for example, a Quote in response
to a Request-For-Quote transaction.
Also, if requested, the sender may request an asynchronous mode
for return of receipt. This mode is indicated by including the
metadata for Receipt-delivery-option as explained above.
2.7 Non-Repudiation of the POST Reply
If the reply to a POST operation needs a MDN receipt for non-
repudiation (for example, the reply includes content other than
a receipt), the top-level headers in the response include
the same headers required for POST data described above:
Disposition-Notification-To, Message-ID, From, and To. Other
headers described above used in a MDN should be included,
for example, Date and Subject.
The MDN receipt of the response data is returned using a
subsequent POST operation. A POST operation used only to transmit
an MDN MUST NOT include the Disposition-Notification-To receipt
request, and only a 200 ("OK") response would be expected.
An MDN in response to a reply may be combined with a subsequent
EDI message sent with a POST operation, for example a
Purchase-Order transaction in response to a Quote. The MIME
multipart/mixed form is used to combine the MDN with the other
data, the same as for a POST reply.
Moberg, Brooks, Drummond, Fischer [page 17]
HTTP Transport for Secure EDI May 2002
2.8 Error Recovery
If the HTTP client fails to read the HTTP server response data,
the POST operation with identical content (including Message-ID,
RefNum, and other header elements) should be repeated, if the
error condition is transient.
The Message-ID or RefNum on a POST operation can be reused if
and only if all of the content (including the original Date)
is identical.
Details of the retry process -- including time intervals to
pause, number of retries to attempt, timeouts for retrying --
are implementation dependent.
Servers should be prepared to receive a POST with a repeated
Message-ID. The MIME reply body previously sent should be resent,
including the MDN and other MIME parts.
3. Other differences to notice in HTTP and SMTP based transport
For HTTP version 1.1, TCP persistent connections are the
default, ([HTTP] sections 8.1.2, 8.2, and 19.7.1). A number
of other differences exist because HTTP does not conform to
MIME [MIME] as used in SMTP transport. Relevant differences
are summarized below.
3.1 Unused MIME headers and operations
3.1.1 Content-Transfer-Encoding not used in HTTP transport
HTTP can handle binary data and so there is no need to use
the Content transfer encodings of MIME [MIME]. This difference
is discussed in [HTTP] section 19.4.4.
3.1.2 Epilogue must be empty
The EBNF for a multipart [MIME] RFC 2046, section 5.1.1 allows
a multipart to have trailing octets after the close delimiter.
In [HTTP] section 3.7.2, it is explicitly noted that multiparts
must have null epilogues.
3.1.3 Lengthy message bodies
In [AS1], section 5.4.1, options for large file processing are
discussed for SMTP transport. For HTTP, large files should be
handled correctly by the TCP layer. However, [HTTP] sections
3.5 and 3.6 discuss some options for compressing or chunking
entities to be transferred. Section 8.1.2.2 discusses a
pipelining option that is useful for segmenting large
amounts of data.
Moberg, Brooks, Drummond, Fischer [page 18]
HTTP Transport for Secure EDI May 2002
3.2 Differences in MIME or other headers or parameters used
3.2.1 Content-Length
Because connections are persistent, closing a connection cannot
be used to indicate the end of an entity. Therefore, [HTTP]
sections 4.4 and 14.14 indicate the need for a Content-Length
entity header in a request.
3.2.2 Final and Original Recipient
The final and original recipient distinction should not
arise for HTTP transport because SMTP aliases and mailing
lists should not be used.
3.2.3 Message-Id and Original-Message-Id
The Message-Id and Original-Message-Id distinction should not
arise for HTTP transport because SMTP MTA alterations should
not occur. Message-Id is formatted as defined in RFC2822:
"<" id-left " <at> " id-right ">" (RFC2822 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,
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.
3.2.4 Host header
The host request header field must be included in the
POST request made when sending business data. This field
is to allow one server IP address to service multiple
hostnames, and potentially conserve IP addresses.
See [HTTP], sections 14.23 and 19.5.1.
Moberg, Brooks, Drummond, Fischer [page 19]
HTTP Transport for Secure EDI May 2002
4. Additional AS2 specific HTTP headers
The following headers are to be included in all AS2 messages
and all AS2 MDNs.
4.1 AS2 Version Header
To promote backward compatibility AS2 includes a version:
AS2-Version: 1.0
This header MUST be present on all AS2 messages and AS2
MDNs, but not in a single line response (see section 2.4).
Receiving systems MUST NOT fail due to the absence of the
AS2-Version header. This would indicate the message is from
an older system.
4.2 AS2 System Identifiers
The receiving system needs to obtain the identity of the sending
system. This may be company specific, such as DUNS number, or it
may be simply an identification string agreed upon between the
trading partners. The two AS2 headers are:
AS2-From: < AS2-quoted-string >
AS2-To: < AS2-quoted-string >
These AS2 headers contain textual values, as described below,
identifying the sender/receiver of a data exchange. This
information MUST appear either in the AS2-From/AS2-To headers
or in the GISB Form-Data; name="from"/"to" (see appendix B).
AS2-qtext = %d32-33 / ; space & bang, printable ASCII
%d35-91 / ; characters not including "\"
%d93-126 ; or the double-quote character
AS2-quoted-pair = <\> <\> / <\> <"> ; backslash or DQUOTE
; \\ \"
AS2-name = 1*128 ( AS2-qtext / AS2-quoted-pair )
AS2-quoted-string = AS2-name / <"> AS2-name <">
The AS2-From header value and the AS2-To header value MUST
each be an AS2-quoted-string, MUST each be comprised of
from 1 to 128 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.
Moberg, Brooks, Drummond, Fischer [page 20]
HTTP Transport for Secure EDI May 2002
4.2.1 Rules for using the AS2-To and AS2-From headers
1. If an AS2-name contains no contiguous embedded SP characters
( 2* SP ), AS2 systems SHOULD use the first form
( no quotes ) for the AS2-quoted-string, in order to
provide maximum compatibility with earlier AS2 systems.
2. If an AS2-name contains contiguous embedded SP characters,
AS2 systems SHOULD use the second form ( quoted ) for the
AS2-quoted-string, in order to provide protection from
contiguous-LWSP substitution by an intermediary HTTP proxy
or server ( cf. RFC 2616 #2.2 ).
3. AS2 systems MUST accept as valid both forms of the
AS2-quoted-string, whether or not the AS2-name contains
contiguous embedded SP characters.
4. AS2 systems that receive an AS2-quoted-string of the
first form ( no quotes ) MAY assume the first significant
character of the AS2-name is the first non-LWSP character
after the extensions header label ( "AS2-From:" or
"AS2-To:" ) and that the last non-LWSP character before the
line termination characters (CRLF) is the last significant
character of the AS2-name.
5. AS2 systems that receive an AS2-quoted-string of the
second form ( quoted ) MAY interpret all characters between
the quotation marks as belonging to the AS2-name. Therefore,
AS2 systems that send messages using the second form
( quoted ) for AS2-names, SHOULD NOT include leading or
trailing SP characters within the quotation marks, as
receiving systems may interpret these characters as
significant.
6. As is explicit in the definition of the AS2-name, an
embedded reverse solidus ( "\" or backslash ) or an
embedded double-quote MUST be represented using the
quoted-pair scheme. Only these two quoted-pair belong to
the AS2-quoted-pair set. Any other quoted-pair is invalid
in an AS2-name.
4.2.2 Unrecognized System Identifiers
If either the AS2-From or the AS2-To or the combination of both
header values is determined to be invalid or unknown by the
receiving system, the receiving system MAY respond in one of
the following ways, but is not limited to these options:
1. The receiving AS2 system MAY disconnect from the
sending AS2 system before completing the reception of
the entire entity if it determines the HTTP headers
do not represent a valid trading-relationship.
Moberg, Brooks, Drummond, Fischer [page 21]
HTTP Transport for Secure EDI May 2002
2. The receiving AS2 system MAY disconnect from the
sending AS2 system before completing the reception
of the entire entity if it determines the entity
being sent is too large to process.
3. The receiving AS2 system MAY return an HTTP response
with a response code in the 2xx range, with or without
any explanation of the error, even if the sending
system requested an MDN.
4. The receiving AS2 system MAY return an unsigned MDN
with an explanation of the error, if the sending
system requested an MDN.
Appendices
A. AS2 MIME templates
Structure of an AS2 MIME message - PGP/MIME
No encryption, no signature (analog of 4.2.1)
-RFC2068/2045
-RFC1767/RFC2376 (application/EDIxxxx or /xml)
No encryption, signature (analog of 4.2.2)
-RFC2068/2045
-RFC1847 (multipart/signed)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)
-RFC2015 (application/pgp-signature)
Encryption, no signature (analog of 4.2.3)
-RFC2068/2045
-RFC1847 (multipart/encrypted)
-RFC2015 (application/pgp-encrypted)
-"Version: 1"
-RFC2015 (application/octet-stream)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
Encryption, signature (analog of 4.2.4)
-RFC2068/2045
-RFC1847 (multipart/encrypted)
-RFC2015 (application/pgp-encrypted)
-"Version: 1"
-RFC2015 (application/octet-stream)
-RFC1847 (multipart/signed)(encrypted)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
-RFC2015 (application/pgp-signature)(encrypted)
Moberg, Brooks, Drummond, Fischer [page 22]
HTTP Transport for Secure EDI May 2002
Structure of an AS2 MIME message - S/MIME
No encryption, no signature (analog of 4.3.1)
-RFC2068/2045
-RFC1767/RFC2376 (application/EDIxxxx or /xml)
No encryption, signature (analog of 4.3.2)
-RFC2068/2045
-RFC1847 (multipart/signed)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)
-RFC2633 (application/pkcs7-signature)
Encryption, no signature (analog of 4.3.3)
-RFC2068/2045
-RFC2633 (application/pkcs7-mime)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
Encryption, signature (analog of 4.3.4)
-RFC2068/2045
-RFC2633 (application/pkcs7-mime)
-RFC1847 (multipart/signed)(encrypted)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
-RFC2633 (application/pkcs7-signature)(encrypted)
B. AS2 Extensions for the GISB Protocol and Report-type
GISB AS2 Profile
The United States based Gas Industry Standards Board (GISB) is a
consortium of companies and individuals that operate in the Gas
Industry. The membership is divided into 5 sectors, Producers,
Pipelines, Services, End Users, Local Distribution Companies,
representing the various type of organizations within the
industry. In 1996 GISB initiated a program to move from the
expensive Value Added Networks they were using, to the Internet.
By October of 1996GISB had developed and tested a protocol,
called GISB Electronic Delivery Mechanism (EDM), which uses HTTP
and is based on RFC1867 (Form-based File Upload in HTML). By
May 1997 this protocol was being used by Enron and others to
send/receive live, mission critical business transactions over
the Internet. Additional companies followed suit and a large
percentage of today's business transactions in the Gas Industry
are transmitted over the Internet using the GISB EDM protocol. In
1998 the Automobile Industry Action Group (AIAG) adopted the GISB
EDM protocol and in 1999 the local electric companies serving the
state of Pennsylvania declared the GISB protocol as their
standard for transmitting business transactions via the Internet.
Moberg, Brooks, Drummond, Fischer [page 23]
HTTP Transport for Secure EDI May 2002
In May of 1999 the AIAG, GISB and members of the IETF EDIINT
workgroup initiated an effort to converge their independent
specifications, the result of which is this specification. In
order to bring the GISB EDM into compliance with this
specification GISB initiated a formal change to the EDM
specification. The following information, referred to as the
"GISB AS2Profile", reflects the planned utilization of this
specification by the GISB membership.
The GISB membership will utilize PGP to meet all P.A.I.N.
requirements. All data exchanges will utilize the multipart/form-
data enveloping method and two generalized receipts,
GISB-Acknowledgement-Receipt and GISB-Error-Notification. All
original business transactions must be digitally signed (using
encapsulated signatures) and encrypted using RSA algorithms. Upon
successful transfer of an original business transaction the
receiver is required to send a GISB-Acknowledgement-Receipt
indicating that the transfer has completed successfully. If, upon
further processing of the business document an error is
encountered a GISB-Error-Notification is sent to the original
sender using the multipart/form-data enveloping.
It is expected that companies following the GISB AS2 profile will
protect their web sites from unauthorized access through the use
of basic authentication (username/passwords), as defined in the
HTTP specification. GISB is not "requiring" the use of signed
receipts; however, signed receipts are allowed between consenting
trading partners. GISB has decided to use the following core
headers:
FROM:
Contains the DUNS number of the sending party
TO:
Contains the DUNS number of the intended recipient
INPUT-FORMAT:
Type of data being sent (only x12 and error currently
supported) other options can easily be added to this list.
INPUT-DATA:
The actual payload containing the business transaction or
GISB-Error-Notification. If the payload contains a business
transaction it is signed and encrypted using PGP.
Version:
The GISB version number (currently 1.3)
RECEIPT-DISPOSITION-TO:
The DUNS number of the party to receive the
GISB-Acknowledgement-Receipt (typically the same DUNS
number associated with the From header.) Presence of this
Moberg, Brooks, Drummond, Fischer [page 24]
HTTP Transport for Secure EDI May 2002
field also serves as a flag indicating that an
acknowledgement receipt is requested by the sender. The
receipt is returned synchronously (on the same session
used to send the input-data payload).
RECEIPT-REPORT-TYPE:
Contains the value GISB-Acknowledgement-Receipt.
Optional headers also available:
TRANSACTION-SET:
Identifies the type of transaction contained in the
input-data payload.
RECEIPT-SECURITY-SELECTION:
This field serves as a flag indicating that a signed
receipt is being requested. The contents of this field
indicate the algorithm and signature type to use in
constructing the signature.
Example of a GISB data exchange:
The sending party creates an X12 business transaction and
concatenates with an RFC 1767 compliant header. The entire
package is then encrypted and signed using PGP. The encrypted
package is then enveloped with the appropriate headers/values
and sent to the trading partner using HTTP POST, the contents
of this post appear as follows:
POST c:\execute HTTP/1.0
Referer: http://www.get.a.life/upl.htm
Connection: Keep-Alive
User-Agent: brow v0.1 XYZ Corp.
Host: localhost
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Content-type: multipart/form-data;
boundary=---------------------------87453838942833
Content-Length: 5379
-----------------------------87453838942833
Content-Disposition: form-data; name="from"
123456789
-----------------------------87453838942833
Content-Disposition: form-data; name="to"
234567890
-----------------------------87453838942833
Content-Disposition: form-data; name="Version"
1.3
Moberg, Brooks, Drummond, Fischer [page 25]
HTTP Transport for Secure EDI May 2002
-----------------------------87453838942833
Content-Disposition: form-data; name="receipt-disposition-to"
123456789
-----------------------------87453838942833
Content-Disposition: form-data; name="receipt-report-type"
GISB-Acknowledgement-Receipt
-----------------------------87453838942833
Content-Disposition: form-data; name="input-format"
x12
-----------------------------87453838942833
Content-Disposition: form-data; name="input-data";
filename=c:\temp\smallnom.bin
Content-Type: multipart/encrypted; boundary=9876;
protocol="application/pgp-encrypted"
--9876
Content-Type: application/pgp-encrypted
Version: 1
--9876
Content-Type: application/octet-stream
-----BEGIN PGP MESSAGE-----
Version: PGP 6.5
hQCMAzRG1pEOIOvdAQP+JMr0m/9+8yOL60Z9Vr6fFV81FCExB/o0xmwiMkiwYsHs
z0e8sb7ErC340MrNA/dw3taGMjmI+CXYRF/PLEdg1NZE1ZCtNeL4YdIHAMLWwODG
lQxhSucz8rMSgQ5mZzcOJwBdWLW70efgsu/9UljuJjYc1uZ6C03eFQv/43fkB+al
ATtgydxX4g8QK664ad+Jo/XUICSmWBL66fqJR1KLeLf4wTaqGy174Aq48Wpwvg1E
h785zC03UAw0qg0ugMt86dPeyd91e2JigqwDYEf/DYEKD0J9BGiGpS/uAupNKj8O
aqx2Dq/ra9g65HNchOCzjul5Vi8HHf6Yhg2WnROe+npByyCue6rihqgNVOJwj0cV
zpb4JE+gMDf3q4ISUb1Fv7/+SSFHDdnhdC5YTpqf1Bc3B07hiLmtTXqNit31EbX9
UVElObzSa9ZhxbC6/eSl7Nuf5ZTDsh9nrk+QQJ6FeC9W4cqXLj7IZySaRO8Vtff+
4ktqeuhYusT4kSpnk027aw4O/5jomUkfb22CAe4=
=Oiuo
-----END PGP MESSAGE-----
--9876--
-----------------------------87453838942833--
Upon receiving the above stream of data the receiving host
parses the headers and returns an unsigned
GISB-Acknowledgement-Receipt, appearing as follows:
Content-Type: multipart/report;
report-type="GISB-Acknowledgement-Receipt"; boundary="GISB7867"
Moberg, Brooks, Drummond, Fischer [page 26]
HTTP Transport for Secure EDI May 2002
--GISB7867
Content-type: text/html
<HTML><HEAD><TITLE>Acknowledgement Receipt Success</TITLE></HEAD>
<BODY><P>
time-c=19960619082855*
request-status=ok*
server-id=coolhost*
trans-id=234423897*
</P> </BODY></HTML>
--GISB7867
Content-type: text/plain
time-c=19960619082855*
request-status=ok*
server-id=coolhost*
trans-id=234423897*
--GISB7867--
C. Samples of AS2 Protocol Data Units
C.1 The following example illustrates the full HTTP request that
sends X12 EDI data from company1 to company2. A signed receipt is
requested; the receipt is to be a MDN report-type, with the pkcs7
signature option, using a signature algorithm of rsa-md5.
The receipt is to be sent synchronously (that is, in the reply to
this HTTP request), because no special delivery options are
indicated.
POST https://tp2server.company2.com/cgi-bin/tp1drawer.pl HTTP/1.1
Host: tp2server.company2.com
AS2-To: zzzcompany2
AS2-From: zzzcompany1
AS2-Version: 1.0
From: ediadmin <at> company1.com
Date: Tue, 06 Nov 2001 12:53:01 UT
Subject: Purchase orders for 6 November 2001
Message-Id: <20011106 <at> company1.com>
Disposition-Notification-To: tp1 <at> company1.com
Disposition-Notification-Options: signed-receipt-protocol=optional,
pkcs7-signature; signed-receipt-micalg=optional,rsa-md5
Content-Type: multipart/signed; boundary="20011106RsXgYlvCNW";
protocol=application/pkcs7-signature; micalg=rsa-md5
Content-Length: 3056
--20011106RsXgYlvCNW
Content-Type: application/edi-x12
Content-Disposition: Attachment; filename=rfc1767.dat
Moberg, Brooks, Drummond, Fischer [page 27]
HTTP Transport for Secure EDI May 2002
[ISA ...EDI transaction data...IEA...]
--20011106RsXgYlvCNW
Content-Type: application/pkcs7-signature
[omitted binary pkcs7 signature data]
--20011106RsXgYlvCNW--
C.2 This second example illustrates returning a signed MDN
that corresponds to the request for a MDN found in C.1.
HTTP/1.0 200 OK
Server: HTTPEDI/1.1
AS2-To: zzzcompany1
AS2-From: zzzcompany2
AS2-Version: 1.0
Content-type: multipart/signed; boundary="boundary1"
Content-Length: 1200
--boundary1
Content-type: multipart/report; boundary="boundary2"
--boundary2
Content-type: text/plain
Message <20011106 <at> company1.com> was authenticated;
EDI processing was initiated.
--boundary2
Content-type: message/disposition-notification
Reporting-UA: Company2UA
Final-Recipient: rfc822; tp2 <at> company2.com
Original-Message-Id: <20011106 <at> company1.com>
Received-Content-MIC: w7AguNJEmhF/qIjJw6LnnA==, rsa-md5
Disposition: MDN-sent-automatically/processed
--boundary2--
--boundary1
Content-Type: application/pkcs7-signature
[Signature data omitted]
--boundary1--
D. Acknowledgments
Carl Hage, Karen Rosenfeld, Chuck Fenton and many others have
provided valuable suggestions improving this applicability
statement.
Moberg, Brooks, Drummond, Fischer [page 28]
HTTP Transport for Secure EDI May 2002
E. References
[ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997
[AS1] T. Harding, R. Drummond, C. Shih, "Peer-to-Peer
MIME-based Secure Business Data Interchange", April 2002,
Internet draft: draft-ietf-ediint-as1-17.txt.
[CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630,
June 1999.
[FORMDATA] L. Masinter, "Returning Values from Forms:
multipart/form-data", RFC 2388, August, 1998.
[GISB] Gas Industry Standards Board, "Electronic Delivery
Mechanism Related Standards", Version 1.3 July 31, 1998
[HTML] D. Raggett, A. Le Hors, I. Jacobs. "HTML 4.0
Specification", World Wide Web Consortium Technical Report
"REC-html40", December, 1997. <http://www.w3.org/TR/REC-html40/>
[HTTP] R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners-Lee,
"Hypertext Transfer Protocol--HTTP/1.1", RFC 2068, March 1997.
[MIME] N. Borenstein, N. Freed, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, December 02, 1996.
N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types", RFC 2046, December 02, 1996.
N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions
(MIME) Part Five: Conformance Criteria and Examples", RFC 2049,
December 02, 1996.
[MIMEEDI] D. Crocker, "MIME Encapsulation of EDI Objects", RFC
1767, March 2, 1995.
[MIMEPGP] M. Elkins, "MIME Security With Pretty Good Privacy
(PGP)", RFC 2015, Sept. 1996.
[MDN] R. Fajman, "An Extensible Message Format for Message
Disposition Notifications", RFC 2298, March 1998.
[SECURITY] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, Oct. 3, 1995
[SMTP] P. Resnick, Editor "Internet Mail Format", RFC 2822,
April 2001.
Moberg, Brooks, Drummond, Fischer [page 29]
HTTP Transport for Secure EDI May 2002
[SMIMEV2] S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L.
Repka, "S/MIME Version 2 Message Specification", RFC 2311.
[SMIMEV3] B. Ramsdell, "S/MIME Version 3 Message Specification",
RFC 2633, June 1999.
[REPORT] G. Vaudreuil, "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC 1892,
March 15, 1996.
[TLS] T. Dierks,C. Allen, "The TLS Protocol Version 1.0" RFC 2246,
March 1999.
[MIME-TYPES] "Media Types," http://www.isi.edu/in-
notes/iana/assignments/media-types/media-types.
[XMLTYPES] E. Whitehead, M. Murata, "XML Media Types", RFC 2376,
July 1998.
F. Security Considerations
This entire document is concerned with secure transport of
business to business data and considers both privacy and
authentication issues.
G. Authors' Addresses
Dale Moberg
dale_moberg <at> cyclonecommerce.com
Cyclone Commerce
8388 E. Hartford Drive
Scottsdale, AZ 85255 USA
Dick Brooks
dick.brooks <at> systrends.com
Systrends, Inc
7855 South River Parkway, Suite 111
Tempe, Arizona 85284 USA
Rik Drummond
rik <at> drummondgroup.com
Drummond Group
5008 Bentwood Ct.
Fort Worth, TX 76132 USA
David Fischer
david <at> drummondgroup.com
Drummond Group
4200 S. Hulen St. Suite 600
Fort Worth, TX 76109 USA
Moberg, Brooks, Drummond, Fischer [page 30]

EDIINT Working Group Dale Moberg
Internet draft Dick Brooks
Expires: November 2002 Rik Drummond
David Fischer
May 2002
HTTP Transport for Secure Peer-to-Peer
Business Data Interchange over the Internet
draft-ietf-ediint-as2-11.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in an Internet-
Drafts Shadow Directory, see http://www.ietf.org/shadow.html.
Any questions, comments, and reports of defects or ambiguities in
this specification may be sent to the mailing list for the EDIINT
working group of the IETF, using the address
<ietf-ediint <at> imc.org>. Requests to subscribe to the mailing list
should be addressed to <ietf-ediint-request <at> imc.org>.
Abstract
This document describes how to exchange structured business data
securely using HTTP transport for Electronic Data Interchange,
(EDI - either the American Standards Committee X12 or UN/EDIFACT,
Electronic Data Interchange for Administration, Commerce and
Transport), XML or other data used for business to business data
interchange. The data is packaged using standard MIME
content-types. Authentication and privacy are obtained by using
Cryptographic Message Syntax (S/MIME) or OpenPGP security body
parts. Authenticated acknowledgements make use of
multipart/signed replies to the HTTP POST requests.
This document extends the procedures and payload packaging options
of AS1 in the following ways: HTTPS may be used to obtain data,
privacy both synchronous and asynchronous reply procedures are,
described multipart/form-data packaging may be used, a generalized
Moberg, Brooks, Drummond, Fischer [page 1]
HTTP Transport for Secure EDI May 2002
multipart/report format is added to the MDN format of AS1, replies
may include a multipart/mixed payload that contains both the
acknowledgement and an additional EDI payload.
This document is intended to be read in conjunction with AS1 and
the referenced RFCs defining the MIME and cryptographic
packaging that are used to obtain secure, authenticated, and
acknowledged transport.
Feedback Instructions:
NOTE TO RFC EDITOR: This section should be removed
by the RFC editor prior to publication.
If you want to provide feedback on this draft, follow these
guidelines:
- Send feedback via e-mail to the ietf-ediint list for discussion,
with "AS#2" in the Subject field. To enter/follow the
discussion, you need to subscribe at ietf-ediint <at> imc.org.
- Be specific as to what section you are referring to, preferably
quoting the portion that needs modification, after which you
state your comments.
- If you are recommending some text to be replaced with your
suggested text, again, quote the section to be replaced, and be
clear on the section in question.
Table of Contents
1. Introduction
1.1 Purpose and relation to previous work
1.2 Overall operation
2. Stages and Details of HTTP Transmission and Acknowledgment
2.1 Requesting Receipts
2.1.1 Requesting MDN-based receipts
2.1.2 Requesting Generalized receipts
2.1.2.1 Additional Commonly Used Headers
2.1.3 Summary Remarks on Receipt request options
2.2 Sending EDI in HTTP POST Requests
2.3 Using Transport Layer Security
2.4 Response Status Codes in Replies
2.5 Receipt Reply
2.5.1 MDN Receipts and Signed MDN Receipts
2.5.2 Generalized Receipts and Signed Receipts
2.6 Additional Reply Content
2.7 Non-Repudiation of the POST Reply
2.8 Error Recovery
3. Other differences between HTTP and SMTP based transport
3.1 Unused MIME headers and operations
3.1.1 Content-Transfer-Encoding not used
Moberg, Brooks, Drummond, Fischer [page 2]
HTTP Transport for Secure EDI May 2002
3.1.2 Epilogue must be empty
3.1.3 Lengthy message bodies
3.2 Differences in MIME or other headers or parameters used
3.2.1 Content-Length
3.2.2 Final Recipient and Original Recipient
3.2.3 Message-Id and Original-Message-Id
3.2.4 Host header
4. Additional AS2 specific HTTP headers
4.1 AS2 Version Header
4.2 AS2 System Identifiers
4.2.1 Rules for using the AS2-To and AS2-From headers
4.2.2 Unrecognized System Identifiers
A. AS2 MIME templates.
B. Using AS2 Extensions in the GISB Protocol
C. Samples of AS2 Protocol Data Units
D. Acknowledgments
E. References
F. Security Considerations
G. Authors' Addresses
1. Introduction
1.1 Purpose and relation to previous work
Early work on Internet EDI focused on specifying MIME content
types for EDI data [MIMEEDI] The functional requirements
document , "Requirements for Interoperable Internet EDI,"
[EDIINT] provides extensive information on EDI security and the
business and user processes that can benefit from the use of EDI
security. In addition, MIME structures appropriate for SMTP
transport of the packaged EDI data are specified in ([AS1]
"MIME-based Secure EDI") as well as the details needed to
support signed receipts as acknowledgments. The framework of
[AS1] shows how to implement the security features--specifically
data privacy, data integrity/authenticity, non-repudiation of
origin and non-repudiation of receipt --found to be requirements
for secure EDI.
In this document, it is assumed that the reader is familiar
with the SMTP/MIME transport document, the requirements document,
and the RFCs applied or referenced in those documents.
This draft, like the SMTP/MIME transport document, builds on
previous RFCs and is attempting to "re-invent" as little as
possible. The goal here is to specify how previously specified
MIME messaging structures and operations can be adapted for use
with HTTP servers and clients to obtain secure, reliable, and
acknowledged transport for EDI and other business data.
The applicability statement, [AS1] "MIME-based Secure EDI,"
Moberg, Brooks, Drummond, Fischer [page 3]
HTTP Transport for Secure EDI May 2002
explained the basic EDI transaction using the concept of a
"secure transmission loop" for EDI. This loop involves one
organization sending a signed and encrypted EDI interchange to
another organization, requesting a signed receipt, followed by
the receiving organization sending this signed receipt back to
the sending organization. The transmission therefore involves
the following stages:
1. The organization sending business data encrypts the data
and provides a digital signature, using either PGP/MIME or
S/MIME. In addition, they request a signed receipt.
2. The receiving organization decrypts the message and
verifies the signature, resulting in verified integrity of
the data and authenticity of the sender.
3. The receiving organization then sends a signed receipt
using a signature over the hash of a message disposition
notification, which contains a hash of the received message.
The above stages describe the functionality that would
satisfy all security requirements. Applications are expected
to be able to provide full functionality, though users may
agree to exchange data using only a restricted subset of
functionality. For example, businesses may agree to send signed
data using TLS, and only request a simple, unsigned receipt.
Implementations are expected to be configurable so that they may
support business community agreements that use subsets
of the full functionality.
In this document, the goal is to make use of HTTP instead of SMTP
as a transport protocol, and make the changes that are needed to
adapt to protocol packaging differences.
In either transport case, the body of the message is a MIME
structure, using MIME headers ("content-type" and other
"content-X" tags) to convey information about the data
being transported.
Also, one primary use of SMTP RFC 822 headers within SMTP based
transport of secure EDI has been to enable requests for
acknowledgements and to specify options for signatures over
acknowledgements (asymmetric encryption and cryptographic
hash algorithm preferences).
One way to convey this information within the HTTP transport
context is to use either HTTP entity-headers or extension-headers
[11, section 7.1] that have the syntax of SMTP headers. Only the
"From" header is overloaded by possibly different usages in the
SMTP and HTTP contexts. The "From" header normally contains
machine-usable email addresses as defined in [SMTPMSG]. The
Moberg, Brooks, Drummond, Fischer [page 4]
HTTP Transport for Secure EDI May 2002
usage of the "From" header in [HTTP] section 14.22 is to provide
the email address of an administrative contact for the HTTP
client. The function of the "From" header in the SMTP context of
secure EDI transport has been to supply a value used in
constructing the MDN style receipt. But the MDN receipt has been
found to be too restrictive for some commercial EDI transport
scenarios [GISB]. So alternative receipt mechanisms will be
provided that, among other things, will remove any conflicts
arising from trying to reuse the SMTP-MDN roles of
"From" within the context of HTTP reserved usage of "FROM".
Also, it is currently difficult to make use of HTML [HTML]
and simple scripting to send HTTP entity-headers as part of the
HTML FORM tag construct. For HTML-based POST situations [GISB],
it is useful to specify ways to convey 'metadata' needed for the
secure transmission loop that do not make use of HTTP headers.
One way to specify this data is by using the MIME
multipart/form-data packaging specified in [FORMDATA].
For SMTP transport, the receipt and signed receipt functions are
implemented using Message Disposition Notifications [MDN]
and Multipart/signed Message Disposition Notifications [AS1].
For HTTP transport, generalization of the Message Disposition
Notification is useful.
The MDN is a special kind of multipart/report [REPORT]. For
MDNS, specialization is achieved by assigning the "report-type"
parameter in the content-type header the special value,
"disposition-notification" and by having the second body part
(the "machine-readable" body part) have the MIME content-type,
"message/disposition-notification".
To generalize a MDN, all that is needed is to remove the
restrictions that make the underlying multipart/report into a
MDN. In other words, the "report-type" parameter [REPORT,
section 1] is given a new value and the second body part is
changed to a content-type other than "message/disposition-
notification". Acknowledgements defined by these changes will be
referred to as "generalized receipts. Each receipt of this kind
will have its own specific report-type parameter and its own
specifications for the syntax and semantics of the automated
response body part. Implementations are encouraged to be able to
register new report-type handlers using only configuration
changes (not recompiling) that specify how to process new report-
type values.
Nothing else needs to be changed to construct reply
acknowledgements that are not restricted by the semantics of
MDNs. Specifically, a signed reply will still be constructed by
using a multipart/signed package to wrap up generalized receipts
with their signatures.
Finally, within the HTTP transport context, it is useful to make
Moberg, Brooks, Drummond, Fischer [page 5]
HTTP Transport for Secure EDI May 2002
use of Transport Layer Security [TLS] to provide privacy.
Compression can be provided using HTTP content-codings [HTTP],
sections 3.5, 14.3, 14.12]. (Content codings are not to be
confused with the MIME concept of content transfer encodings.)
A variety of other minor differences (for example, absence of
content-transfer-encoding) are noted below and summarized in the
concluding section.
1.2 Overall operation
A HTTP POST operation [HTTP] is used to send appropriately
packaged EDI, XML, or other business data. The Request-URI
([HTTP],section 9.5) identifies a process to unpack and handle
the message data and to generate a reply for the client that
contains a message disposition acknowledgement or a multipart/
report, signed or unsigned, and possibly other turnaround
transactions. This request/reply transactional interchange
provides secure, reliable, and authenticated transport for EDI
or other business data using HTTP; the security protocols and
structures used also support auditable records of these
transmissions, acknowledgements, and authentication.
2. Stages and Details of HTTP Transmission and Acknowledgment
A data file or stream is first structured into one of the
message templates described in [AS1], sections 4.2.1 to 4.2.4 or
4.3.1 to 4.3.4 for PGP/MIME or S/MIME security. In addition
to the content-types of [MIMEEDI], applications should be
prepared for handling other content-types used in business to
business transactions, such as those for XML [MIME-TYPES].
For convenience, these message templates, adapted for the
HTTP transport context, are provided in Appendix A.
If TLS is to be used, the typical packaging will be that
described in sections 4.2.2 or 4.3.2; that is, a multipart/signed
message will be created with no encryption in the message.
Otherwise, if privacy is desired, message templates 4.2.4 or
4.3.4 are used. Content transfer encoding is not used and
a content-length field is to be provided.
If HTML-based POST is used (using the METHOD=POST attribute
within the "FORM" tag) [HTML, 17 Forms], then the message payload
will be packaged in the input-data element of a multipart/form-
data. The metadata needed for application layer routing,
identification, requesting a reply and other transaction
operations can be packaged in message body parts in the
multipart/form-data. The labels for the metadata values are found
in the "name" parameter of the Content-Disposition header in each
form-data part as discussed in [FORMDATA, section 3].
Moberg, Brooks, Drummond, Fischer [page 6]
HTTP Transport for Secure EDI May 2002
In general, both HTTP servers and HTTP clients handling the
message templates of [AS1] should be prepared to process these
basic EDIINT data formats when they are embedded within MIME
multiparts. In addition to the enveloping and MIME media type
options defined in sections 4.2.x and 4.3.x of "MIME-based
Secure Peer-to-Peer Business Data Interchange over the
Internet" [AS1], this specification enables the transport of
payload objects containing other MIME media types. Implementors
are to follow the appropriate specifications identified under
"References" in [MIME-TYPES], for the type of object being
transmitted. For example, to send an XML object, the MIME media
type of application/xml is used in the Content-type MIME header
and the specifications for enveloping the object are contained
in [XMLTYPES]; for example:
Content-type: application/xml; charset="utf-8"
Many of the specifications referenced by [MIME-TYPES] were
designed for SMTP transports. Implementors are advised to make
appropriate adjustments for HTTP transport as indicated in
section 4 of this document.
Finally, several industry groups currently make use of
"encapsulated"(or opaque) signatures within encrypted or
signed objects. Encapsulated signatures should be supported
in order to accommodate these existing practices. Objects
containing encapsulated signatures must be prepared according
to the specifications contained in section 3.4.2 of [SMIMEV2]
or, in the case of PGP, according to the specifications contained
in section 6.2 of "MIME Security with Pretty Good Privacy (PGP)"
[MIMEPGP] and "OpenPGP Message Format" [RFC2440].
2.1 Requesting Receipts
2.1.1 Requesting MDN-based receipts
For requesting MDN based receipts, the originator supplies
metadata using the syntax of extension headers (the [SMTPMSG]
header syntax) that precede the message body.
The header "tags" are as follows:
A Disposition-Notification-To header is added to indicate
that a message disposition notification is requested
in the reply to the POST request. This header is
specified in [MDN]. It may have values other than email
addresses, such as a D-U-N-S number, when it is found as a
name parameter in a form-data body part When this tag is used in
HTTP extension headers, it follows the MDN usage.
A Message-ID header is added to support message reconciliation,
so that an Original-Message-Id value can be returned in the MDN
Moberg, Brooks, Drummond, Fischer [page 7]
HTTP Transport for Secure EDI May 2002
body part of the receipt. (The term "Receipts" is here used
to refer to the signed or unsigned multipart/report content.)
Both "From" and "To" extension headers SHOULD be supplied. The
"From" value needs to have an email address as specified in
[SMTPMSG] and [HTTP]. If other uses of "From" are needed, the
generalized receipts to be next discussed should be used. There
the role of "From" is replaced by symbols not having a reserved
HTTP or SMTP usage.
Other headers, especially "Subject" and "Date", should be
supplied; the values of these headers are often mentioned in the
human-readable section of a MDN to aid in identifying the
original message.
A Disposition-Notification-Options header is used to request
a signed message disposition notification. The parameters
used to select protocols for signed message disposition
notification are found in [AS1].
Disposition-Notification-To is a name that, if present,
indicates that the MDN style of receipt is to be used.
Disposition-notification-options identifies characteristics of
message disposition notification in accordance with [AS1] and
[MDN].
A Receipt-delivery-option is a header whose value is a URL
that indicates how the receipt is to be delivered. This header
is only used within AS2. The default mode of operation is
synchronous within HTTP transport, which means that the receipt
(be it MDN, signed MDN, generalized report receipt, or signed
report receipt) is returned in the reply body. By using the
"receipt-delivery-option," an asynchronous reply mode can be
requested. The values for this option are URLs that indicate the
destination for the reply, and may use any appropriate protocol
("mailto", "http", and "https" will be the more common types)
for this information. If this header/metadata is absent, then
the mode of operation is synchronous, which means that the
receipt is returned in the reply to the current HTTP request.
2.1.2 Requesting Generalized Receipts
In this section, the ways to request generalized receipts
are specified. Generalized receipts are multipart/reports
with a report-type other than "disposition-notification," and
a second automated response with a content type other
than "message/disposition-notification".
For requesting generalized receipts using the MIME template for
multipart/reports [REPORTS], the following metadata elements
will be useful. A specific example of a generalized receipt
Moberg, Brooks, Drummond, Fischer [page 8]
HTTP Transport for Secure EDI May 2002
with report-type "GISB-Acknowledgement-Receipt" will be
presented in appendix B.
When the term "metadata" is used in the following, the term
indicates the information may be supplied in one of two ways:
First, the metadata information may be supplied using the
syntax of HTTP headers. That is, the symbol name is
followed by a colon and its value follows; the header
is subject to processing of structured field bodies
[SMTPMSG, section 3.1.4], also including parameters.
Second, the metadata information may be supplied by using
the syntax of the "name" parameter within the
"Content-Disposition" header of the multipart/form-data
structure, when that MIME packaging [FORMDATA] is used.
For example,
--boundaryformdata
Content-Disposition: form-data; name="Receipt-Report-Type"
GISB-Acknowledgement-Receipt
--boundaryformdata
Within HTML, the symbols used for these names correspond to
the value of the name attribute within the INPUT element,
where the "type" attribute has a "text" value. [HTML],
section 18; for example,
<FORM action="http://somesite.com/responder" method="post">
<INPUT type="text" name="Receipt-Report-Type">
<INPUT type="submit" value="Send"> <INPUT type="reset">
</FORM>
To indicate the various options for generalized receipts, the
basic metadata that the POSTing client needs to convey to the
replying server are: "Receipt-Disposition-To", and
"Receipt-report-type", "Receipt-Security-Selection",
"Receipt-Delivery-Option".
The presence of the metadata value "Receipt-Disposition-To",
using the extension header syntax, indicates a request for a
generalized receipt.
Because HTTP already has a role for the "From" header, the
"Receipt-Disposition-To" header is used to avoid conflicts
with [HTTP], when using the header syntax for metadata.
(Within a multipart/form-data package, the "From" value
can be used to identify the sending party without any
conflict with HTTP headers.) Notice that the value for this
identifier need not be an email address or a URL. In this way,
other systems of identification (such as a DUNS number) may be
Moberg, Brooks, Drummond, Fischer [page 9]
HTTP Transport for Secure EDI May 2002
used, if needed. Notice that the information needed for delivery
of the receipt is found in the receipt-delivery-option element
described below; delivery information is not generally needed
if the default mode of operation occurs. In that case, the
receipt just goes back in the reply to the current HTTP request.
"Receipt-Report-Type" indicates the desired value of the
"report-type" parameter in the multipart/report content type of
a specific version of the generalized receipt. This parameter
must be supplied when "Receipt-Disposition-To" is used to
indicate a request for a generalized receipt because this
indicates what specific type of receipt is desired. An example
for this value (discussed in appendix A) is
"GISB-Acknowledgement-Receipt".
"Receipt-Security-Selection" is a name that indicates the
protocol and algorithm choices for a digital signature
over the receipt. Signatures are always in multipart/signed
packages. The format for protocol and algorithm choices is
that used in [AS1] and [MDN]; for example,
Receipt-Security-Selection:
signed-receipt-protocol=optional,pkcs7-signature;
signed-receipt-micalg=optional,rsa-sha1
"Receipt-Delivery-Option" is used to indicate the
URL for asynchronous delivery of the receipt.
While the default mode of operation within HTTP
transport is to return the receipt(be it MDN, signed
MDN, generalized receipt, or signed generalized receipt)
in the reply body, asynchronous reply is allowed through
use of this symbol. The URLs will typically use the
"MAILTO", "HTTP", and "HTTPS" schemes. For the HTTP and
HTTPS schemes, the POST method is to be used.
2.1.2.1 Additional Commonly Used Headers
The following set of header data elements are also available for
use. Organizations wishing to use this specification for the
secure and reliable transport of business documents are not
required to utilize all of these headers and are free to use
whatever subset they deem appropriate for their business needs.
TO:
The To name contains an identifier identifying the
intended recipient of a data exchange and may be
D&B D-U-N-S number [DUNS] or other agreed upon
identifier system. Applications should allow users to
configure these elements in the automated HTTP agents
Moberg, Brooks, Drummond, Fischer [page 10]
HTTP Transport for Secure EDI May 2002
processing these values. For example, the body
part MIME header line looks like the following line:
Content-Disposition: form-data; name="To"
FROM:
The From name contains a textual value identifying the sender
of a data exchange, such as the a D&B D-U-N-S number [DUNS] as
in [GISB]. Because "From" has a specified use within [HTTP],
the From name parameter is not to be considered equivalent
to the extension header. If an extension header "From" is
to be used within HTTP, it should conform to the usage, syntax,
and semantics of [HTTP] section 14.22. The extension header
counterpart of the sender of a data exchange is the extension
header version of "Receipt-disposition-to"
INPUT-FORMAT:
The Input-format name identifies the type of data contained
in a data file.
AGENT:
The Agent name parameter indicates the network or agent
where the data exchange originated.
APPLICATION:
The Application name identifies the application used to process
the data next (after the URI-request process has finished with
the stream).
DATETIME:
The DateTime name provides the date and time the data was
created and uses the format specified in [SMTPMSG] as updated
by RFC 1123.
REFNUM:
The RefNum is an integer value used to uniquely identify the
communication exchange and is in a textual format. The RefNum is
similar to the Message-ID and Content-Id headers of SMTP that
are used in constructing values in receipts based on MDNs.
USERPARAM:
The UserParam is a user-defined parameter.
Version:
Version is a protocol version number [GISB].
TRANSACTION-SET:
Transaction-set is an optional data element identifying the
EDI transaction.
INPUT-DATA:
Input-data is the sending side's local file system name
Moberg, Brooks, Drummond, Fischer [page 11]
HTTP Transport for Secure EDI May 2002
for the file being sent. The payload is contained as the body
part of this header element.
PRIORITY:
The "Priority" name is used to indicate the processing priority
of each message relative to other messages sent by a given
party. The value "1" indicates highest priority and a value
of "5" indicates the lowest priority.
EXPIRATION:
The "Expiration" name is used to indicate the date and time at
which a message is no longer transportable. No message delivery
should be attempted beyond the date and time specified in
this value. The date/time format must follow the specifications
contained in section 5 of RFC822.
2.1.3 Summary Remarks on Receipt request options
Applications are encouraged to support handling all metadata
values whether they make use of the name parameter syntax
within a multipart/form-data or whether they use the message
header syntax used in SMTP or HTTP headers [SMTPMSG]. If
metadata items are repeated in extension headers and in
form-data parts, but the values are not the same, the
extension header values will be selected for use.
Because the value in Receipt-Disposition-To may have no
significance for how the receipt is transported, the extension
header "Receipt-delivery-option" is to be used to provide
that information.
The receipt-delivery-option's value should be a URL indicating
the delivery transport destination for the receipt.
The Receipt-delivery-option field is used when asynchronous
delivery is desired. It should not be present if the intention
is to deliver the reply synchronously; synchronous delivery of
the reply is the default mode of delivery.
For signed generalized receipts, an extension header of
"Receipt-security-selection" should be added to indicate the
desired security protocol for the multipart/signed over the
multipart/report.
In summary, the receipt request and construction processes now
have the following options:
1. Receipt requests are made by conveying metadata
values using a syntax of either the name parameter in a
multipart/form-data's Content-Disposition headers or by
using a syntax of HTTP extension headers.
Moberg, Brooks, Drummond, Fischer [page 12]
HTTP Transport for Secure EDI May 2002
2. Both MDN and generalized receipts can be requested using
either syntax. However, using an extension header syntax
and requesting a MDN receipt means restricting the "From"
values to email addresses.
3. Either type of receipt comes in signed or unsigned versions.
4. Finally, receipts may be delivered synchronously (delivered
in the HTTP reply) or asynchronously by using the
"Receipt-delivery-option" header.
2.2 Sending EDI in HTTP Client Requests using POST
For sending EDI, the following protocol elements are typically
present: a request line ([HTTP], section 5.1), entity headers, a
CRLF pair to mark the end of the entity headers, followed by the
message-body.
The request line will have the form: "POST Request-URI HTTP/1.1",
with spaces and followed by a CRLF. The Request-URI is typically
exchanged out of band, as part of setting up a bilateral
trading partner agreement. Applications should be prepared
to deal with an initial reply containing a status indicating a
need for authentication of the usual types used for authorizing
access to the Request-URI ([HTTP], section 10.4.2 and elsewhere).
Automation of this process is not discussed in this document
but might involve obtaining a session URL from a page requesting
authentication and possibly other information about proposed
EDI standard versions and other trading conventions to be used.
The request line is followed by entity headers specifying content
length ([HTTP] section 14.14) and content type [HTTP], section
14.18. The Host request header ([HTTP] sections 9 and 14.23)
is also included.
The entity or extension headers used for requesting a MDN
(unsigned or signed) have previously been mentioned,
as have those ("To" "From" "Message-Id") that are needed as
values for MDN fields or for other receipt requests.
For generalized receipts based on the multipart/report content
type, the metadata can be the values found in extension headers,
but can also be placed in body parts of a multipart/form-data
using "name" parameters in the content-disposition header.
Finally, the payload is found in any of the message patterns
of [AS1] sections 4.2.1 to 4.2.4 or 4.3.1 to 4.3.4 for PGP/MIME
or S/MIME security. These payloads may arrive as the "input-data"
part of the multipart/form-data or may even be enclosed in some
other multipart.
Moberg, Brooks, Drummond, Fischer [page 13]
HTTP Transport for Secure EDI May 2002
2.3 Using Transport Layer Security
To use Transport Layer Security [TLS], the request-URI should
indicate the appropriate scheme value, HTTPS. Usually only a
multipart/signed message body would be sent using TLS, as
encrypted message bodies would be redundant. Encrypted message
bodies are not prohibited, however. For asynchronous receipt
delivery requests, use the "Receipt-delivery-option" header with
a URL value making use of the HTTPS scheme to obtain security
privacy.
2.4 Response Status Codes in Replies
The status line for response to errors in the POST request line
will be provided by a status line with the following protocol
elements present ([HTTP], section 6.1): HTTP version (normally,
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 [HTTP], sections 6.1.1 and throughout section 10.
HTTP/1.1), a status code, reason phrase, and CRLF.
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 [HTTP].
A careful examination of these codes and their semantics
should be made before implementing any retry functionality
that is described below; specifically, retries should not
be made if the error is not transient or if retries are
explicitly discouraged (for real authentication failures,
for example.)
If there are no transfer protocol errors and no MDN is
requested, the one line status response should appear as:
HTTP/1.1 200 OK<CRLF>
<CRLF>
Note that the status code 200 might be anything in the 2xx
range, such as 204 No Content.
2.5 Receipt Reply
The details of the response to the POST command vary depending
upon whether a receipt has been requested and upon what kind
of receipt has been requested.
With no extended header requesting a receipt, and no errors
accessing the request-URI specified processing, the status
line in the Response to the POST request should be in the 200
Moberg, Brooks, Drummond, Fischer [page 14]
HTTP Transport for Secure EDI May 2002
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 condition
at the authentication, decryption or other higher level, the
HTTP status code should indicate success at the HTTP level.
The HTTP server-side application may respond with an unsolicited
multipart/report as a message body that the HTTP client
might not have solicited, but this may be discarded by the
client. Applications should avoid emitting unsolicited receipt
replies because bandwidth or processing limitations might
have led administrators to suspend asking for acknowledgements.
When a Disposition-Notification-To extension header is present
in the POST request entity headers, then entity headers for
the MDN should be included. The content type for the MDN receipt
(multipart/report [REPORT] or multipart/signed [SECURITY])
should be included in the Response entity headers.
The basic responsibilities of responding to requests are
discussed in [AS1] section 5, and in detail within section 5.2.1.
2.5.1 MDN based Receipts and Signed MDN Receipts
Message Disposition Notifications, when used in the HTTP
reply context, will closely parallel a SMTP MDN. For
example, the disposition field is a required element in the
machine readable second part of a multipart/report for a
MDN. The final-recipient-field ([MDN] section 3.1) value
should be derived from the entity headers of the request.
If the "To" field is missing, for signed messages, the value for
Original-recipient may be the email address field from the
signer's X.509 attribute for email addresses, if that value is
available. For a MDN, an application must report the Message-ID
of the request. The human readable part (the first part of the
multipart/report) should include items such as the subject, date
and other information when those fields are present in entity
header fields following the POST request.
The HTTP reply should normally omit the third optional part
of the multipart/report (used to return the original message
or its headers in the SMTP context).
2.5.2 Generalized Receipts and Signed Receipts
For generalized receipts, the multipart/report [REPORT]
or a multipart/signed containing a multipart/report
as the signed data is the basic MIME packaging. Each
generalized receipt needs a value for the multipart/report
parameter, "report-type," a selection of a content-type
Moberg, Brooks, Drummond, Fischer [page 15]
HTTP Transport for Secure EDI May 2002
for its second body part, when signed, a hash value over
a defined portion of the original message and,
when asynchronously delivered, information allowing the
identification of the original POSTed message.
The basic structure of the multipart/report is used so that
the first part is a "human-readable" message concerning the
received message. The second part should be for automated process
utilization. It should at least possess some common Internet
syntax for expressing names and values, such as the [SMTPMSG]
header syntax, XML, or some MIME content type correlated with
automated processing.
The MDN requirements, therefore, are removed for this second
part, but information used in MDNs may be used here. The third
part of the multipart report is usually omitted in the HTTP
context, but could include the extension headers, or even the
entire payload, to provide diagnostic information.
A multipart/signed over a multipart/report is constructed
precisely in the same way as a multipart/signed over a MDN [AS1].
One metadata element should be within the automated part.
This is the Received-Content-MIC (also allowing
X-Received-Content-MIC). This value is constructed and formatted
as described in [AS1] and the syntax should be either RFC822:
Received-Content-MIC: w7AguNJEmhF/qIjJw6LnnA==, rsa-md5
or simple XML
<ReceivedContentMic algid=rsa-md5 encode=base64 >
w7AguNJEmhF/qIjJw6LnnA==
</ReceivedContentMic>
Original-Message-ID: <43141asfioufasd <at> somewhere.com>
Otherwise the automated acknowledgement semantics are left open
to further semantic specification by specific electronic commerce
communities, such as in [GISB]. Each specialization of the
generalized receipt should make use of a specific identifying
value to be placed in the parameter "report-type,"
Any original metadata thought useful to include in the automated
part may be reflected back using "Original-X", as in
Content-Type: multipart/report;
report-type="identifying-value";
boundary="=-Trfds88fd99"
Implementations should attempt to be configurable to allow
for new report-type values to be added; communities can then
Moberg, Brooks, Drummond, Fischer [page 16]
HTTP Transport for Secure EDI May 2002
agree to the specific extensions they need to support application
level routing, transaction identification, timestamps, and
other specialized information about the data they have exchanged.
2.6 Additional Reply Content
In general, both HTTP servers and HTTP clients should be prepared
to process the basic EDIINT data formats when they are embedded
within MIME multiparts. This is true for HTTP request payloads
as well as HTTP reply payloads.
So, as previously mentioned, for HTML-based POSTS, any of the
EDIINT templates described in [AS1], sections 4.2.1 to 4.2.4 or
4.3.1 to 4.3.4 for PGP/MIME or S/MIME security, may be found as
parts of a multipart/form-data. [Consult Appendix A for the
templates adapted for this document.]
In addition, the response to the POST operation may include other
MIME wrapped content besides an MDN Receipt, Signed MDN,
Generalized Receipt or Signed Generalized Receipt. If a receipt
was requested within the POST data, and additional content is to
be returned, the receipt multipart/report must be combined with
the other data using some MIME multipart pattern. Real-time EDI
processing systems may use MIME multipart content-types to
include a response EDI message, for example, a Quote in response
to a Request-For-Quote transaction.
Also, if requested, the sender may request an asynchronous mode
for return of receipt. This mode is indicated by including the
metadata for Receipt-delivery-option as explained above.
2.7 Non-Repudiation of the POST Reply
If the reply to a POST operation needs a MDN receipt for non-
repudiation (for example, the reply includes content other than
a receipt), the top-level headers in the response include
the same headers required for POST data described above:
Disposition-Notification-To, Message-ID, From, and To. Other
headers described above used in a MDN should be included,
for example, Date and Subject.
The MDN receipt of the response data is returned using a
subsequent POST operation. A POST operation used only to transmit
an MDN MUST NOT include the Disposition-Notification-To receipt
request, and only a 200 ("OK") response would be expected.
An MDN in response to a reply may be combined with a subsequent
EDI message sent with a POST operation, for example a
Purchase-Order transaction in response to a Quote. The MIME
multipart/mixed form is used to combine the MDN with the other
data, the same as for a POST reply.
Moberg, Brooks, Drummond, Fischer [page 17]
HTTP Transport for Secure EDI May 2002
2.8 Error Recovery
If the HTTP client fails to read the HTTP server response data,
the POST operation with identical content (including Message-ID,
RefNum, and other header elements) should be repeated, if the
error condition is transient.
The Message-ID or RefNum on a POST operation can be reused if
and only if all of the content (including the original Date)
is identical.
Details of the retry process -- including time intervals to
pause, number of retries to attempt, timeouts for retrying --
are implementation dependent.
Servers should be prepared to receive a POST with a repeated
Message-ID. The MIME reply body previously sent should be resent,
including the MDN and other MIME parts.
3. Other differences to notice in HTTP and SMTP based transport
For HTTP version 1.1, TCP persistent connections are the
default, ([HTTP] sections 8.1.2, 8.2, and 19.7.1). A number
of other differences exist because HTTP does not conform to
MIME [MIME] as used in SMTP transport. Relevant differences
are summarized below.
3.1 Unused MIME headers and operations
3.1.1 Content-Transfer-Encoding not used in HTTP transport
HTTP can handle binary data and so there is no need to use
the Content transfer encodings of MIME [MIME]. This difference
is discussed in [HTTP] section 19.4.4.
3.1.2 Epilogue must be empty
The EBNF for a multipart [MIME] RFC 2046, section 5.1.1 allows
a multipart to have trailing octets after the close delimiter.
In [HTTP] section 3.7.2, it is explicitly noted that multiparts
must have null epilogues.
3.1.3 Lengthy message bodies
In [AS1], section 5.4.1, options for large file processing are
discussed for SMTP transport. For HTTP, large files should be
handled correctly by the TCP layer. However, [HTTP] sections
3.5 and 3.6 discuss some options for compressing or chunking
entities to be transferred. Section 8.1.2.2 discusses a
pipelining option that is useful for segmenting large
amounts of data.
Moberg, Brooks, Drummond, Fischer [page 18]
HTTP Transport for Secure EDI May 2002
3.2 Differences in MIME or other headers or parameters used
3.2.1 Content-Length
Because connections are persistent, closing a connection cannot
be used to indicate the end of an entity. Therefore, [HTTP]
sections 4.4 and 14.14 indicate the need for a Content-Length
entity header in a request.
3.2.2 Final and Original Recipient
The final and original recipient distinction should not
arise for HTTP transport because SMTP aliases and mailing
lists should not be used.
3.2.3 Message-Id and Original-Message-Id
The Message-Id and Original-Message-Id distinction should not
arise for HTTP transport because SMTP MTA alterations should
not occur. Message-Id is formatted as defined in RFC2822:
"<" id-left " <at> " id-right ">" (RFC2822 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,
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.
3.2.4 Host header
The host request header field must be included in the
POST request made when sending business data. This field
is to allow one server IP address to service multiple
hostnames, and potentially conserve IP addresses.
See [HTTP], sections 14.23 and 19.5.1.
Moberg, Brooks, Drummond, Fischer [page 19]
HTTP Transport for Secure EDI May 2002
4. Additional AS2 specific HTTP headers
The following headers are to be included in all AS2 messages
and all AS2 MDNs.
4.1 AS2 Version Header
To promote backward compatibility AS2 includes a version:
AS2-Version: 1.0
This header MUST be present on all AS2 messages and AS2
MDNs, but not in a single line response (see section 2.4).
Receiving systems MUST NOT fail due to the absence of the
AS2-Version header. This would indicate the message is from
an older system.
4.2 AS2 System Identifiers
The receiving system needs to obtain the identity of the sending
system. This may be company specific, such as DUNS number, or it
may be simply an identification string agreed upon between the
trading partners. The two AS2 headers are:
AS2-From: < AS2-quoted-string >
AS2-To: < AS2-quoted-string >
These AS2 headers contain textual values, as described below,
identifying the sender/receiver of a data exchange. This
information MUST appear either in the AS2-From/AS2-To headers
or in the GISB Form-Data; name="from"/"to" (see appendix B).
AS2-qtext = %d32-33 / ; space & bang, printable ASCII
%d35-91 / ; characters not including "\"
%d93-126 ; or the double-quote character
AS2-quoted-pair = <\> <\> / <\> <"> ; backslash or DQUOTE
; \\ \"
AS2-name = 1*128 ( AS2-qtext / AS2-quoted-pair )
AS2-quoted-string = AS2-name / <"> AS2-name <">
The AS2-From header value and the AS2-To header value MUST
each be an AS2-quoted-string, MUST each be comprised of
from 1 to 128 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.
Moberg, Brooks, Drummond, Fischer [page 20]
HTTP Transport for Secure EDI May 2002
4.2.1 Rules for using the AS2-To and AS2-From headers
1. If an AS2-name contains no contiguous embedded SP characters
( 2* SP ), AS2 systems SHOULD use the first form
( no quotes ) for the AS2-quoted-string, in order to
provide maximum compatibility with earlier AS2 systems.
2. If an AS2-name contains contiguous embedded SP characters,
AS2 systems SHOULD use the second form ( quoted ) for the
AS2-quoted-string, in order to provide protection from
contiguous-LWSP substitution by an intermediary HTTP proxy
or server ( cf. RFC 2616 #2.2 ).
3. AS2 systems MUST accept as valid both forms of the
AS2-quoted-string, whether or not the AS2-name contains
contiguous embedded SP characters.
4. AS2 systems that receive an AS2-quoted-string of the
first form ( no quotes ) MAY assume the first significant
character of the AS2-name is the first non-LWSP character
after the extensions header label ( "AS2-From:" or
"AS2-To:" ) and that the last non-LWSP character before the
line termination characters (CRLF) is the last significant
character of the AS2-name.
5. AS2 systems that receive an AS2-quoted-string of the
second form ( quoted ) MAY interpret all characters between
the quotation marks as belonging to the AS2-name. Therefore,
AS2 systems that send messages using the second form
( quoted ) for AS2-names, SHOULD NOT include leading or
trailing SP characters within the quotation marks, as
receiving systems may interpret these characters as
significant.
6. As is explicit in the definition of the AS2-name, an
embedded reverse solidus ( "\" or backslash ) or an
embedded double-quote MUST be represented using the
quoted-pair scheme. Only these two quoted-pair belong to
the AS2-quoted-pair set. Any other quoted-pair is invalid
in an AS2-name.
4.2.2 Unrecognized System Identifiers
If either the AS2-From or the AS2-To or the combination of both
header values is determined to be invalid or unknown by the
receiving system, the receiving system MAY respond in one of
the following ways, but is not limited to these options:
1. The receiving AS2 system MAY disconnect from the
sending AS2 system before completing the reception of
the entire entity if it determines the HTTP headers
do not represent a valid trading-relationship.
Moberg, Brooks, Drummond, Fischer [page 21]
HTTP Transport for Secure EDI May 2002
2. The receiving AS2 system MAY disconnect from the
sending AS2 system before completing the reception
of the entire entity if it determines the entity
being sent is too large to process.
3. The receiving AS2 system MAY return an HTTP response
with a response code in the 2xx range, with or without
any explanation of the error, even if the sending
system requested an MDN.
4. The receiving AS2 system MAY return an unsigned MDN
with an explanation of the error, if the sending
system requested an MDN.
Appendices
A. AS2 MIME templates
Structure of an AS2 MIME message - PGP/MIME
No encryption, no signature (analog of 4.2.1)
-RFC2068/2045
-RFC1767/RFC2376 (application/EDIxxxx or /xml)
No encryption, signature (analog of 4.2.2)
-RFC2068/2045
-RFC1847 (multipart/signed)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)
-RFC2015 (application/pgp-signature)
Encryption, no signature (analog of 4.2.3)
-RFC2068/2045
-RFC1847 (multipart/encrypted)
-RFC2015 (application/pgp-encrypted)
-"Version: 1"
-RFC2015 (application/octet-stream)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
Encryption, signature (analog of 4.2.4)
-RFC2068/2045
-RFC1847 (multipart/encrypted)
-RFC2015 (application/pgp-encrypted)
-"Version: 1"
-RFC2015 (application/octet-stream)
-RFC1847 (multipart/signed)(encrypted)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
-RFC2015 (application/pgp-signature)(encrypted)
Moberg, Brooks, Drummond, Fischer [page 22]
HTTP Transport for Secure EDI May 2002
Structure of an AS2 MIME message - S/MIME
No encryption, no signature (analog of 4.3.1)
-RFC2068/2045
-RFC1767/RFC2376 (application/EDIxxxx or /xml)
No encryption, signature (analog of 4.3.2)
-RFC2068/2045
-RFC1847 (multipart/signed)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)
-RFC2633 (application/pkcs7-signature)
Encryption, no signature (analog of 4.3.3)
-RFC2068/2045
-RFC2633 (application/pkcs7-mime)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
Encryption, signature (analog of 4.3.4)
-RFC2068/2045
-RFC2633 (application/pkcs7-mime)
-RFC1847 (multipart/signed)(encrypted)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
-RFC2633 (application/pkcs7-signature)(encrypted)
B. AS2 Extensions for the GISB Protocol and Report-type
GISB AS2 Profile
The United States based Gas Industry Standards Board (GISB) is a
consortium of companies and individuals that operate in the Gas
Industry. The membership is divided into 5 sectors, Producers,
Pipelines, Services, End Users, Local Distribution Companies,
representing the various type of organizations within the
industry. In 1996 GISB initiated a program to move from the
expensive Value Added Networks they were using, to the Internet.
By October of 1996GISB had developed and tested a protocol,
called GISB Electronic Delivery Mechanism (EDM), which uses HTTP
and is based on RFC1867 (Form-based File Upload in HTML). By
May 1997 this protocol was being used by Enron and others to
send/receive live, mission critical business transactions over
the Internet. Additional companies followed suit and a large
percentage of today's business transactions in the Gas Industry
are transmitted over the Internet using the GISB EDM protocol. In
1998 the Automobile Industry Action Group (AIAG) adopted the GISB
EDM protocol and in 1999 the local electric companies serving the
state of Pennsylvania declared the GISB protocol as their
standard for transmitting business transactions via the Internet.
Moberg, Brooks, Drummond, Fischer [page 23]
HTTP Transport for Secure EDI May 2002
In May of 1999 the AIAG, GISB and members of the IETF EDIINT
workgroup initiated an effort to converge their independent
specifications, the result of which is this specification. In
order to bring the GISB EDM into compliance with this
specification GISB initiated a formal change to the EDM
specification. The following information, referred to as the
"GISB AS2Profile", reflects the planned utilization of this
specification by the GISB membership.
The GISB membership will utilize PGP to meet all P.A.I.N.
requirements. All data exchanges will utilize the multipart/form-
data enveloping method and two generalized receipts,
GISB-Acknowledgement-Receipt and GISB-Error-Notification. All
original business transactions must be digitally signed (using
encapsulated signatures) and encrypted using RSA algorithms. Upon
successful transfer of an original business transaction the
receiver is required to send a GISB-Acknowledgement-Receipt
indicating that the transfer has completed successfully. If, upon
further processing of the business document an error is
encountered a GISB-Error-Notification is sent to the original
sender using the multipart/form-data enveloping.
It is expected that companies following the GISB AS2 profile will
protect their web sites from unauthorized access through the use
of basic authentication (username/passwords), as defined in the
HTTP specification. GISB is not "requiring" the use of signed
receipts; however, signed receipts are allowed between consenting
trading partners. GISB has decided to use the following core
headers:
FROM:
Contains the DUNS number of the sending party
TO:
Contains the DUNS number of the intended recipient
INPUT-FORMAT:
Type of data being sent (only x12 and error currently
supported) other options can easily be added to this list.
INPUT-DATA:
The actual payload containing the business transaction or
GISB-Error-Notification. If the payload contains a business
transaction it is signed and encrypted using PGP.
Version:
The GISB version number (currently 1.3)
RECEIPT-DISPOSITION-TO:
The DUNS number of the party to receive the
GISB-Acknowledgement-Receipt (typically the same DUNS
number associated with the From header.) Presence of this
Moberg, Brooks, Drummond, Fischer [page 24]
HTTP Transport for Secure EDI May 2002
field also serves as a flag indicating that an
acknowledgement receipt is requested by the sender. The
receipt is returned synchronously (on the same session
used to send the input-data payload).
RECEIPT-REPORT-TYPE:
Contains the value GISB-Acknowledgement-Receipt.
Optional headers also available:
TRANSACTION-SET:
Identifies the type of transaction contained in the
input-data payload.
RECEIPT-SECURITY-SELECTION:
This field serves as a flag indicating that a signed
receipt is being requested. The contents of this field
indicate the algorithm and signature type to use in
constructing the signature.
Example of a GISB data exchange:
The sending party creates an X12 business transaction and
concatenates with an RFC 1767 compliant header. The entire
package is then encrypted and signed using PGP. The encrypted
package is then enveloped with the appropriate headers/values
and sent to the trading partner using HTTP POST, the contents
of this post appear as follows:
POST c:\execute HTTP/1.0
Referer: http://www.get.a.life/upl.htm
Connection: Keep-Alive
User-Agent: brow v0.1 XYZ Corp.
Host: localhost
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Content-type: multipart/form-data;
boundary=---------------------------87453838942833
Content-Length: 5379
-----------------------------87453838942833
Content-Disposition: form-data; name="from"
123456789
-----------------------------87453838942833
Content-Disposition: form-data; name="to"
234567890
-----------------------------87453838942833
Content-Disposition: form-data; name="Version"
1.3
Moberg, Brooks, Drummond, Fischer [page 25]
HTTP Transport for Secure EDI May 2002
-----------------------------87453838942833
Content-Disposition: form-data; name="receipt-disposition-to"
123456789
-----------------------------87453838942833
Content-Disposition: form-data; name="receipt-report-type"
GISB-Acknowledgement-Receipt
-----------------------------87453838942833
Content-Disposition: form-data; name="input-format"
x12
-----------------------------87453838942833
Content-Disposition: form-data; name="input-data";
filename=c:\temp\smallnom.bin
Content-Type: multipart/encrypted; boundary=9876;
protocol="application/pgp-encrypted"
--9876
Content-Type: application/pgp-encrypted
Version: 1
--9876
Content-Type: application/octet-stream
-----BEGIN PGP MESSAGE-----
Version: PGP 6.5
hQCMAzRG1pEOIOvdAQP+JMr0m/9+8yOL60Z9Vr6fFV81FCExB/o0xmwiMkiwYsHs
z0e8sb7ErC340MrNA/dw3taGMjmI+CXYRF/PLEdg1NZE1ZCtNeL4YdIHAMLWwODG
lQxhSucz8rMSgQ5mZzcOJwBdWLW70efgsu/9UljuJjYc1uZ6C03eFQv/43fkB+al
ATtgydxX4g8QK664ad+Jo/XUICSmWBL66fqJR1KLeLf4wTaqGy174Aq48Wpwvg1E
h785zC03UAw0qg0ugMt86dPeyd91e2JigqwDYEf/DYEKD0J9BGiGpS/uAupNKj8O
aqx2Dq/ra9g65HNchOCzjul5Vi8HHf6Yhg2WnROe+npByyCue6rihqgNVOJwj0cV
zpb4JE+gMDf3q4ISUb1Fv7/+SSFHDdnhdC5YTpqf1Bc3B07hiLmtTXqNit31EbX9
UVElObzSa9ZhxbC6/eSl7Nuf5ZTDsh9nrk+QQJ6FeC9W4cqXLj7IZySaRO8Vtff+
4ktqeuhYusT4kSpnk027aw4O/5jomUkfb22CAe4=
=Oiuo
-----END PGP MESSAGE-----
--9876--
-----------------------------87453838942833--
Upon receiving the above stream of data the receiving host
parses the headers and returns an unsigned
GISB-Acknowledgement-Receipt, appearing as follows:
Content-Type: multipart/report;
report-type="GISB-Acknowledgement-Receipt"; boundary="GISB7867"
Moberg, Brooks, Drummond, Fischer [page 26]
HTTP Transport for Secure EDI May 2002
--GISB7867
Content-type: text/html
<HTML><HEAD><TITLE>Acknowledgement Receipt Success</TITLE></HEAD>
<BODY><P>
time-c=19960619082855*
request-status=ok*
server-id=coolhost*
trans-id=234423897*
</P> </BODY></HTML>
--GISB7867
Content-type: text/plain
time-c=19960619082855*
request-status=ok*
server-id=coolhost*
trans-id=234423897*
--GISB7867--
C. Samples of AS2 Protocol Data Units
C.1 The following example illustrates the full HTTP request that
sends X12 EDI data from company1 to company2. A signed receipt is
requested; the receipt is to be a MDN report-type, with the pkcs7
signature option, using a signature algorithm of rsa-md5.
The receipt is to be sent synchronously (that is, in the reply to
this HTTP request), because no special delivery options are
indicated.
POST https://tp2server.company2.com/cgi-bin/tp1drawer.pl HTTP/1.1
Host: tp2server.company2.com
AS2-To: zzzcompany2
AS2-From: zzzcompany1
AS2-Version: 1.0
From: ediadmin <at> company1.com
Date: Tue, 06 Nov 2001 12:53:01 UT
Subject: Purchase orders for 6 November 2001
Message-Id: <20011106 <at> company1.com>
Disposition-Notification-To: tp1 <at> company1.com
Disposition-Notification-Options: signed-receipt-protocol=optional,
pkcs7-signature; signed-receipt-micalg=optional,rsa-md5
Content-Type: multipart/signed; boundary="20011106RsXgYlvCNW";
protocol=application/pkcs7-signature; micalg=rsa-md5
Content-Length: 3056
--20011106RsXgYlvCNW
Content-Type: application/edi-x12
Content-Disposition: Attachment; filename=rfc1767.dat
Moberg, Brooks, Drummond, Fischer [page 27]
HTTP Transport for Secure EDI May 2002
[ISA ...EDI transaction data...IEA...]
--20011106RsXgYlvCNW
Content-Type: application/pkcs7-signature
[omitted binary pkcs7 signature data]
--20011106RsXgYlvCNW--
C.2 This second example illustrates returning a signed MDN
that corresponds to the request for a MDN found in C.1.
HTTP/1.0 200 OK
Server: HTTPEDI/1.1
AS2-To: zzzcompany1
AS2-From: zzzcompany2
AS2-Version: 1.0
Content-type: multipart/signed; boundary="boundary1"
Content-Length: 1200
--boundary1
Content-type: multipart/report; boundary="boundary2"
--boundary2
Content-type: text/plain
Message <20011106 <at> company1.com> was authenticated;
EDI processing was initiated.
--boundary2
Content-type: message/disposition-notification
Reporting-UA: Company2UA
Final-Recipient: rfc822; tp2 <at> company2.com
Original-Message-Id: <20011106 <at> company1.com>
Received-Content-MIC: w7AguNJEmhF/qIjJw6LnnA==, rsa-md5
Disposition: MDN-sent-automatically/processed
--boundary2--
--boundary1
Content-Type: application/pkcs7-signature
[Signature data omitted]
--boundary1--
D. Acknowledgments
Carl Hage, Karen Rosenfeld, Chuck Fenton and many others have
provided valuable suggestions improving this applicability
statement.
Moberg, Brooks, Drummond, Fischer [page 28]
HTTP Transport for Secure EDI May 2002
E. References
[ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997
[AS1] T. Harding, R. Drummond, C. Shih, "Peer-to-Peer
MIME-based Secure Business Data Interchange", April 2002,
Internet draft: draft-ietf-ediint-as1-17.txt.
[CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630,
June 1999.
[FORMDATA] L. Masinter, "Returning Values from Forms:
multipart/form-data", RFC 2388, August, 1998.
[GISB] Gas Industry Standards Board, "Electronic Delivery
Mechanism Related Standards", Version 1.3 July 31, 1998
[HTML] D. Raggett, A. Le Hors, I. Jacobs. "HTML 4.0
Specification", World Wide Web Consortium Technical Report
"REC-html40", December, 1997. <http://www.w3.org/TR/REC-html40/>
[HTTP] R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners-Lee,
"Hypertext Transfer Protocol--HTTP/1.1", RFC 2068, March 1997.
[MIME] N. Borenstein, N. Freed, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, December 02, 1996.
N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types", RFC 2046, December 02, 1996.
N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions
(MIME) Part Five: Conformance Criteria and Examples", RFC 2049,
December 02, 1996.
[MIMEEDI] D. Crocker, "MIME Encapsulation of EDI Objects", RFC
1767, March 2, 1995.
[MIMEPGP] M. Elkins, "MIME Security With Pretty Good Privacy
(PGP)", RFC 2015, Sept. 1996.
[MDN] R. Fajman, "An Extensible Message Format for Message
Disposition Notifications", RFC 2298, March 1998.
[SECURITY] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, Oct. 3, 1995
[SMTP] P. Resnick, Editor "Internet Mail Format", RFC 2822,
April 2001.
Moberg, Brooks, Drummond, Fischer [page 29]
HTTP Transport for Secure EDI May 2002
[SMIMEV2] S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L.
Repka, "S/MIME Version 2 Message Specification", RFC 2311.
[SMIMEV3] B. Ramsdell, "S/MIME Version 3 Message Specification",
RFC 2633, June 1999.
[REPORT] G. Vaudreuil, "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC 1892,
March 15, 1996.
[TLS] T. Dierks,C. Allen, "The TLS Protocol Version 1.0" RFC 2246,
March 1999.
[MIME-TYPES] "Media Types," http://www.isi.edu/in-
notes/iana/assignments/media-types/media-types.
[XMLTYPES] E. Whitehead, M. Murata, "XML Media Types", RFC 2376,
July 1998.
F. Security Considerations
This entire document is concerned with secure transport of
business to business data and considers both privacy and
authentication issues.
G. Authors' Addresses
Dale Moberg
dale_moberg <at> cyclonecommerce.com
Cyclone Commerce
8388 E. Hartford Drive
Scottsdale, AZ 85255 USA
Dick Brooks
dick.brooks <at> systrends.com
Systrends, Inc
7855 South River Parkway, Suite 111
Tempe, Arizona 85284 USA
Rik Drummond
rik <at> drummondgroup.com
Drummond Group
5008 Bentwood Ct.
Fort Worth, TX 76132 USA
David Fischer
david <at> drummondgroup.com
Drummond Group
4200 S. Hulen St. Suite 600
Fort Worth, TX 76109 USA
Moberg, Brooks, Drummond, Fischer [page 30]

RE: New AS2 Draft

Dick Brooks <dick <at> tech-comm.com>
2002-04-17 21:44:41 GMT

David,
In section 4.1 it states:
"To promote backward compatibility AS2 includes a version:
AS2-Version: 1.0
This header MUST be present on all AS2 messages and AS2
MDNs, but not in a single line response (see section 2.4).
Receiving systems MUST NOT fail due to the absence of the
AS2-Version header. This would indicate the message is from
an older system."
I don't see the need for an AS2-Version if parties are using the "Version"
header described in section 2.1.2.1.
Dick Brooks
Systrends, Inc
7855 South River Parkway, Suite 111
Tempe, Arizona 85284
Web: www.systrends.com <http://www.systrends.com>
Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714
-----Original Message-----
From: owner-ietf-ediint <at> mail.imc.org
[mailto:owner-ietf-ediint <at> mail.imc.org]On Behalf Of David Fischer
Sent: Wednesday, April 17, 2002 3:34 PM
To: IETF EDIINT
Subject: FW: New AS2 Draft
Try Again...
David
-----Original Message-----
From: David Fischer [mailto:david <at> drummondgroup.com]
Sent: Wednesday, April 17, 2002 2:49 PM
To: Steve Lowery
Cc: IETF EDIINT
Subject: RE: New AS2 Draft
Sorry,
David.
-----Original Message-----
From: Steve Lowery [mailto:Lowerys <at> meijer.com]
Sent: Wednesday, April 17, 2002 2:23 PM
To: david <at> drummondgroup.com
Subject: Re: New AS2 Draft
was the document to be attached?
>>> "David Fischer" <david <at> drummondgroup.com> 04/17/02 02:33PM >>>
This is the new draft AS2 spec with the new AS2-Version
header.
We also tightened up the definition of Message-Id (section
3.2.3) and AS2-To/AS2-From (section 4) to enhance
interoperability and backward compatibility.
This has not yet been sent to IETF.
Comments?
Regards,
David Fischer
Drummond Group.

RE: New AS2 Draft

David Fischer <david <at> drummondgroup.com>
2002-04-17 22:37:43 GMT

Oh, I thought the version attribute in 2.1.2.1 was a GISB version, not an AS2
version?
There is actually no need for this header right now. This is being added in
anticipation of future AS2 interop needs.
Regards,
David.
-----Original Message-----
From: Dick Brooks [mailto:dick <at> tech-comm.com]
Sent: Wednesday, April 17, 2002 4:45 PM
To: David Fischer; IETF EDIINT
Subject: RE: New AS2 Draft
David,
In section 4.1 it states:
"To promote backward compatibility AS2 includes a version:
AS2-Version: 1.0
This header MUST be present on all AS2 messages and AS2
MDNs, but not in a single line response (see section 2.4).
Receiving systems MUST NOT fail due to the absence of the
AS2-Version header. This would indicate the message is from
an older system."
I don't see the need for an AS2-Version if parties are using the "Version"
header described in section 2.1.2.1.
Dick Brooks
Systrends, Inc
7855 South River Parkway, Suite 111
Tempe, Arizona 85284
Web: www.systrends.com <http://www.systrends.com>
Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714
-----Original Message-----
From: owner-ietf-ediint <at> mail.imc.org
[mailto:owner-ietf-ediint <at> mail.imc.org]On Behalf Of David Fischer
Sent: Wednesday, April 17, 2002 3:34 PM
To: IETF EDIINT
Subject: FW: New AS2 Draft
Try Again...
David
-----Original Message-----
From: David Fischer [mailto:david <at> drummondgroup.com]
Sent: Wednesday, April 17, 2002 2:49 PM
To: Steve Lowery
Cc: IETF EDIINT
Subject: RE: New AS2 Draft
Sorry,
David.
-----Original Message-----
From: Steve Lowery [mailto:Lowerys <at> meijer.com]
Sent: Wednesday, April 17, 2002 2:23 PM
To: david <at> drummondgroup.com
Subject: Re: New AS2 Draft
was the document to be attached?
>>> "David Fischer" <david <at> drummondgroup.com> 04/17/02 02:33PM >>>
This is the new draft AS2 spec with the new AS2-Version
header.
We also tightened up the definition of Message-Id (section
3.2.3) and AS2-To/AS2-From (section 4) to enhance
interoperability and backward compatibility.
This has not yet been sent to IETF.
Comments?
Regards,
David Fischer
Drummond Group.