home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / edi / edi-minutes-94dec.txt < prev    next >
Text File  |  1995-02-28  |  5KB  |  114 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Ned Freed/Innosoft International
  5.  
  6. Minutes of the Electronic Data Interchange Working Group (EDI)
  7.  
  8. The following minutes were compiled by Ned Freed, with a small(?)
  9. amount of creative distortion added by the working group chair, Dave
  10. Crocker.
  11.  
  12.  
  13.  
  14. Agenda
  15.  
  16.    o EDI in MIME specification has been technically stable for over 6
  17.      months.
  18.      Should the document now be approved by the Working Group and
  19.      submitted for consideration as a proposed standard?
  20.  
  21.    o Work on the EDI `usage' document.
  22.  
  23.  
  24.  
  25. EDI in MIME Specification
  26.  
  27. The current document deals with both the international standard for EDI
  28. (EDIFACT) as well as the national US standard (X12).  Other countries
  29. have comparable national standards, e.g.  TDI in the UK. Should the
  30. other national variants receive some consideration in the specification?
  31.  
  32. It was decided, after some discussion, that at a minimum EDIFACT should
  33. be described before X12 is described.  No action was taken to label,
  34. cite, or describe any other national variants.  [Chair's note:  the
  35. Internet-Draft version does not reflect the change in section ordering,
  36. but it has been updated for final submission.  DHC]
  37.  
  38. Concern was raised about the question of security mechanisms and the
  39. need for user solutions.  In particular, the issue of built-in EDI
  40. security mechanisms was raised.  These need to be mentioned in the
  41. security section as one of the ways to achieve security.  An extended
  42. discussion ensued, where the idea of specifying a ``preferred'' security
  43. mechanism was proposed.  Applications Area Director John Klensin noted
  44. that the confusion in this area is a reflection of reality, and this
  45. reality is what needs to be reflected in the document, not an ad hoc
  46. selection of some specific mechanism.
  47.  
  48. This concluded the discussion of the EDI in MIME specification.  It was
  49. agreed that a two week working group Last Call would begin on 10
  50. December 1994, and if no further objections were raised the document
  51. would submitted to the IESG for consideration as a Proposed Standard.
  52. [Chair's note:  The timer started a bit later.  DHC]
  53.  
  54.  
  55. The Usage Document
  56.  
  57. Discussion began with a poll of the audience to assess how many people
  58. were familiar with the usage document.  A fairly small number of people
  59. had read the latest draft, which made it problematic to achieve any
  60. major progress in this area.  The chair noted that this document is a
  61. difficult one in any case, in that it attempts to capture preferred
  62. sorts of actual use of EDI. The uses of EDI are changing rapidly, and
  63. any attempt to capture a static picture risks capturing practices that
  64. make sense only in the short term.
  65.  
  66. It was noted that EDI has historically been carried by Value Added
  67. Networks (VANs), which makes the transition to using the Internet, where
  68. any set of trading partners can directly exchange EDI messages, a very
  69. large one.  The ability to use EDI without third party auditing may be
  70. especially troubling in some contexts.
  71.  
  72. It was then noted that all this discussion is in fact exactly what
  73. belongs in a usage document, and it was suggested that the group should
  74. break the usage document down into pieces and assign individuals to the
  75. specific pieces.  Something like this:
  76.  
  77.  
  78.   1. Operational requirements.  (Jim Amster, Dave Ferenz)
  79.  
  80.   2. Operational realities
  81.      What are they on the Internet?
  82.      Note that the ``style'' of universities on the Internet does not
  83.      generalize to all service providers.
  84.  
  85.   3. Styles of use
  86.      Use of third parties.
  87.      What services must a third party provide?
  88.  
  89.   4. Scenarios, examples.
  90.  
  91.   5. System components, standards (RFC 822, SMTP, MIME, etc.).
  92.  
  93.  
  94. It was noted that one of the purposes of this working group was to
  95. acquaint the EDI community with Internet.  However, the Internet
  96. ``message'' has been spread by many other agencies, with the result that
  97. the EDI community has become aware of the Internet from many sources.
  98. Moreover, the EDI community has already acted on its own to develop the
  99. technology it sees as being necessary for using the Internet as a means
  100. of carrying EDI (e.g., security).
  101.  
  102. Hence, there probably is less need to be ``defensive'' about EDI over
  103. the Internet, but there are still real issues that all users of EDI on
  104. the Internet must deal with, and the usage document is needed to provide
  105. guidance in how to resolve these issues.
  106.  
  107. The meeting concluded with a discussion of what else belongs in the
  108. usage document.  The idea of talking about proprietary solutions was
  109. raised, as was the notion of surveying the list membership to find
  110. real-world solutions to include.  The first was vetoed as not being
  111. germane to the standards process and the second as not being an
  112. appropriate methodology for the IETF.
  113.  
  114.