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.