Date: Thu, 11 Aug 1994 21:38 EDT
From: Dave Crocker <dcrocker@mordor.stanford.edu>
Subject: Minutes of Toronto IETF EDI working group (in text)
EDI Working Group Meeting
Toronto, Ontario, CA
Chair, D. Crocker.
Minutes: Wednesday (Cindi Mills); Thursday (Walt Houser) --
with distortions and misrepresentations added by the chair.
Blame him, not them.
Note: These notes are rather longer than usual IETF meeting
minutes, since they are intended as input to the working
group's new effort at a "usage" document. They also
(accurately) reflect the somewhat free-ranging (or even
rambling and redundant) nature of the discussion, at times.
Agenda
Wednesday, 13:30 - 15:30
13:30 - 14:00 Greetings, intros, summary of tech spec,
current goal, etc.
14:00 - 15:00 General discussion of issues surrounding
"Use of EDI over the Internet"
15:00 - 15:30 Walt Houser, U.S. Federal ECAT
Thursday, 13:30-15:30
13:30 - 14:00 Sample table of contents for usage
document
14:00 - 15:00 Detailed discussion of expected/intended
contents
15:00 - 15:30 Assignments & schedule
WEDNESDAY
Intro
This was the second meeting of the working group. The WG is
focussing 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:
EDI-X12
EDIFACT
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, need to coordinate
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
particiularly coherent, from one paragraph to the next...
Robert Moscowitz, Chrysler: Automobile Assocation 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 WG 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 acountability.
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.
Graularity of security, object vs. 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 laywers,
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: Cochair 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. 703-681-0369
<houser.walt@forum.va.gov>
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 email.
Walt's presentation was extensive and a copy of his slides
are included in the IETF Proceedings.
THURSDAY
Rubber meets the road. Must produce Usage document table of
contents and some writing assignments.
The purpose of the usage document are the following:
o Review operational requirements of different kinds of
EDI, based on exisitng practise.
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 support of
additional EDI use.
o Creating a practice for refereince 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.
Usage document
Audience:
1. EDI consumers + providers (e.g., VANS) interested in use
of Internet;
2. Managers consideration operational tradeoffs;
3. Translator developers and application developers
considering interfacing to Internet transport services.
Usage concerns, issues, etc:
- carriage of EDI and other objects together
- Response time and latency
- Range of transport choices.
- Accountatbility:
A third party logging,
guaranteed notice of receipt,
audit trails
- Integrity, checksum, signed end2end
- X.400/X.435 interoperability
- Concern for spoofing & software mailer bugs
- Granularity of security (object vs. field)
- How is accountability handled for private lines?
- Restricted list of trading partners
- Tracking, tracing, timing of events, and place
- Certification of EDI format
- Standardized reporting
- Performance -- lossiness, slowness (host vs. net)
- How to configure between users
Usage and Primer
- Transport methodologies
- Encoding - binary, control, text
- Use of Mime multipart
- Summary for executives: attend to the challenges
- Auditability
- Expectations for Internet performance (by transport)
- Security choices
- Citations & pointers
- Trading partner screening
- OMIT: Role of VANs or how things "ought" to be done.
- Basic architecture(s): e.g., where is translation
- FAQ
- Examples
- Attachments to the Internet
Proposed Table of Contents (assignment)
1. Audience (Dave)
2. Summary for Executives
3. Introduction: What is EDI over Internet?
(Dave)
4. EDI Functional Requirements (Jim&Ray)
5. Internet Technologies (Bob)
6. Internet Operations (Stef)
7. Use of Technologies
8. FAQ (Michael)
Schedule
Messy, incomplete draft 20 Aug
First component draft 1 Sept
Sections complete, but not fully integrated
Completed draft 1 Oct
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 spec.)
The meeting adjourned with something of a wimper, probably
due to the ambitiousness of the schedule and the
dauntingness of the writing tasks...