2.1.3 Electronic Data Interchange-Internet Integration (ediint)

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 01-Feb-99

Chair(s):

Rik Drummond <drummond@onramp.net>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>

Applications Area Advisor:

Keith Moore <moore@cs.utk.edu>

Mailing Lists:

General Discussion:ietf-ediint@imc.org
To Subscribe: ietf-ediint-request@imc.org
In Body: subscribe
Archive: http://www.imc.org/ietf-ediint/

Description of Working Group:

Electronic Data Interchange (EDI) is a set of protocols for conducting highly structured inter-organization exchanges, such as for making purchases or initiating loan requests. The initial RFC1767 defined the method for packaging the EDI X12 and UN/EDIFACT transactions sets in a MIME envelope. However, several additional requirements for obtaining multi- vendor, inter-operable service, over and above how the EDI transactions are packaged, have come to light since the effort concluded. These currently revolve around security issues such as EDI transaction integrity, privacy and non- repudiation in various forms. Additional requirements that mimic many of the heading fields found in X.435 EDI messages (e.g.; Interchange Sender, Interchange Recipient, interchange Control Reference, Communications Agreement ID, and Syntax Identifier) are also needed to support exchanges by point-to-point, FTP and SMTP protocols. Standards in these and other areas are necessary to ensure inter- operability between EDI packages over Internet. Various technologies already exist for these additional features and the primary requirement is to review and select a common set of components for use by the EDI community when it sends EDI over the Internet. In effect, the effort is to provide an EDI over the Internet Informational and Applicability Statement Document.

Deliverables:

The group will produce Four documents:

1) An Informational document describing the requirements for interoperable EDI, with sufficient background material to give an explanation for the EDI community of the Internet-related issues.

2) A Applicability Statement describing how current Internet standards can be used to achieve this functionality for MIME and SMTP.

3) A Applicability Statement describing how current Internet standards can be used to achieve this functionality for Process-to-Process (real-time) EDI.

4) Security Issues for Inter-organizational EDI over Internet.

Additional Administrative information:

Editor: Chuck Shih <chuck@orville.premenos.com John DesJardins <jdesjard@nicom.com Marc Blanchet <Marc.Blanchet@viagenie.gc.ca First Readers: Rik Drummond <drummond@onramp.net

Goals and Milestones:

Done

  

Submit outline for the informationl requirements document.

Done

  

Submit informational requirements document as an Internet-Draft.

Done

  

Submit both Applicability Statement documents as Internet-Drafts.

Done

  

Submit requirements document Internet-Draft to IESG for consideration as an Informational RFC.

Done

  

Submit AS Internet-Draft documents to IESG for consideration as Proposed Standards.

Oct 97

  

Submit second applicability statement(AS#2)and the Security document as Internet-Drafts.

Apr 98

  

Submit AS#2 and Security Document to IESG for consideration as Internet-Draft documents for Proposed Standard.

Internet-Drafts:

No Request For Comments

Current Meeting Report

Minutes EDIINT Workgroup Meeting
IETF Minneapolis, MN
March 16, 1999

Background: The workgroup has four drafts ready for submittal to IESG for Informational Standards. Three of these are based on S/MIME and have been completed for over 16 months. Because of the S/MIME references they are waiting on the completion of the IETF CMS (S/MIME) workgroup before proceeding for submittal as RFCs.

Minutes:
- A few open "CMS alignment" issues continue to crop up on the three finished documents. As the CMS workgroup makes adjustments to S/MIME the EDIINT workgroup must make adjustments to their documents to reflect these changes. Changes to the Requirements, Applicability Statement #1 and the HL7 document are required to reflect changes to the CMS draft documents. Chuck Shih of Gardner Group is aligning both the requirements and the AS#1 document with the CMS drafts. These changes are focused on the CMS REQUIRED encryption, signing and hashing algorithms.
- Most of the meeting was spent discussing AS#2, which is EDI based on HTTP as the transport. Dale Moberg lead the discussions. His slides are attached.
- Issue number 1: AS#2 was thought to be created by just changing the transport protocols from SMTP as defined in AS#1 to HTTP for AS#2. Now after the meeting, it seems that it may not be possible to do this as easily as we first thought. The reason being that AS#1 uses MDN's created for email as the receipt, which may require email addresses. If the AS#1 functionality is just transferred over to AS#2 .we can't require email addresses, which means that MDN's may not work in HTTP transports. Dale will research this and let the group know the alternatives.
- Issue number 2: At this time there are two standards, both industry level, that use HTTP to move secure EDI over Internet. They are the Auto Industry's E5 and the Oil and Gas Industry's GISB standards. The discussion centered on how we product AS#2 in a manner which would allow both E5 and GISB standards to use it as a basis for their future work. This would give all of us a much closer alignment for EDI standards over Internet. Rik will schedule a two-day face to face meeting in April or May with the key player to hammer this out. The results will be presented to the workgroup listserv for discussion and approval.

Todo: Redo the Charter to explicitly say HTTP. At this time it just says "point-to-point" transport protocols which was to cover the HTTP protocol when it was written. Done - Rik Drummond.

The target date for submittal of the workgroup's finished drafts as RFC's is shortly after the submittal of the CMS drafts for consideration as RFC's.

Submitted by Rik Drummond
March 31, 1999

Slides

None received.