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.