home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / edi / edi-minutes-94jul.txt < prev    next >
Encoding:
Text File  |  1994-11-01  |  9.5 KB  |  264 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Cynthia Mills/BBN and Walter Houser/GSA
  5.  
  6. Minutes of the Electronic Data Interchange Working Group (EDI)
  7.  
  8.  
  9. Wednesday's Agenda
  10.  
  11.    o Introductions, summary of the technical specification, current
  12.      goal, etc.
  13.  
  14.    o General discussion of issues surrounding ``use of EDI over the
  15.      Internet''
  16.  
  17.    o Presentation by Walt Houser, US Federal ECAT
  18.  
  19.  
  20. Introduction
  21.  
  22. This was the second meeting of the EDI Working Group.  The group is
  23. focusing on the carriage of EDI objects through simple encapsulation of
  24. EDI objects in MIME. EDI over X.400/X.435 already exists.
  25.  
  26. Three MIME objects, or content-type types have been defined:
  27.  
  28.  
  29.    o EDI-X12
  30.    o EDIFACT
  31.    o EDI-Consent
  32.  
  33.  
  34. There is a lot of structure that goes along with the unstructured EDI
  35. documents, therefore some ``unstructured'' or non-EDI objects may need
  36. to be encapsulated into other EDI objects to retain context.  Other EDI
  37. (and associated non-EDI) objects may be carried as separate MIME
  38. objects.  For EDI-specific semantic or syntactic work, there needs to be
  39. coordination with the EDI community on what objects will be standardized
  40. within EDI (e.g., EDI internal citation of MIME objects).
  41.  
  42.  
  43. General Discussion
  44.  
  45. The usage document is intended to assist the EDI and Internet
  46. communities in understanding the operational requirements for doing EDI
  47. over the Internet and to indicate current solutions.  Since this is a
  48. broad-ranging topic, the rest of the discussion time of the meeting was
  49. devoted to free-flowing exposition and discussion, saving the structured
  50. work for the next day.
  51.  
  52. Several mini-presentations were made by participants, along with the
  53. usual group discussion; none of the rest of this section is particularly
  54. coherent, from one paragraph to the next...
  55.  
  56. Robert Moscowitz, Chrysler:  Automobile Association will be requiring
  57. all OEM supplier information to be IP-based.  CAD group doesn't want to
  58. include CAD data INSIDE EDI, prefers to transport CAD data as separate
  59. data.  Their FastBatch process requires a 2-minute turnaround of EDI
  60. data, so mail approach does not have adequate response guarantee.
  61. (response time and latency) Also the range of transport choice is
  62. important.
  63.  
  64. The working group chair observed that there is a need to distinguish
  65. between high-level user requirements (core requirements) and engineering
  66. requirements (technical consequences of taking a particular
  67. implementation approach).  Security implications - using the
  68. Internet-at-large or Virtual Private Network (private internet with
  69. direct private line between two known parties).  Establish a core set of
  70. urgent capabilities with known limitations that can be implemented today
  71. and an extended set of action items that can be implemented later.
  72.  
  73. Eric Fleischman, Boeing:  has used EDI for many years.  Standardized on
  74. X.12 and UN EDIFACT. Try to carry this over X.400 and X.435.  Currently
  75. using X.25 public networks and many private links, some proprietary.
  76. Common transport inside Boeing is TCP/IP. Would like to do EDI between
  77. Boeing divisions VANs perform logging.  Internet is a best- effort type
  78. of thing.  Need accountability.
  79.  
  80.  
  81. More Discussion
  82.  
  83. Accountability:  Need accountability - want a guaranteed receipt of
  84. delivery and an audit trail to show what happened and exact recipient
  85. time.  (Is a third party necessary to keep impartial logs?  Private
  86. lines don't have a third party, how is accountability handled for
  87. private lines.)  Restricted list of trading partners.  Virtual private
  88. line can be provided by an encrypted tunnel between trading partners who
  89. have firewalls on the network.  Need Integrity:  checksum, signed end to
  90. end, digitally signed receipt.
  91.  
  92. Concern for spoofing, s/w mailer bugs:  These mailer bugs are common to
  93. many mailers, but managers only hear about SMTP bugs.  Should write some
  94. explanatory text to cover security issues and set the record straight.
  95.  
  96. X12.58 provides internal security for a single EDI field.  Granularity
  97. of security, object versus field.
  98.  
  99. Government requires timestamps for open bidding, etc.
  100.  
  101. Must track and trace documents through entire system -- from start to
  102. finish.  997 functional acknowledgement.  This is more than a receipt --
  103. it is a complete trail documenting a transaction or string of
  104. transactions.  Wanted by lawyers, accountants, auditors.  Must be able
  105. to PROVE time and place of contract formation.
  106.  
  107. Time-delayed delivery, X.400 has certain desirable store and forward
  108. facilities?
  109.  
  110. Jim Amster, AT&T: Co-chair of Communications Task Group at EDI? Liaison
  111. from X12C. Tracking ...  time of delivery AND time of
  112. receipt/reading/acceptance.  Want to debug and find lost documents.
  113.  
  114. Performance of the Internet is perceived as inadequate, by some.  Need
  115. guidelines on how to achieve reasonable performance over the internet.
  116. Perception generated by low- value-added services, rather than the
  117. underlying net.  Many suppliers are coming in at 2400 baud with bisync,
  118. so Internet will be perceived as faster.  (Note, less predictable in
  119. response time.)
  120.  
  121. Certification of EDI format.
  122.  
  123. Specify what's necessary for interoperability between MIME and
  124. X.400/X.435.  Separate and parallel, or gateway for translating between
  125. them?
  126.  
  127. X.435 includes security features, notifications.  This general
  128. capability (object and field level security?)  PEDI message replaces
  129. X.400 P2 header with the X.435 PEDI -- separate, not necessarily
  130. isomorphic control mechanisms.  This group should specify common base of
  131. functions as a separate effort?
  132.  
  133. Interactive EDI: latency, response time.  Health care industry wants
  134. access to patient benefits, records via EDI. Auto industry has
  135. ``critical shortages'' currently taken care of by interactive 3270
  136. sessions which should be interactive EDI, e.g.  truck leaving dock with
  137. following load, arrives your door in less than 15 minutes.
  138.  
  139. Walt Houser, US. Veterans Administration:  US Federal ECAT effort
  140. created by presidential memo.  Electronic commerce in federal
  141. acquisition.  Seeking convergence of multiple government EDI initiatives
  142. to present a single face to industry for government acquisition.  Goals:
  143. single vendor registration process, standard trading partner agreement,
  144. one way of using the EDI standards, agency automation, virtual network,
  145. standard interface to vans, electronic cross agency servicing,
  146. electronic funds transfer incentives, ubiquitous e-mail.
  147.  
  148.  
  149. Thursday's Agenda
  150.  
  151.    o Sample table of contents for usage document
  152.    o Detailed discussion of expected/intended contents
  153.    o Assignments and schedule
  154.  
  155.  
  156. Usage Document
  157.  
  158. The group must produce a usage document table of contents and writing
  159. tasks must be assigned.
  160.  
  161. The purpose of the usage document is the following:
  162.  
  163.  
  164.    o Review operational requirements of different kinds of EDI, based on
  165.      existing practice.
  166.  
  167.    o Review of operational realities and choices for the current
  168.      Internet.
  169.  
  170.    o Suggest feasible, current styles of EDI use.
  171.  
  172.    o Specify enhancement to Internet services to support additional EDI
  173.      use.
  174.  
  175.    o Create a practice for reference within EDI X12 to a MIME body part.
  176.  
  177.  
  178. Security of the Internet.  Many press reports cite instances of security
  179. problems of the Internet.  But sensitive data can be sent using the
  180. Internet, even in clear-text, if the connection is controlled.
  181.  
  182. Audience:
  183.  
  184.  
  185.    o EDI consumers and providers (e.g., VANS) interested in use of
  186.      Internet;
  187.  
  188.    o Managers consideration operational tradeoffs;
  189.  
  190.    o Translator developers and application developers considering
  191.      interfacing to Internet transport services.
  192.  
  193.  
  194. Usage concerns, issues, etc:
  195.  
  196.  
  197.    o carriage of EDI and other objects together
  198.    o Response time and latency
  199.    o Range of transport choices.
  200.    o Accountatbility:  A third party logging, guaranteed notice of
  201.      receipt, audit trails
  202.    o Integrity, checksum, signed end2end
  203.    o X.400/X.435 interoperability
  204.    o Concern for spoofing and software mailer bugs
  205.    o Granularity of security (object versus field)
  206.    o How is accountability handled for private lines?
  207.    o Restricted list of trading partners
  208.    o Tracking, tracing, timing of events, and place
  209.    o Certification of EDI format
  210.    o Standardized reporting
  211.    o Performance -- lossiness, slowness (host versus net)
  212.    o How to configure between users
  213.  
  214.  
  215. Usage and Primer:
  216.  
  217.  
  218.    o Transport methodologies
  219.    o Encoding - binary, control, text
  220.    o Use of Mime multipart
  221.    o Summary for executives:  attend to the challenges
  222.    o Auditability
  223.    o Expectations for Internet performance (by transport)
  224.    o Security choices
  225.    o Citations and pointers
  226.    o Trading partner screening
  227.    o OMIT: Role of VANs or how things ``ought'' to be done.
  228.    o Basic architecture(s):  e.g., where is translation
  229.    o FAQ
  230.    o Examples
  231.    o Attachments to the Internet
  232.  
  233.  
  234. Proposed Table of Contents and Assignments:
  235.  
  236.  
  237.    o Audience (Dave)
  238.    o Summary for Executives
  239.    o Introduction:  What is EDI over Internet?  (Dave)
  240.    o EDI Functional Requirements (Jim and Ray)
  241.    o Internet Technologies (Bob)
  242.    o Internet Operations (Stef)
  243.    o Use of Technologies
  244.    o FAQ (Michael)
  245.  
  246.  
  247. And observant reader will note that not all of the sections have authors
  248. assigned.  This is an opportunity for some of you.
  249.  
  250. (It was observed that another, more focused Usage document is going to
  251. be needed, to help EDI folks understand the relevant details of the
  252. MIME/EDI specification.)
  253.  
  254. An incomplete draft is expected by 20 August.  The first component draft
  255. (sections complete, but not fully integrated) is scheduled for 1
  256. September and a completed draft is scheduled for 1 October.
  257.  
  258.  
  259. Conclusion
  260.  
  261. The meeting adjourned with something of a wimper, probably due to the
  262. ambition of the schedule and the dauntingness of the writing tasks.
  263.  
  264.