CURRENT_MEETING_REPORT_ Reported by Cynthia Mills/BBN and Walter Houser/GSA Minutes of the Electronic Data Interchange Working Group (EDI) Wednesday's Agenda o Introductions, summary of the technical specification, current goal, etc. o General discussion of issues surrounding ``use of EDI over the Internet'' o Presentation by Walt Houser, US Federal ECAT Introduction This was the second meeting of the EDI Working Group. The group is focusing on the carriage of EDI objects through simple encapsulation of EDI objects in MIME. EDI over X.400/X.435 already exists. Three MIME objects, or content-type types have been defined: o EDI-X12 o EDIFACT o EDI-Consent There is a lot of structure that goes along with the unstructured EDI documents, therefore some ``unstructured'' or non-EDI objects may need to be encapsulated into other EDI objects to retain context. Other EDI (and associated non-EDI) objects may be carried as separate MIME objects. For EDI-specific semantic or syntactic work, there needs to be coordination with the EDI community on what objects will be standardized within EDI (e.g., EDI internal citation of MIME objects). General Discussion The usage document is intended to assist the EDI and Internet communities in understanding the operational requirements for doing EDI over the Internet and to indicate current solutions. Since this is a broad-ranging topic, the rest of the discussion time of the meeting was devoted to free-flowing exposition and discussion, saving the structured work for the next day. Several mini-presentations were made by participants, along with the usual group discussion; none of the rest of this section is particularly coherent, from one paragraph to the next... Robert Moscowitz, Chrysler: Automobile Association will be requiring all OEM supplier information to be IP-based. CAD group doesn't want to include CAD data INSIDE EDI, prefers to transport CAD data as separate data. Their FastBatch process requires a 2-minute turnaround of EDI data, so mail approach does not have adequate response guarantee. (response time and latency) Also the range of transport choice is important. The working group chair observed that there is a need to distinguish between high-level user requirements (core requirements) and engineering requirements (technical consequences of taking a particular implementation approach). Security implications - using the Internet-at-large or Virtual Private Network (private internet with direct private line between two known parties). Establish a core set of urgent capabilities with known limitations that can be implemented today and an extended set of action items that can be implemented later. Eric Fleischman, Boeing: has used EDI for many years. Standardized on X.12 and UN EDIFACT. Try to carry this over X.400 and X.435. Currently using X.25 public networks and many private links, some proprietary. Common transport inside Boeing is TCP/IP. Would like to do EDI between Boeing divisions VANs perform logging. Internet is a best- effort type of thing. Need accountability. More Discussion Accountability: Need accountability - want a guaranteed receipt of delivery and an audit trail to show what happened and exact recipient time. (Is a third party necessary to keep impartial logs? Private lines don't have a third party, how is accountability handled for private lines.) Restricted list of trading partners. Virtual private line can be provided by an encrypted tunnel between trading partners who have firewalls on the network. Need Integrity: checksum, signed end to end, digitally signed receipt. Concern for spoofing, s/w mailer bugs: These mailer bugs are common to many mailers, but managers only hear about SMTP bugs. Should write some explanatory text to cover security issues and set the record straight. X12.58 provides internal security for a single EDI field. Granularity of security, object versus field. Government requires timestamps for open bidding, etc. Must track and trace documents through entire system -- from start to finish. 997 functional acknowledgement. This is more than a receipt -- it is a complete trail documenting a transaction or string of transactions. Wanted by lawyers, accountants, auditors. Must be able to PROVE time and place of contract formation. Time-delayed delivery, X.400 has certain desirable store and forward facilities? Jim Amster, AT&T: Co-chair of Communications Task Group at EDI? Liaison from X12C. Tracking ... time of delivery AND time of receipt/reading/acceptance. Want to debug and find lost documents. Performance of the Internet is perceived as inadequate, by some. Need guidelines on how to achieve reasonable performance over the internet. Perception generated by low- value-added services, rather than the underlying net. Many suppliers are coming in at 2400 baud with bisync, so Internet will be perceived as faster. (Note, less predictable in response time.) Certification of EDI format. Specify what's necessary for interoperability between MIME and X.400/X.435. Separate and parallel, or gateway for translating between them? X.435 includes security features, notifications. This general capability (object and field level security?) PEDI message replaces X.400 P2 header with the X.435 PEDI -- separate, not necessarily isomorphic control mechanisms. This group should specify common base of functions as a separate effort? Interactive EDI: latency, response time. Health care industry wants access to patient benefits, records via EDI. Auto industry has ``critical shortages'' currently taken care of by interactive 3270 sessions which should be interactive EDI, e.g. truck leaving dock with following load, arrives your door in less than 15 minutes. Walt Houser, US. Veterans Administration: US Federal ECAT effort created by presidential memo. Electronic commerce in federal acquisition. Seeking convergence of multiple government EDI initiatives to present a single face to industry for government acquisition. Goals: single vendor registration process, standard trading partner agreement, one way of using the EDI standards, agency automation, virtual network, standard interface to vans, electronic cross agency servicing, electronic funds transfer incentives, ubiquitous e-mail. Thursday's Agenda o Sample table of contents for usage document o Detailed discussion of expected/intended contents o Assignments and schedule Usage Document The group must produce a usage document table of contents and writing tasks must be assigned. The purpose of the usage document is the following: o Review operational requirements of different kinds of EDI, based on existing practice. o Review of operational realities and choices for the current Internet. o Suggest feasible, current styles of EDI use. o Specify enhancement to Internet services to support additional EDI use. o Create a practice for reference within EDI X12 to a MIME body part. Security of the Internet. Many press reports cite instances of security problems of the Internet. But sensitive data can be sent using the Internet, even in clear-text, if the connection is controlled. Audience: o EDI consumers and providers (e.g., VANS) interested in use of Internet; o Managers consideration operational tradeoffs; o Translator developers and application developers considering interfacing to Internet transport services. Usage concerns, issues, etc: o carriage of EDI and other objects together o Response time and latency o Range of transport choices. o Accountatbility: A third party logging, guaranteed notice of receipt, audit trails o Integrity, checksum, signed end2end o X.400/X.435 interoperability o Concern for spoofing and software mailer bugs o Granularity of security (object versus field) o How is accountability handled for private lines? o Restricted list of trading partners o Tracking, tracing, timing of events, and place o Certification of EDI format o Standardized reporting o Performance -- lossiness, slowness (host versus net) o How to configure between users Usage and Primer: o Transport methodologies o Encoding - binary, control, text o Use of Mime multipart o Summary for executives: attend to the challenges o Auditability o Expectations for Internet performance (by transport) o Security choices o Citations and pointers o Trading partner screening o OMIT: Role of VANs or how things ``ought'' to be done. o Basic architecture(s): e.g., where is translation o FAQ o Examples o Attachments to the Internet Proposed Table of Contents and Assignments: o Audience (Dave) o Summary for Executives o Introduction: What is EDI over Internet? (Dave) o EDI Functional Requirements (Jim and Ray) o Internet Technologies (Bob) o Internet Operations (Stef) o Use of Technologies o FAQ (Michael) And observant reader will note that not all of the sections have authors assigned. This is an opportunity for some of you. (It was observed that another, more focused Usage document is going to be needed, to help EDI folks understand the relevant details of the MIME/EDI specification.) An incomplete draft is expected by 20 August. The first component draft (sections complete, but not fully integrated) is scheduled for 1 September and a completed draft is scheduled for 1 October. Conclusion The meeting adjourned with something of a wimper, probably due to the ambition of the schedule and the dauntingness of the writing tasks.