Internet-Draft Gunther Schadow Expires in 6 months 17 November 1997 MIME Encapsulation of EDI Objects Revised Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Purpose This memo attempts a further development of what has been begun by [1]. It is not meant as a superseding version of the MIME encapsulation of EDI objects. Rather, its purpose is to claim the necessity of such a next version. This memo outlines the major shortcomings of, and tries to raise more potential from [1]. Table of Contents 1. Introduction.............................................2 2. Structure of MIME EDI Transactions.......................4 2.1 The Content-ID Header Field.............................7 2.2 The In-Reply-To Header Field............................8 2.3 The Transaction-ID Header Field.........................8 2.4 Received-content-MIC...................................9 3. Redefinition of EDI MIME Types...........................9 3.1 Protocol................................................10 3.2 Version.................................................11 3.3 Syntax..................................................11 3.4 Features................................................11 3.5 Recommendations.........................................11 4. Examples.................................................11 draft-schadow-edirev-01.txt [Page 1] Schadow MIME EDI Objects Revised 17 November 1997 5. References...............................................12 6. Author's Address.........................................13 1. Introduction Crocker [1] set out a first step to make EDI messages communicable over the Internet, and -- vice versa -- to make the Internet EDI aware. By defining a simple MIME wrapper for EDI messages it allows that EDI message can be sent over whatever Internet transport channel is aware of MIME, including but not limited to SMTP and HTTP. According to [2] and [3], there is a lot more to consider when EDI communications is to be migrated from private to public networks, where security is certainly the paramount issue. Shih et al. [4] summarize how recently developed methods for e-mail security [5] can be applied in a standard way, such that an interoperable secure EDI communication over Internet is now possible. The main security issues that [4] addresses are confidentiality by encryption, message integrity and non-repudiation of origin by digital signature, and non-repudiation of message receipt by signed message disposition notifications (MDN) [6]. One of the most important issue for EDI standards developers and users that suggest using the Internet is the worldwide abundance of Internet connectivity and Internet software. Notably it is hoped that off-the-shelf software will be available for a low price that allows modern as well as legacy information systems to do their EDI communications using Internet technology. The strength of this kind of software is that it is independent from the particular EDI protocol deployed. There are different EDI standards for many different application domains. EDIFACT [7] is important in international administration and commerce, where in USA ASC X12 [8] is widely used. HL7 [12] is an ANSI standard used in healthcare worldwide, and there are many more official standards and national and regional conventions that can all benefit from the same software. Thus, an Internet EDI wrapper should reflect the abstract properties of EDI in general. There are characteristics of the EDI world that are not yet sufficiently mapped to the Internet world. One of these issues yet unresolved is the plurality of EDI standards. While [1] only names EDIFACT and X12 explicitly, it claims that all other EDI standards use the MIME subtype APPLICATION/EDI-CONSENT. Without even the ability to specify of which particular EDI protocol a given message is it is certainly insufficient to allow interoperable communications. draft-schadow-edirev-01.txt [Page 2] Schadow MIME EDI Objects Revised 17 November 1997 An other issue is versioning. Some EDI protocols come in different versions and others are continuously developed further, such that it becomes important to identify the versions and characteristics of the EDI protocol that apply to a given message. A third, closely related issue is that some EDI standards allow different presentation syntaxes for the same application-level message, and it is thus necessary to specify the presentation syntax that applies to a given message. On the other hand, some issues that are well-known to the Internet world from the beginning are relatively new to the EDI world: namely, the worldwide trans-institutional communication in a large and growing community. While it is true that electronic data interchange has been developed in order to replace the slow and costly exchange of paper documents, other means of communication, including personal meetings, usually preceded the establishment of routine EDI connections. While it now rarely happens that Internet communication partners meet each other in person, EDI still grounds on this personal meeting, bilateral negotiation, and signing of contracts. EDI standard organizations are now developing security policies, by which an interoperable and legally solid communication could be performed without prior negotiations, but in many cases, this development is unfinished yet. It is a reasonable and economic approach for standards organizations to rely on Internet security standards rather than creating their own security protocols that are valid only within their limited scope. There is also a technical reason why it makes sense to rely on Internet standards for many of the security issues: most security mechanisms (encryption, hashing) do only apply to bit strings and not to abstract EDI objects, which suggests handling security on a different layer below the OSI presentation layer (6). EDI transactions take over the function of written contracts or other documents that had a legal value. Conversely, Internet protocols never had such a legal function. While companies or other institutions could run their internal business based on Internet protocols, it has not yet been necessary to present a transcript of Internet communications in a court of civil jurisdiction in order to support a case against a trading partner. Secure EDI transactions must be ready to be taken to court in order to provide a solid basis to tele-business. Non-repudiation is the essential service that a secure EDI protocol must add. In more and more countries (e.g. Germany) there are new laws that set out rules for a legally valid EDI and digital signatures play a key role in this legislation. The security mechanisms as proposed by [4] draft-schadow-edirev-01.txt [Page 3] Schadow MIME EDI Objects Revised 17 November 1997 address what is required by law, but it does so by imposing an Internet message paradigm on an EDI transaction, which misses some important characteristics of EDI transactions. Current Internet standardization considers the essence of EDI transactions to be singular messages. However, EDI transactions represent contracts more than mere messages. While in the paper world contracts could be sent and received within letters a contract was more than a letter as it required the signature of both trading partners. Thus, a paper-based contract was a handy piece of evidence, as neither partner can repudiate his commitment to the contract. In EDI this is reflected by a transaction consisting of more than one message. Typically an EDI transaction is made up of one pair of messages, one flowing from the initiator to the responder and an other vice versa. The function of the second message is to communicate the explicit consent and commitment to the transaction by the responder. This positive information of the response message is of high importance to EDI transactions, very different from the absence of an error notification. The major disadvantage of [4] is that its approach to non-repudiation in EDI was that of non-repudiation of origin and receipt of e-mail messages. As in the paper world one cannot rely on on a receipt notification when a contract is to be made over a distance. The contract, if signed only by one trading partner, has no legal value unless the other partner signs it as well and returns it. Receipt notifications are useful, but non-repudiation of receipt is different from non-repudiation of explicit commitment. 2. Structure of MIME EDI Transactions EDI standards define messages by which the trading partners communicate. One EDI transaction typically consists of two messages, request and response. A legally reliable EDI transaction must be concluded by a definitive positive response. +---------+ +---------+ | sender-------(REQUEST)------->receiver | |INITIATOR| |RESPONDER| | receiver<------(RESPONSE)-------sender | +---------+ +---------+ Figure 1: Roles and messages in a typical EDI transaction. draft-schadow-edirev-01.txt [Page 4] Schadow MIME EDI Objects Revised 17 November 1997 From a technical perspective, positive responses that carry no further information than the trading partner's explicit consent might be regarded redundant. However, the function of a positive response is not so much a technical than a legal one. A negative response only tells that the transaction failed, but failed transactions have no legal value. +-----------------------+ | TRANSACTION | |+---------------------+| || REQUEST || || ................... || || you owe me $20000 || || for bla, bla, bla || || || || Signature: XXX || |+---------------------+| |+---------------------+| || REPLY || || ................... || || o.k. i'll pay || || || || Signature: YYY || |+---------------------+| +-----------------------+ Figure 2: A complete EDI transaction. There are other more complex EDI transactions that for example implement queries or orders. However, the characteristics of EDI is that its transactions are usually self consistent and atomic and do not require nesting of multiple EDI transactions. As opposed to protocols that define fine-grained transactions, EDI generally does not require sophisticated transaction managers that would implement a two phase commit protocol. Many EDI applications expect a synchronous mode of communication, as they often used serial lines (RS232C) or direct telephone connections. For these applications, it becomes difficult to cope with the new asynchronicity that is introduced by the e-mail transport. Simple MIME programs such as mail agents designed for EDI, could be used to automatically match responses to their requests and thus make the asynchronicity transparent to the EDI application. If no response is received before a timeout deadline, recovery draft-schadow-edirev-01.txt [Page 5] Schadow MIME EDI Objects Revised 17 November 1997 mechanisms will usually apply. These include retry of the initiation of the transaction by re-transmission of the request message. E-mail introduces a high variability of throughput and turn around times. Thus, even with timeout values reasonably high, it happens that more than one EDI request messages are re-sent for the same transaction and all these messages arrive at the responder. If the EDI mail agent could autonomously handle retries and identification of messages as retransmissions of the same request, it would allow to further shield the idiosyncrasies of e-mail delivery from EDI applications. +------------+ +------------+ +------------+ |EDI MESSAGE | |EDI MESSAGE | |EDI MESSAGE | |message id |<--+ |message id |<--+ |message id | |replies to | +--+replies to | +--+replies to | |transaction | |transaction | |transaction | +----------+-+ +------+-----+ +-+----------+ | | | +---------------+--------------+ | v +-----------+ |TRANSACTION| |trnsact. id| +-----------+ Figure 3: Tracking of message relationships within a transaction. Since the EDI mail agent should not depend on a special EDI standard, it is desirable to put the general information required to identify messages and transactions into the representation of the EDI objects on the MIME level. This includes the following: 1. Identification of the EDI message 2. Identification of the previous EDI message that this message replies to. 3. Identification of the EDI transaction that the message belongs to Since a transaction can be identified by the identifier of its request message, there would be no need for an explicit transaction identifier. However, if a conversational pattern requires more than two messages to belong to a complete EDI transaction, the reference to the preceding message and the reference to the transaction to which all messages belong are different. draft-schadow-edirev-01.txt [Page 6] Schadow MIME EDI Objects Revised 17 November 1997 If ever [4] or [11] see a need for tracking of EDI messages and transactions they suggest that the Message-ID header field of the enclosing e-mail message should be used as an identifier for the EDI message itself. Likewise, the tracking of reply messages to their requests could be tried using the In-Reply-To header field of the e- mail message. This strategy, however, has many disadvantages: 1. It is generally a bad design practice to extend the meaning of something to mean something differently as well. 2. MIME EDI messages and transactions are independent from e-mail messages, and if there is a need to name them, they should be named independently. 3. A MIME EDI object can appear outside of any e-mail message so that there is no Message-ID to steal the meaning as EDI object ID from. 4. Multiple EDI objects could appear in a single e-mail message with the consequence that they would not be named uniquely. 5. Message-IDs can get scrambled by e-mail routers and gateways. 6. E-mail Message-IDs are outside of any MIME object that would apply to security conversions, these identifiers could not be signed or encrypted. Therefore it seems advisable to introduce new header fields to the MIME EDI wrapper that was originally defined in [1]. These are 1. Content-ID 2. In-Reply-To 3. Transaction-ID 4. Received-content-MIC 2.1 The Content-ID Header Field A MIME EDI object must contain a Content-ID header field, by which it is identified and can be referenced later. The MIME standard [14] explicitly suggests using this field by stating: In constructing a high-level user agent, it may be desirable to allow one body to make reference to another. Accordingly, bodies may be labeled using the "Content-ID" header field, which is syntactically identical to the "Message-ID" header field: - extension field = "Content-ID" ":" obj-id with: draft-schadow-edirev-01.txt [Page 7] Schadow MIME EDI Objects Revised 17 November 1997 obj-id = "<" addr-spec ">" ; Unique object id addr-spec = local-part "@" domain ; global address local-part = word *("." word) ; uninterpreted ; case-preserved domain = sub-domain *("." sub-domain) sub-domain = domain-ref domain-ref = atom ; symbolic reference Content-ID values must be generated to be world-unique, which is simple by the mechanism suggested by [13]: an object id is constructed like an e-mail address in the form "local@domain" where "local" is about any string, while "domain" is a unique domain address, simply and preferably the Internet address. Although the Content-ID header is generally optional, its use is MANDATORY in media types "application/edi". That is, each EDI MIME object must have a Content-ID field to permit transaction tracking. 2.2 The In-Reply-To Header Field The In-Reply-To field is used in every reply EDI MIME object to reference the Content-ID of the EDI MIME object that it replies to. This is not necessarily the request EDI MIME object of the transaction, but the received EDI MIME object on behalf of which this EDI MIME object was created. Its format is similar to the Content-ID field: - extension field = "In-Reply-To" ":" obj-id 2.3 The Transaction-ID Header Field The Transaction-ID header field is generated by the sender of a EDI MIME object in order to identify the transaction that this EDI MIME object belongs to. Its format is: - extension field = "Transaction-ID" ":" obj-id If a request message does not specify a Transaction-ID header field, the responder uses the Content-ID of the request message as a Transaction-ID. If the response message does not contain a Transaction-ID, the initiator uses the In-Reply-To field as the Transaction-ID. However, if the transaction requires more than two draft-schadow-edirev-01.txt [Page 8] Schadow MIME EDI Objects Revised 17 November 1997 EDI MIME objects flowing back and forth between the trading partners, a Transaction-ID must be specified at least in the third EDI MIME object. 2.4 Received-content-MIC The "Received-content-MIC" extension field is an optional field. The MIC is the base64 encoded quantity computed over the received EDI message (i.e. the contents of the EDI MIME wrapper) with a hash function. It is recommended that the SHA1 algorithm be used to calculate the MIC on the received message or message contents. - extension field = "Received-content-MIC" ":" MIC whith: MIC = base64MicValue "," micalg base64MicValue = the result of the one way hash function, base64 encoded. micalg = the micalg value defined in RFC1847, an IANA registered MIC algorithm ID token. This field allows the link between response and replied-to EDI MIME object to be secured: the responder not only names the Content-ID of the request, but also a representation of its content, i.e. the content of the EDI message itself. This field should be specified whenever an EDI MIME object is created in reply to an other EDI MIME object, and if the EDI MIME object does not lead to failure of the EDI transaction. When the reply EDI MIME object is signed this implements a special kind of non-repudiation: a non-refutable commitment to the EDI transaction by the responder. This is completely independent from non-repudiation of receipt of messages by signed MDNs. This is not a mechanism to replace non-repudiation of receipt, it is a mechanism invented solely for a bilateral non-repudiation of EDI transactions. However, if the fate of single messages is of no interest, non- repudiation of receipt can be omitted and legally valid EDI transactions are still carried out. 3. Redefinition of EDI MIME Types As said in the introduction, there are many EDI protocols, versions and variances out in the world that need to be specified in the header of the EDI MIME object in order to allow interoperable communication. draft-schadow-edirev-01.txt [Page 9] Schadow MIME EDI Objects Revised 17 November 1997 3.1 Protocol There are two competing strategies how the EDI protocol can be specified. Either as a mime subtype in the form subtype = "edi" protocol protocol = An IANA registered EDI protocol ID This leads to the usual mime types "application/edifact" and "application/edi-x12". The disadvantage of this method might be that the namespace of MIME subtype identifiers for the "application" media type tends to be blown up. Therefore the preferred mode is to specify the protocol in a way that was initially intended for the "application/edi-consent" subtype in [1] but forgotten or otherwise not defined later: a protocol identifier specified as a required parameter. Thus a superseding specification to [1] should define only the following MIME type: MIME type name: Application MIME subtype name: EDI Required parameters: PROTOCOL, a IANA registered identi- fier for "Application/EDI" proto- cols. Optional parameters: CHARSET, as defined for MIME, VERSION, a version identifier as applicable EDI standard, SYNTAX, a presentation syntax iden- tifier as applicable to the EDI standard, FEATURES, a list of feature identi- fiers as applicable to the EDI standard. Encoding considerations: May need BASE64 or QUOTED-PRINTABLE transfer encoding. Security considerations: See separate section in the docu- ment. Published specification: This document. draft-schadow-edirev-01.txt [Page 10] Schadow MIME EDI Objects Revised 17 November 1997 3.2 Version Many EDI standards come in different versions. Recognized version numbers should be specified in a conformance recommendation document or registered by the IANA if the IANA is able and willing to do this. The problem might be that the name space managed by the IANA becomes too deep and that the task of registering version identifiers for EDI protocols for the MIME EDI subtype might be too special to be assigned to the IANA. 3.3 Syntax ASC X12, for example, defines that the new transaction sets should use EDIFACT syntax, but an older syntax exists. Likewise there will be many different transfer syntaxes for HL7. The problem with regis- tering syntax identifiers is the same as outlined for protocol ver- sions and will be solved in the same way. 3.4 Features Some protocols might allow the optional selection of certain charac- teristics of the protocol. The optional parameter "feature" can be used to specify these. 3.5 Recommendations EDI standards organizations should document their application to the MIME EDI subtype, including the lists of recognized parameters in separate documents, that should be made publicly available. 4. Examples The following example shows a complete edi transaction with all header fields set to reasonable values. --bound Content-Type: application/edi; protocol="foo"; version="2.3"; Content-Transfer-Encoding: base64 Content-ID: Transaction-ID: --bound Content-Type: application/edi; protocol="foo"; version="2.3"; Content-Transfer-Encoding: base64 Content-ID: Transaction-ID: In-Reply-To: Received-content- MIC: 91dde119cc09904d76edd523b68b2d07,sha1 draft-schadow-edirev-01.txt [Page 11] Schadow MIME EDI Objects Revised 17 November 1997 --bound-- 5. References [1] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, March 2, 1995. [2] W. Houser, J. Griffin, C. Hage, "EDI Meets the Internet", RFC 1865, January 1996 [3] C. Shih, "Requirements for Inter-operable Internet EDI", Internet draft: draft-ietf-ediint-req03.txt July 1997. [4] C. Shih, M. Jansson, R. Drummond, "MIME-based Secure EDI", Inter- net draft: draft-ietf-ediint-as1-04.txt, July 1997. [5] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Oct. 3, 1995 [6] R. Fajman, "An Extensible Message Format for Message Disposition Notifications", draft-ietf-receipt-mdn-04.txt, June 14, 1997. [7] UN/EDIFACT (Electronic Data Interchange for Administration, Com- merce and Transport) Syntax Rules (ISO 9735), March 1993, United Nations Economic Commission for Europe (UN/ECE), Working Party for the Facilitation of International Trade Procedures (WP.4) [8] Data Interchange Standards Association; sets of specific EDI standards are ordered by their version number; Washington D.C. [9] ANSI X12.5 Interchange Control Structure for Electronic Data Interchange, Washington D.C.: DISA [10] ANSI X12.6 Applications Control Structures for Electronic Data Interchange, Washington D.C.: DISA [11] C. Shih, D. Moberg, R. Drummond, "HTTP Transport for Secure EDI" Internet draft: draft-ietf-ediint-as#2-01.txt, November 1997 [12] Health Level Seven, Version 2.3, Ann Arbor, 1997: Health Level Seven, Inc [13] D. Crocker, "Standard for the Format of ARPA Internet Text Mes- sages", STD 11, RFC 822, August 13, 1982. [14] N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, draft-schadow-edirev-01.txt [Page 12] Schadow MIME EDI Objects Revised 17 November 1997 December 02, 1996. 6. Author's Address Gunther Schadow Windsteiner Weg 54a 14165 Berlin Germany Phone: +49 (30) 815-3355 EMail: schadow@ukbf.fu-berlin.de draft-schadow-edirev-01.txt [Page 13]