CURRENT_MEETING_REPORT_

Reported by Ned Freed/Innosoft International

Minutes of the Electronic Data Interchange Working Group (EDI)

The following minutes were compiled by Ned Freed, with a small(?)
amount of creative distortion added by the working group chair, Dave
Crocker.



Agenda

   o EDI in MIME specification has been technically stable for over 6
     months.
     Should the document now be approved by the Working Group and
     submitted for consideration as a proposed standard?

   o Work on the EDI `usage' document.



EDI in MIME Specification

The current document deals with both the international standard for EDI
(EDIFACT) as well as the national US standard (X12).  Other countries
have comparable national standards, e.g.  TDI in the UK. Should the
other national variants receive some consideration in the specification?

It was decided, after some discussion, that at a minimum EDIFACT should
be described before X12 is described.  No action was taken to label,
cite, or describe any other national variants.  [Chair's note:  the
Internet-Draft version does not reflect the change in section ordering,
but it has been updated for final submission.  DHC]

Concern was raised about the question of security mechanisms and the
need for user solutions.  In particular, the issue of built-in EDI
security mechanisms was raised.  These need to be mentioned in the
security section as one of the ways to achieve security.  An extended
discussion ensued, where the idea of specifying a ``preferred'' security
mechanism was proposed.  Applications Area Director John Klensin noted
that the confusion in this area is a reflection of reality, and this
reality is what needs to be reflected in the document, not an ad hoc
selection of some specific mechanism.

This concluded the discussion of the EDI in MIME specification.  It was
agreed that a two week working group Last Call would begin on 10
December 1994, and if no further objections were raised the document
would submitted to the IESG for consideration as a Proposed Standard.
[Chair's note:  The timer started a bit later.  DHC]


The Usage Document

Discussion began with a poll of the audience to assess how many people
were familiar with the usage document.  A fairly small number of people
had read the latest draft, which made it problematic to achieve any
major progress in this area.  The chair noted that this document is a
difficult one in any case, in that it attempts to capture preferred
sorts of actual use of EDI. The uses of EDI are changing rapidly, and
any attempt to capture a static picture risks capturing practices that
make sense only in the short term.

It was noted that EDI has historically been carried by Value Added
Networks (VANs), which makes the transition to using the Internet, where
any set of trading partners can directly exchange EDI messages, a very
large one.  The ability to use EDI without third party auditing may be
especially troubling in some contexts.

It was then noted that all this discussion is in fact exactly what
belongs in a usage document, and it was suggested that the group should
break the usage document down into pieces and assign individuals to the
specific pieces.  Something like this:


  1. Operational requirements.  (Jim Amster, Dave Ferenz)

  2. Operational realities
     What are they on the Internet?
     Note that the ``style'' of universities on the Internet does not
     generalize to all service providers.

  3. Styles of use
     Use of third parties.
     What services must a third party provide?

  4. Scenarios, examples.

  5. System components, standards (RFC 822, SMTP, MIME, etc.).


It was noted that one of the purposes of this working group was to
acquaint the EDI community with Internet.  However, the Internet
``message'' has been spread by many other agencies, with the result that
the EDI community has become aware of the Internet from many sources.
Moreover, the EDI community has already acted on its own to develop the
technology it sees as being necessary for using the Internet as a means
of carrying EDI (e.g., security).

Hence, there probably is less need to be ``defensive'' about EDI over
the Internet, but there are still real issues that all users of EDI on
the Internet must deal with, and the usage document is needed to provide
guidance in how to resolve these issues.

The meeting concluded with a discussion of what else belongs in the
usage document.  The idea of talking about proprietary solutions was
raised, as was the notion of surveying the list membership to find
real-world solutions to include.  The first was vetoed as not being
germane to the standards process and the second as not being an
appropriate methodology for the IETF.