Article 1286 of bit.listserv.edi-l: Path: cs.utk.edu!news.msfc.nasa.gov!europa.eng.gtefsd.com!howland.reston.ans.net!math.ohio-state.edu!cyber2.cyberstore.ca!vanbc.wimsey.com!usenet From: paulr@wimsey.com Newsgroups: bit.listserv.edi-l Subject: EDI & X.400 Date: Wed, 04 May 94 12:22:57 PDT Organization: Wimsey Information Services Lines: 29 Message-ID: <2q90d3$76d@wolfe.wimsey.com> NNTP-Posting-Host: pme12.bby.wis.net Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Newsreader: NEWTNews & Chameleon -- TCP/IP for MS Windows from NetManage I am researching the integration of EDI and X.400 and would like to correspond, whether through the mailing list or directly, with people who can give me overview information on any of the following topics: 1) Which industries, if any, have more need for X.400 EDI transmission? Are there any which require it? 2) Are VANs going to offer X.400 capability. What benefit does it have for them? 3) Is X.400 more/less critical to realtime/interactive EDI? 4) What is the difference between INtercative and Realtime EDI. I know that there is ongoing discussion of standards for Realtime can anyone point me to archives or documents where I can read up on this topic. 5) IS RT/Interactive more used in any industries? 6) Is X.435 an essential component in X400/EDI? 7) I believe that there is a 1988 X.400 standard. Is this now the most commonly used implementation? (or does this belong in the X.400 forum?) 8) Are there any industries/sectors that are morte likely to use the legacy mainframe for EDI rather than offload it to a UNIX box or PC? 9) Is it solely transaction volume that determines choice of platform to run EDI transmission? 10) Can anyone give me the address for DISA? 11) Is X.400/EDI more standard in Europe than N.A.? How about the Far East? All comments and info gratefully received. Thank you Paul Rickett Article 1287 of bit.listserv.edi-l: Path: cs.utk.edu!nntp.memst.edu!nntp.msstate.edu!paladin.american.edu!howland.reston.ans.net!usenet.ins.cwru.edu!news.ecn.bgu.edu!psuvax1!psuvm!auvm!AOL.COM!edi1smw Newsgroups: bit.listserv.edi-l Subject: Re: EDI & X.400 Message-ID: <9405042129.tn160047@aol.com> From: "Sylvia M. Webb" Date: Wed, 4 May 1994 21:29:06 EDT Sender: Electronic Data Interchange Issues Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU X-Mailer: America Online Mailer Comments: To: edi-l@UCCVMA.UCOP.EDU Lines: 19 Paul Rickett had several questions. The answer to one of them follows: <10) Can anyone give me the address for DISA?> DISA's address is: Data Interchange Standards Association Suite 200 1800 Diagonal Road Alexandria, VA 22314-2852 Telephone: 703-548-7005 FAX: 703-548-5738 I'll be glad to share the information I have on EDI & X400 over the next few days. Sylvia Webb EDI Systems Integration Company 310-671-1787 EDI1SMW@AOL.COM Article 1288 of bit.listserv.edi-l: Path: cs.utk.edu!nntp.memst.edu!nntp.msstate.edu!emory!news-feed-2.peachnet.edu!umn.edu!news Newsgroups: bit.listserv.edi-l Subject: Re: EDI in Health Care Message-ID: <17536.scstrike@maroon.tc.umn.edu> From: "scstrike@maroon.tc.umn.edu" Date: Fri, 6 May 1994 19:39:49 GMT Sender: news@news.cis.umn.edu (Usenet News Administration) Organization: University of Minnesota, Twin Cities To: jrl@landau.win.net X-Minuet-Version: Minuet1.0_Beta_11 Nntp-Posting-Host: dialup-1-17.gw.umn.edu X-Popmail-Charset: English Lines: 30 On Sun, 1 May 1994 14:16:47 LCL, Joe Landau wrote: > >The reason I write at such length of this situation is that I see it >repeating itself. "Standards" have been arrived at under the ANSI X12 >imprimatur and have been adopted by Medicare. Much of the private sector >will also use these standards. However, the standards, as far as I have >seen them, allow variation in implementation in just the way that Medicare's >NSF did. No hint of a validation suite, or agency, has reached my ears The >result will, of course, be the same. Instead of having Babel, we will have >Standardized Babel. This kind of standard-making is fine in a world where >there are relatively few trading partners who can negotiate with each other and >who have staffs of people who implement software for a living. It is absurd >when there are hundreds of thousands of partners, or even millions, who have >trouble hiring people who can read. > >Joseph R. Landau Applied Software Technology For what its worth, we recently supported the implementation of the 835 from the HCFA manual at one of the largest clinics in the United States. I am pleased to say 1) Translators DO have the ability to validate syntax 2) The HCFA guideline is very specific - the exception being with respect to reject codes may be payor specific if an X12 code is not available 3) The payors are very closely adhering the HCFA guidelines. The issues for discrepancies are not so much syntax related as they are with respect to agreeing on the meaning or value of the data itself. In Minnesota, there is actually a data standardization group, working on meaning, rather than syntax. Article 1290 of bit.listserv.edi-l: Path: cs.utk.edu!martha.utcc.utk.edu!darwin.sura.net!howland.reston.ans.net!news.cac.psu.edu!psuvm!auvm!NETCOM.COM!hsteck Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 6 May 1994 17:52:54 -0700 Sender: Electronic Data Interchange Issues From: Harry Steck Subject: Re: EDI in Health Care Comments: To: Electronic Data Interchange Issues Comments: cc: Multiple recipients of list EDI-L In-Reply-To: <199405062034.NAA29003@mail2.netcom.com> Lines: 51 The interactive EDI group within X12 is also very interested in evolving an unambigious, semantic value to the data exchanged via EDI (X12 and EDIFACT share this problem of semantic meaning). The PANAM EDIFACT group has been discussing the use of business models as a pre-requisit or accompanying documentation to requests for message development. I'm curious if others working on EDI (either message development or implementations) are using business models, process modeling, data modeling, etc as part of their development process? Harry H. Steck hsteck@netcom.com Electronic Commerce Solutions "Business Practices drive EDI..." Voice: (703) 905-1213 FAX: (703)590-5871 On Fri, 6 May 1994, scstrike@maroon.tc.umn.edu wrote: > On Sun, 1 May 1994 14:16:47 LCL, Joe Landau wrote: > > > >The reason I write at such length of this situation is that I see it > >repeating itself. "Standards" have been arrived at under the ANSI X12 > >imprimatur and have been adopted by Medicare. Much of the private sector > >will also use these standards. However, the standards, as far as I have > >seen them, allow variation in implementation in just the way that Medicare's > >NSF did. No hint of a validation suite, or agency, has reached my ears The > >result will, of course, be the same. Instead of having Babel, we will have > >Standardized Babel. This kind of standard-making is fine in a world where > >there are relatively few trading partners who can negotiate with each other > and > >who have staffs of people who implement software for a living. It is absurd > >when there are hundreds of thousands of partners, or even millions, who have > >trouble hiring people who can read. > > > >Joseph R. Landau Applied Software Technology > > For what its worth, we recently supported the implementation of the 835 > from the HCFA manual at one of the largest clinics in the United States. I > am pleased to say > 1) Translators DO have the ability to validate syntax > 2) The HCFA guideline is very specific - the exception being with > respect to reject codes may be payor specific if an X12 code is not > available > 3) The payors are very closely adhering the HCFA guidelines. > > The issues for discrepancies are not so much syntax related as they are > with respect to agreeing on the meaning or value of the data itself. In > Minnesota, there is actually a data standardization group, working on > meaning, rather than syntax. > Article 1291 of bit.listserv.edi-l: Path: cs.utk.edu!martha.utcc.utk.edu!darwin.sura.net!howland.reston.ans.net!news.cac.psu.edu!psuvm!auvm!AOL.COM!edi1smw Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l X-Mailer: America Online Mailer Message-ID: <9405062121.tn240663@aol.com> Date: Fri, 6 May 1994 21:21:03 EDT Sender: Electronic Data Interchange Issues From: "Sylvia M. Webb" Subject: Re: EDI in Health Care Comments: To: edi-l@UCCVMA.UCOP.EDU Lines: 65 Joseph R. Landau wrote in part: "The reason I write at such length of this situation is that I see it repeating itself. "Standards" have been arrived at under the ANSI X12 imprimatur and have been adopted by Medicare. Much of the private sector will also use these standards. However, the standards, as far as I have seen them, allow variation in implementation in just the way that Medicare's NSF did. No hint of a validation suite, or agency, has reached my ears. This kind of standard-making is fine in a world where there are relatively few trading partners who can negotiate with each other and who have staffs of people who implement software for a living. It is absurd when there are hundreds of thousands of partners, or even millions, who have trouble hiring people who can read." ================================================================== I have been involved in EDI implementation for the last nine years. Both as an employee and now as a consultant. FWIW, I'd like to comment to your statements. 1. The problem you address isn't a standards problem. It's a business practice problem. All of the good ANSI X12 translation software products validate for X12 syntax and X12 codes. The flexibility of the standards in no way limits the ability of application software providers to validate data. In fact, more stringent validation can occur because the user can dictate exactly what is to be validated to and from the application. Unfortunately, in far too many instances, application software providers do not invest in basic EDI/Electronic Commerce education which allows them to understand the the business problems that EDI can solve. More importantly, with such knowledge, software products can be developed that enhance the capabilities of the EDI translation products. 2. Because EDI using the X12 standards is computer to computer and not computer to human, there must be negotiation between trading partners prior to implementation. While it is labor and costly for small medical offices to perform this task on their own, there are companies and consultants with the expert knowledge needed who specialize in EDI trading partner implementation. Based on my experience with companies who fail to negotiate before implementing EDI, the cost of using EDI specialists is far less than the cost of trial and error. This is a fact regardless of the size of the companies involved. 3. Implementing EDI isn't a software or standards issue, although both have a substantial impact on implementing. EDI is a business issue. The challenge of changing business practices and procedures to exploit the benefits of electronic commerce. Creating an inflexible standard does not solve this problem. Small medical offices have even a greater need than their larger competitors to steamline business practices to permit them to remain competitive and provide quality services. Sylvia Webb EDI Systems Integration Company 310-671-1787 EDI1@AOL.COM Article 1319 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!howland.reston.ans.net!paladin.american.edu!auvm!MINDLINK.BC.CA!Bill_Laidley Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l Message-ID: Date: Sat, 14 May 1994 07:45:26 -0700 Sender: Electronic Data Interchange Issues From: Bill Laidley Subject: EDIFACT Standards Available Comments: To: EDI-L@uccvma.ucop.edu Lines: 37 Over the years there have been many postings asking about the availability of X12 or UN/EDIFACT standards on the Internet. I was just browsing the International Telecommunications Union Gopher server - it would appear that the EDIFACT standards are there for downloading. They have also provided copies of the meeting minutes, working papers, indexes, code lists, etc, etc. I'm impressed. If you work with EDIFACT you can not only access the standard over Internet, you can refer to the working papers to get clarification of obscure details. Three cheers and a large vote of thanks to the ITU! I believe that there is at least one person on this list from DISA - perhaps they could consider making available the working papers, meeting minutes, etc. It seems unlikely that DISA will make available X12 on the Internet. That being the case DISA may wish to look at its pricing for the standards. I teach courses on EDI, and in those courses I *always* recommend buying a copy of the standard. The students *always* reply that the price is too high, but they would be willing if the price were made reasonable. When Borland introduced their first version of Turbo Pascal it sold for about $70, the competition sold products in the $500 plus range. Borland is still with us, they made a profit, and most of the competition from those days are gone. I feel that a reasonable price for the X12 standards is between $100 to $200. At that level people would be willing to buy a copy, and sales would be *much* higher. -- ----------------------------------------------------------- Bill Laidley Electronic Data Interchange Consulting Internet: bill_laidley@mindlink.bc.ca Telephone: (604) 434-8576 ----------------------------------------------------------- Article 1322 of bit.listserv.edi-l: Path: cs.utk.edu!news.msfc.nasa.gov!europa.eng.gtefsd.com!paladin.american.edu!auvm!PANIX.COM!mfogel Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l Message-ID: Date: Sat, 14 May 1994 21:03:15 +1000 Sender: Electronic Data Interchange Issues From: "Mark A. Fogel" Subject: Re: Randall Smith's Observations Comments: To: Electronic Data Interchange Issues Lines: 40 Some observations from a "small business" person currently implementing a full blown implementation of EDI. 1. The greatest obstacle to implementation of EDI by small businesses IMHO, is cost. I currently pay a fee for every kilocharacter transmitted to my VAN. Simply by eliminating this cost, I believe EDI over the Internet can contribute to the more widespread use of EDI. 2. Each trading partner will use a different subset of the EDI standards that suits their business purposes. My limited experience as a small Manufacturer, is that my trading partners (large Retailers) dictate to me their own subset that they want to use. I have no choice in this. I then need a period of several weeks or months to map their version of the standards to my Accounting program. Having this information sent via EDI serves no useful purpose. A hard copy manual stating the specific data elements, qualifiers and what information they must contain is what is useful and what I currently receive. 3. There are 3 separate functions involved in EDI which must be kept separate. a. The transmission of EDI data ( directly, via VAN or over the Internet ) b. The translation software c. Mapping software to move to data to and from existing accounting app s. The largest contribution we can make on the internet to foster the spread and use of EDI is in area a. Vans can still have functionality for those who cant or won't use the Internet, Or as facilitators of Internet transfer of EDI documents, possibly as sort of a specialized access provider. They can still provide translation software, but so can other software companies. Hopefully, one of the intended results of the above, even for those who continue to use current transmission methods , will be drastically lower costs for transmission due to lower cost alternatives (ie:internet), as well as lower costs for the translation software. ===================================================================== Mark Alan Fogel mfogel@panix.com "Imagine if horse racing had no horses, thousands of people could go to the track each day & save millions of dollars." Julius H. Marx Article 1323 of bit.listserv.edi-l: Path: cs.utk.edu!news.msfc.nasa.gov!europa.eng.gtefsd.com!paladin.american.edu!auvm!MINDLINK.BC.CA!Bill_Laidley Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l Message-ID: Date: Sun, 15 May 1994 08:52:49 -0700 Sender: Electronic Data Interchange Issues From: Bill Laidley Subject: Location of ITU Comments: To: edi-l@uccvma.ucop.edu Lines: 13 I neglected to include the Internet address of the ITU Gopher server. It is 'info.itu.ch'. For those accessing it via a Gopher server - look in the menu for 'Other Gophers', then 'Europe', then 'Switzerland' and finally 'International Telecommunications Union'. -- ----------------------------------------------------------- Bill Laidley Electronic Data Interchange Consulting Internet: bill_laidley@mindlink.bc.ca Telephone: (604) 434-8576 ----------------------------------------------------------- Article 1327 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!howland.reston.ans.net!pipex!ibmpcug!ibmpcug!fzl!jmoore Newsgroups: bit.listserv.edi-l Message-ID: <27@fzl.win-uk.net> References: Reply-To: jmoore@fzl.win-uk.net (Jonathan Moore) From: jmoore@fzl.win-uk.net (Jonathan Moore) Date: Mon, 16 May 1994 10:47:58 GMT Subject: Re: EDI security Lines: 47 Anatole Shamrakov wrote: >If anyone could help me with outlining the major points when setting up a >security for an EDI system (just some general points) this would be greatly >appreciated. >Please post your answer on this newsgroup as my e-mail address has not been >set up properly. Perhaps I could kick this one off with the following brief outline, which is one of the clearest I have seen: (By Peter Green of Citibank Procedings of EDI 92, UK): Three Categories of Electronic Risks: Access Control - Is the Business Transaction Valid? - Created by authorised users - Validated/Authorised as Required - Protected within the organisation Data Communications - Did I receive what you sent? - Originator Authentication - Integrity of content - Non-repudiation of Origin - Non-repudiation of receipt - Sequence integrity - Confidentiality of content Business Validity - Is the Business Transaction Reasonable? - Valid trading partners - Individual amounts limits - Aggregate limits - Past behaviour I hope this is the kind of thing you are looking for Anatole. Best Regards Jon Moore IT Consultant Internet: jmoore@fzl.win-uk.net Article 1330 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!howland.reston.ans.net!paladin.american.edu!auvm!CAP.GWU.EDU!georgef Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 16 May 1994 09:14:54 -0400 Sender: Electronic Data Interchange Issues From: George Farnsworth Subject: ECAT draft-for-comments available Comments: To: EDI List Lines: 18 At the ECAT meetings of Friday the 13th it was announced that a review copy of their architecture is available by ftp at ds.internic.net. login as "anonymous: and give your email address as password (or "guest"). Change directory to: /pub/ecat.library/march.architecture and then either: ascii - for the text only or: postscript - for the PostScript versions or: acrobat.pdf They also provided an email address for the team as: useop_at_slf1@cc.ims.disa.mil _______________________________________________________________ I am not a member of the ECAT and I have not tried either of these addresses, they were part of the handouts at the meeting. There seems to be no secrecy about the project and there is a genuine interest in constructive feedback from both federal agencies and the business community. George Farnsworth, HUD georgef@cap.gwu.edu (personal internet account) Article 1333 of bit.listserv.edi-l: Path: cs.utk.edu!darwin.sura.net!nntp.msstate.edu!paladin.american.edu!auvm!NETCOM.COM!hsteck Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 16 May 1994 09:11:54 -0700 Sender: Electronic Data Interchange Issues From: Harry Steck Subject: Re: ECAT draft-for-comments available Comments: To: Electronic Data Interchange Issues Comments: cc: Multiple recipients of list EDI-L In-Reply-To: <199405161316.GAA18911@mail.netcom.com> Lines: 34 I can verify that the download works! I've downloaded the postscript version and even (hate to admit it) printed the package. Its quiet thick - say about 4inches of paper. But its full of interesting "stuff". I recommend you read it and comment - its like voting; if you don't, don't gripe out YOUR government. Thanks George for letting us know about the ECAT Files. "signed" Harry Steck Voice: (703) 905-1213 Electronic Commerce Solutions On Mon, 16 May 1994, George Farnsworth wrote: > At the ECAT meetings of Friday the 13th it was announced that a review > copy of their architecture is available by ftp at ds.internic.net. login > as "anonymous: and give your email address as password (or "guest"). > > Change directory to: /pub/ecat.library/march.architecture > and then either: ascii - for the text only > or: postscript - for the PostScript versions > or: acrobat.pdf > > They also provided an email address for the team as: > useop_at_slf1@cc.ims.disa.mil > _______________________________________________________________ > I am not a member of the ECAT and I have not tried either of these > addresses, they were part of the handouts at the meeting. There seems to > be no secrecy about the project and there is a genuine interest in > constructive feedback from both federal agencies and the business community. > > George Farnsworth, HUD > georgef@cap.gwu.edu (personal internet account) > Article 1334 of bit.listserv.edi-l: Path: cs.utk.edu!darwin.sura.net!convex!news.duke.edu!eff!news.umbc.edu!europa.eng.gtefsd.com!howland.reston.ans.net!paladin.american.edu!auvm!MORDOR.STANFORD.EDU!dcrocker Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l Contact: phone: +1 408 246 8253; fax: +1 408 249 6205 X-Mts: smtp Message-ID: <199405162125.OAA09991@Mordor.Stanford.EDU> Date: Mon, 16 May 1994 14:25:42 -0700 Sender: Electronic Data Interchange Issues From: Dave Crocker Subject: Mime encapsulation of EDI Comments: To: IETF-EDI@BYU.EDU, EDI List , ietf-822@dimacs.rutgers.edu Lines: 14 Folks, I've just submitted the final(?) draft of the spec for encapsulating EDI objects inside MIME. It will show up at your friendly, neighborhood internet-drafts directory as draft-crocker-edi-02.{txt,.ps} and I'm declaring this to be the final round of review. (Assuming, ahem!, that there is no strong consensus to the contrary...) Hence, I am vigorously requesting that you take a look and raise any concerns via the ietf-edi mailing list. I'd like to close the review at the end of next week, and then we can submit it for processing on the IETF standards track. Thanks. Dave Article 1337 of bit.listserv.edi-l: Path: cs.utk.edu!nntp.memst.edu!nntp.msstate.edu!olivea!charnel.ecst.csuchico.edu!nic-nac.CSU.net!usc!sdd.hp.com!swrinde!news.dell.com!paladin.american.edu!auvm!CC.IMS.DISA.MIL!useop Newsgroups: bit.listserv.edi-l Subject: Accessing the ECAT Electronic Library Message-ID: <9404177691.AA769193171@cc.ims.disa.mil> From: USEOP Date: Tue, 17 May 1994 09:46:11 EST Sender: Electronic Data Interchange Issues Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Comments: To: ietf-edi@byu.edu, Electronic Data Interchange Issues Lines: 148 The Federal Electronic Commerce Acquisition Team (ECAT) has made their draft report available via Internet for your review and comments. The report is organized in separate files. The Readme.txt file under the march.architecture directory describes all files in the library. The library can be accessed by the methods described below. ANONYMOUS FTP FTP to ds.internic.net. Login with the username "anonymous" and the password "guest". You will need to change to the Pub directory, then change to the ECAT.Library directory. Enter the following line to change to the correct directory: "cd ecat.library/march.architecture/{Enter}" The readme.txt file can be retrieved from this directory. Enter: "get readme.text[Enter]" to receive that file which describes the library contents. There are three directories under march.architecture called ascii, postscript, and acrobat.pdf. Each contains the file type of it's name. Change to the directory of choice ("cd[Enter]"). To receive a list of files in that directory enter "ls[Enter]". To retrieve a file enter "get". For example, to retrieve the Acrobat version of the Executive Summary file, in the acrobat.pdf subdirectory, the following commands would be entered: ftp> cd acrobat.pdf[Enter] ftp> get ex-sum.pdf[Enter] ELECTRONIC MAIL Send requests to "mailserv@ds.internic.net" and include the appropriate command in the message body. Commands must be entered in lower case letters. To receive the ECAT library "readme.txt" file, send the following command in the message body: file /pub/ecat.library/march.architecture/readme.txt To receive a list of documents in the ECAT library ASCII subdirectory, send the following command in the message body: ls /pub/ecat.library/march.architecture/ascii/ To receive a file from the ASCII subdirectory, send the following command in the message body: file /pub/ecat.library/march.architecture/ascii/ For other subdirectories use the same command lines, replacing "ascii" with another subdirectory name and entering the appropriate file name. The Mail Server treats PostScript and Acrobat.pdf files as ASCII text. To receive the Mail Server User Guide, send the word "help" in the message body. TELNET CLIENT TUTORIAL Telnet to ds.internic.net, login as guest. The "InterNIC Directory and Database Services (DS) Telnet Interface Main Menu" will appear. Number 2, "InterNIC Directory of Directories" brings up a WAIS client. After the welcome message a "Search->" prompt will appear. Commands are entered at this prompt. Only ASCII files are available from this location. To change the search base to the ECAT library enter "database ecat.library". To search this library enter "query". A list of files that contain the keyword is returned. Each file is identified by a number. To save a file enter "save #", where "#" is the number next to the file desired. You will be prompted to enter an email address which must be an Internet address. The file is sent to that address when the session is terminated. You can also view a file from a list. Enter "view #", where "#" is the number next to the file desired. After viewing a file there will be a "@Document, use or command->" prompt indicating you're at the document level. Enter "quit" to return to the search level. The "Search->" prompt will return. Files can only be saved directly from a list, so to save a previously viewed document, you have to query the database for another list. Enter "query " again. When the list of files is returned, enter "save#" as stated above. To end the session enter "quit". For more information about this client, enter "help" at the "Search->" prompt. Number 4, "Search the InterNIC DS Server File Space" brings up a "Enter file name or quit to exit:" prompt after the welcome message. Enter a file name. A list of file names that match the name or contain the name as part of their file is returned. If the desired file is located in the returned list, enter that complete file name and location (exact path from list). That one file is returned with an option to mail it. You are prompted to enter an email address which must be an Internet address. When binary files are mailed, an option is given to set your "file transfer by email parameters". The available options are uuencode, btoa, and mime. To end the session enter "quit". Number 5, "Browse the InterNIC DS Server File Space (Gopher)" brings up a Gopher client. This is a menu-driven client. Menu choices are made by moving the arrow key or entering the number of the menu item and pressing [Enter]. From the first menu choose number 4, "InterNIC Directory and Database Services (AT&T)". From the next menu choose 4 again, "InterNIC Database Services (Public Databases)". The ECAT library is located from the following menu. To view a document, enter the number next to that document or move the arrow key to point to that document and press[Enter]. When you quit from viewing a document, an option is given to mail the document and you are prompted for an email address. The address entered must be an Internet address. Only ASCII files will be mailed successfully. To end the session enter "q". Number 6, "Internet Public File Search (ARCHIE)" brings up an archie client. After the welcome message an "archie>" prompt will appear. Commands are entered at this prompt. The line above the "archie>" prompt will display the search type. The default is "exact" which means you will receive results from a search only when an exact match is found. It is advised that you change this option unless you know the exact file name(s) you will be searching for. To change this option enter "set search sub". The sub option will provide results on an exact match and when the keyword entered is part of a file name. For example, if "list" was a keyword for a sub search type, files with the name "listserv.exe" and "testlist.txt" would be included in the search results. But if list was used for an exact search type, only files with the name "list" would be included in the search results. To search for a document enter "find". A list of all file names that match the keyword or contain the keyword in their file name is returned. If you want to receive the list enter "mail". The address entered must be an Internet address. If the desired file is located in the returned list, enter another find command with the exact file name. That one file will be returned. Enter "mail". If the desired file is non-ASCII, prior to executing the mail command the following commands must be executed in order: archie>"set compress compress" archie>"set encode uuencode" All non-ASCII files mailed until the end of the session will be uuencoded. Uuencode is the only option for non-ASCII files from this client. To end the session enter "q". For more information on this client enter "help" at the "archie>" prompt. Article 1402 of bit.listserv.edi-l: Path: cs.utk.edu!news.msfc.nasa.gov!sol.ctr.columbia.edu!howland.reston.ans.net!paladin.american.edu!auvm!FREH-02.ADPC.PURDUE.EDU!MSHINES Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l Priority: normal X-Mailer: Pegasus Mail v2.3 (R5). Message-ID: <306922F1935@freh-02.adpc.purdue.edu> Date: Wed, 1 Jun 1994 15:14:56 EST Sender: Electronic Data Interchange Issues From: "Michael S. Hines" Organization: Purdue University Subject: Re: Trading Partner Agreements Lines: 27 Dan, Try Ben Wright's book, "The Law of Electronic Commerce: EDI, Fax, and e- mail", Little, Brown. I believe there is a sample TPA in there. >Date: Wed, 1 Jun 1994 15:29:00 - 0400 >Reply-to: Electronic Data Interchange Issues >From: Dan OKeefe >Subject: Trading Partner Agreements >To: Multiple recipients of list EDI-L > I am currently attempting to draft a Trading Partner > Agreement to use in support of our effort to implement > Electronic Commerce. I have Appendix E, Federal Government > Electronic Data Interchange rading Partner Agreement, from > the ECAT document, Streamlining Procurement Through > Electronic Commerce, dated April 29, 1994 but I would also > like to review samples that are already in use. Any > suggestions/assistance would be appreciated. > ---------------------------------------------------------------------- Internet: mshines@ia.purdue.edu | Michael S. Hines Bitnet: michaelh@purccvm | Sr. Information Systems Auditor Purdue WIZARD Mail: MSHINES | Purdue University GTE Net Voice: (317) 494-5845 | 1065 Freehafer Hall GTE Net FAX: (317) 496-1814 | West Lafayette, IN 47907-1065 CompuServe: 73240,1631 | America On-Line: mysterios | Article 1404 of bit.listserv.edi-l: Path: cs.utk.edu!news.msfc.nasa.gov!europa.eng.gtefsd.com!paladin.american.edu!auvm!!DeMarco Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l Message-ID: <53940601230935/0005305232NA3EM@mcimail.com> Date: Wed, 1 Jun 1994 18:09:00 EST Sender: Electronic Data Interchange Issues From: John DeMarco Subject: Trading Partner Agreements -Reply Lines: 27 When drafting TPA's, you should also obtain and read the 1990 Report of the American Bar Association's Electronic Messaging Task Force titled "The Commercial Use of Electronic Data Interchange -- A Report and Model Trading Partner Agreement". Part B of the Report contains an annotated Model TPA. The Model TPA is a good guide, but like all forms, it's _only_ a starting point. The Report is available (hard copy only, to my knowledge) from: American Bar Association Order Fulfillment Department 750 North Lake Shore Drive Chicago, IL 60611 Tel: (312) 988-5000 I hope you find this helpful. -- John ------------------------------------------------------------ John M. DeMarco, Esq. _______________________ Morgan, Lewis & Bockius | 6416533@mci.com 801 South Grand Avenue, 22nd Floor | CompuServe: 73710,1535 Los Angeles, California 90017 USA ----------------------- Fax: (213) 612-2554 Ph: (213) 612-1120 ------------------------------------------------------------ Article 1410 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!nntp.msstate.edu!paladin.american.edu!auvm!CSSMP.CORP.MOT.COM!khush Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l X-Mailer: Mail*Link PT/Internet 1.0.1 Message-ID: <199406071459.AA07177@cssmp.corp.mot.com> Date: Mon, 6 Jun 1994 22:00:31 -0500 Sender: Electronic Data Interchange Issues From: Ken Hush Subject: Re: CommerceNet Lines: 31 Commercenet is the first large-scale market trial of electronic commerce on the Internet. Membership for those organisations offering services on Commercenet is $25,000, but lower-priced memberships will also be available. Commercenet consortium consists of Xerox Corp, Apple Computer Inc and Bank America. The server is accessible via WWW and the Mosaic user agent. ------ From: Electronic Data Interchange Issues, Fri, Jun 3, 1994 ------ I am interested in finding out any information in relation to a product called "CommerceNet" Does anyone have any knowledge of such a product ? Ken Hush, Manager, Customer Satisfaction and Business Consultancy Corporate Computer Services 1299, E.Algonquin Road, Schaumburg, IL 60196 Phone: 708-576-6935 Motorola e-Mail: xtss40 FAX: 708-576-4153 Internet: xtss40@email.mot.com or khush@mot.com Cellular: 708-421-0579 AOL: Ken_Hush@aol.com EMBARC: Ken_Hush@embarc.roaming.com RadioMail: Ken_Hush@radiomail.net X.400: /c=us/admd=attmail/prmd=motorola/g=ken/s=hush/ddt=id/ddv=xtss40/ Article 1412 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!howland.reston.ans.net!news.cac.psu.edu!psuvm!auvm!COMPUSERVE.COM!76277.115 Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l Message-ID: <940607231033_76277.115_FHA63-2@CompuServe.COM> Date: Tue, 7 Jun 1994 19:10:33 EDT Sender: Electronic Data Interchange Issues From: "Jonathan M. Backus" <76277.115@COMPUSERVE.COM> Subject: Re: Need info on MACing Comments: To: EDI-L Lines: 23 Paul Khanna wrote: > I need some help. Can anyone tell me if there is a Method > Authentication Code (MAC) system available for midrange systems > (AS/400) Paul, First off, MAC stands for Message Authentication Code, as defined in the ANSI X9.9 standard and further defined for use with EDI in the X12.58 standard. Secondly, yes systems exist for mid- range computers. My company does NOT have anything for the AS/400, but we do have two different systems for the HP3000 (MPE/iX). If you would like information or have more questions I would be happy to try and answer them. Thanx, Jon Backus Racal-Guardata 480 Spring Park Place, Suite 900 Herndon, VA 22070 tel: 1-800-521-6261 fax: 1-703-437-9333 eml: 76277.115@compuserve.com Article 1421 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!howland.reston.ans.net!paladin.american.edu!auvm!STERLING.COM!Kent_Landfield Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l X-Mailer: ELM [version 2.3 PL11] Message-ID: <199406081607.AA16749@sparky.sterling.com> Date: Wed, 8 Jun 1994 11:07:50 CDT Sender: Electronic Data Interchange Issues From: Kent Landfield Subject: Re: FAQ/archive for this group? In-Reply-To: <199405300619.AA07211@sparky.sterling.com>; from "Olav Schettler I5.FIT" at May 29, 94 5:04 pm Lines: 20 > > Is there a FAQ for this group? Are there any archive sites? > > Kind regards, > -- > Olav Schettler > > GMD-SET > P.O. Box 1316 phone: +49 (2241) 14-2291 > Schloss Birlinghoven fax: +49 (2241) 14-2242 > D-53757 Sankt Augustin 1, Germany email: Olav@GMD.de > ftp.sterling.com:/edi/lists/edi-l -Kent+ -- Kent Landfield INTERNET: kent_landfield@sterling.com Sterling Software UUCP: uunet!kent || sparky!kent Phone: (402) 291-8300 FAX: (402) 291-4362 Please send comp.sources.misc-related mail to kent@uunet.uu.net. Article 1416 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!howland.reston.ans.net!paladin.american.edu!auvm!TIS.LLNL.GOV!frank Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l X-Orig-Date: Wed, 8 Jun 1994 00:24:15 GMT X-Orig-From: Australasian EDI Report/Technosocial X-Orig-Message-Id: <9406080039.AA02344@tis.llnl.gov> Message-ID: <9406080459.AA27944@ec002.tis.llnl.gov> Date: Tue, 7 Jun 1994 21:59:49 -0700 Sender: Electronic Data Interchange Issues From: "Robert E. Frank" Subject: Re: CommerceNet Comments: To: EDI-L%UCCVMA.BITNET@cmsa.berkeley.edu Comments: cc: medich@commerce.net Lines: 50 In Stewart Carter's message of 7 Jun 1994 at 1739 PDT, he writes: {Ken , in response to a query about Commercenet on EDI-L you said that { {Commercenet is the first large-scale market trial of electronic commerce on {the Internet. Membership for those organisations offering services on {Commercenet is $25,000, but lower-priced memberships will also be available. {Commercenet consortium consists of Xerox Corp, Apple Computer Inc and Bank {America. The server is accessible via WWW and the Mosaic user agent. { {--------- End of Original Message --------- { {My questions are, {1, does Commercenet have an address where I can contact it to find out {more info? Recommend you contact medich@commerce.net (Ms. Cathy Medich, CommerceNet Ex- ecutive Director) for factual information on CommerceNet. The current pric- ing is different and the consortium has many more sponsor companies than those listed above. {2, Is the US government envisaging becoming involved with its Electronic {Commerce proposals for government purchasing The US Government is co-sponsoring the CommerceNet program and providing ap- proximately 50% of the funding. Because of President Clinton's Electronic Commerce policies for federal government agencies which direct broad imple- mentations during the next two years (starting in September 94), CommerceNet should see widespread use by government agencies. {3, Is it the case that EDI is expected to be used for transactions {carried out through Commercenet? { {Stewart Carter {Editor {Australasian EDI Report {GPO Box 1240L {Melbourne Australia 3001 {Ph (+61) 3 602 1544 Fax (+61) 3 602-3216 CommerceNet plans to use a combination of WWW-based and EDI-based (EDI within SMTP/MIME/PEM-based e-mail) systems to accomplish all types of busi- ness transactions. The EDI Working Group is planning for a broad use of EDI within e-mail over Internet, and to exchange transactions via a gateway with qualified VANs. You can review the details by accessing EDI Working Group minutes under CommerceNet's URL http://www.commerce.net ====================================================================== Robert E. Frank, Electronic Commerce Project Lawrence Livermore National Laboratory, Livermore, California robert-frank@llnl.gov, PHONE: 510/422-0070, FAX: 510/424-5054 ====================================================================== Article 1418 of bit.listserv.edi-l: Path: cs.utk.edu!news.msfc.nasa.gov!europa.eng.gtefsd.com!howland.reston.ans.net!spool.mu.edu!nigel.msen.com!emory!nntp.msstate.edu!paladin.american.edu!auvm!AOL.COM!DudleyG Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l X-Mailer: America Online Mailer Message-ID: <9406080806.tn956800@aol.com> Date: Wed, 8 Jun 1994 08:06:18 EDT Sender: Electronic Data Interchange Issues From: DudleyG@AOL.COM Subject: Re: CommerceNet/ USGov EDI Comments: To: EDI-L%UCCVMA.BITNET@cmsa.berkeley.edu Lines: 59 Stewart Carter asked, among other things: "2, Is the US government envisaging becoming involved with its Electronic Commerce proposals for government purchasing" The government is very involved in trying to bring EDI into its procurement efforts, but there are numerous problems to resolve. At the moment, the Air Force may be the most active EDI user. But because of the current state of regulations, every EDI "order" is followed by a paper copy and only that may be treated as the legal order. This should soon change, as both legislative and regulatory efforts are underway addresssing it. Also, except for the Postal Service, these agencies cannot currenty issue orders in the simplified format for amounts in excess of $25K or $50K, depending upon the organization. Congress is currently changing that threshold to $100K. Ironically, a stumbling block in the change is that one house wants to tie it to the availability of EC; the other wants the change immediately. EDI for the government procurement function will probably never be a perfect mirror to the commercial environment, because the "Trading Partner" concept has severe limitations in the public sector. The trading partner implies a vendor selection process that involves a long term commitment over several requirements. The public sector acquisition model tends to the opposite: spread the wealth among the taxpaying vendors. Indeed, investigations are ongoing concerning alleged "bundling" by procurement organizations of numerous small requirements into larger ones to escape an automatic preference for small business. But even a small proportion of federal contracts is a large quantity of EDI transactions. And without question, that's the way things are heading. And there is an awful lot of current activity in the area. Some details. There's a presidential Executive Memorandum dated 10-26-93 which "calls for an initial federal electronic commerce system that permits exchange of requests for quotations (RFQ), quotes, purchase orders, and notice of awards by September 1994 and an expanded initial capability to include electronic payments, document exchange, and supporting databases by July 1995. The governmentwide implementation will not be complete until 1997." (quote source follows) Within DoD, "A team...produced the _DoD Electronic Commerce (EC)/Electronic Data Interchange (EDI) in COntracting Report_ dated December 20, 1993 that calls for more than 200 buying activities to be EDI capable through a standard EC/EDI procurement system over the next two years." (Both quotes froman article by Daniel J. Drake, CPCM, in the June 1994 Contract Management magazine.) The summary of the DoD report runs about thirty pages and is available on line in the GEnie Air Force roundtable, (system page 1035). The 200 activities represent a large proportion of the dollars expended, but a small proportion of the several thousand purchasing agencies within DoD. And the focus remains on simply-described commodities for which price-only acquisition is appropriate. That's just an overview. Hope it helps you. Feel free to contact me if you need to pursue any of this further. Dudley Glass Article 1419 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!howland.reston.ans.net!usenet.ins.cwru.edu!news.ecn.bgu.edu!psuvax1!psuvm!auvm!TIS.LLNL.GOV!frank Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l X-Orig-Date: Wed, 8 Jun 1994 08:06:18 EDT X-Orig-From: DudleyG@aol.com X-Orig-Message-Id: <9406081210.AA02894@tis.llnl.gov> Message-ID: <9406081543.AA00221@ec002.tis.llnl.gov> Date: Wed, 8 Jun 1994 08:43:15 -0700 Sender: Electronic Data Interchange Issues From: "Robert E. Frank" Subject: Re: CommerceNet/ USGov EDI Comments: To: EDI-L%UCCVMA.BITNET@cmsa.berkeley.edu Lines: 106 In Dudley Glass' message of 8 Jun 1994 at 0510 PDT, he writes: {Stewart Carter asked, among other things: { {"2, Is the US government envisaging becoming involved with its Electronic {Commerce proposals for government purchasing" { {The government is very involved in trying to bring EDI into its procurement {efforts, but there are numerous problems to resolve. At the moment, the Air {Force may be the most active EDI user. But because of the current state of {regulations, every EDI "order" is followed by a paper copy and only that may {be treated as the legal order. This should soon change, as both legislative {and regulatory efforts are underway addressing it. It is correct that the AF is highest volume user of all-electronic commerce technology, but it is *not* correct that paper follows the electronic order in the AF system. Mr. Glass seems to have mixed things up with the way some other DoD systems operate. And, he is *not* correct that paper is required by federal laws or regulations for small purchasing activities. The Lawrence Livermore Lab-developed Electronic Commerce system for the Air Force (named GATEC--Government Acquisition Through Electronic Commerce) does *not* use any paper between the buyers and the vendors. It is an "EDI within e-mail" approach. It is designed so customer requisitions can (when ever they wish) be e-mailed (using Internet MIME/PEM standards) to procurement and invoices/payments can be e-mailed (in the near future) between Defense Finance & Accounting Service offices. No changes or waivers to the Federal Acquisition Regulations or the laws were required to eliminate the paper by using the LLNL/AF GATEC approach. {Also, except for the Postal Service, these agencies cannot currenty issue {orders in the simplified format for amounts in excess of $25K or $50K, {depending upon the organization. Congress is currently changing that {threshold to $100K. Ironically, a stumbling block in the change is that one {house wants to tie it to the availability of EC; the other wants the change {immediately. This is not a major limitation because over 97% of all procurement actions are valued at less than $25,000. The increase to $100,000 for small purchase procedures will only involve another 2% of the volume. While this would be helpful in the short-run, the best solution is to complete the application of all-electronic contracting techniques for the over $25,000 categories and minimize the paper impacts on that area as well. {EDI for the government procurement function will probably never be a perfect {mirror to the commercial environment, because the "Trading Partner" concept {has severe limitations in the public sector. The trading partner implies a {vendor selection process that involves a long term commitment over several {requirements. The public sector acquisition model tends to the opposite: { spread the wealth among the taxpaying vendors. Indeed, investigations are {ongoing concerning alleged "bundling" by procurement organizations of {numerous small requirements into larger ones to escape an automatic {preference for small business. This is not really significant. Government procurement uses both long-term contracting relationships via such instruments as requirements contracts, as well as short-term, limited quantity orders. U.S. law provides special considerations for small and disadvantaged businesses. Electronic Commerce Through EDI procedures in GATEC makes it possible to establish a new way of dealing with "trading partners". Although business and government do not work exactly the same, the "EDI-within-email" approach minimizes the need to be concerned about the differences. If accomplished using the LLNL approach, the lowest prices can be obtained >from small and disadvantaged business. It is not a "spread the wealth" approach. More than 1,200 companies (all over the U.S.) have used 7 Value-Added-Networks and the Internet to exchange more that 2,000,000 EDI-within-email transactions during the past 18 months. Almost all of the orders were completed using public bidding via "EDI-within-email". Public competition was so heavily used by the AF for GATEC because the system design made it quick, easy, inexpensive, and cheaper to do so--for everyone involved. Prices have been reduced by 10-15% and vendors are making generous profits (due to significantly lower sales and operating costs using the GATEC procedures). Buyer and vendor productivity has been more than doubled (daily output more than doubled for every participant). And, there is *no paper* exchanged between buyers and sellers. {But even a small proportion of federal contracts is a large quantity of EDI {transactions. And without question, that's the way things are heading. And {there is an awful lot of current activity in the area. A lot of *activity* in a lot of agencies, yes; but, there is also a lot of reinventing the wheel going on. LLNL's design is an open systems approach which permits any vendor, any VAN and any agency to operate unique legacy systems, and to use a wide variety of networking approaches. The common denominator is an EDI transaction contained with an SMTP or X.400 e-mail envelope via Internet or a qualified VAN. Some agencies are simply "paving the paper cow-paths" with a few EDI formats. The end results (in terms of customer support, prices, operating costs and productivity) are not comparable to the AF GATEC system. However, there are a few commercial systems coming out which are technically *compatible* with the LLNL "EDI-within-email" approach and many agencies are considering the LLNL approach as the fastest and lowest cost way of achieving the federal mandates. -Bob Frank- ====================================================================== Robert E. Frank, Electronic Commerce Project Lawrence Livermore National Laboratory robert-frank@llnl.gov, PHONE: 510/422-0070, FAX: 510/424-5054 ====================================================================== Article 1448 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!howland.reston.ans.net!newsserver.jvnc.net!news.cac.psu.edu!psuvm!auvm!AOL.COM!DudleyG Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l X-Mailer: America Online Mailer Message-ID: <9406111742.tn1086310@aol.com> Date: Sat, 11 Jun 1994 17:42:30 EDT Sender: Electronic Data Interchange Issues From: DudleyG@AOL.COM Subject: Re: Gov EDI revisited: an order ain't a contract Comments: To: EDI-L%UCCVMA.BITNET@cmsa.berkeley.edu Lines: 119 Geeze, sorry: Bob Frank at Lawrence Livermore took some of my opinions to task. I certainly hadn't intended to mislead anyone. And before I launch into the following, let me preface it by saying that the main difference is one of perspective; I don't deny the utility of EDI, nor the huge current volume (altho its still a small piece of a $200 billion government contracting pie). I'm looking at all of this from the experience of dealing with policy implications and watching the shifting sands of the procurement universe for well over two decades... Mr. Frank is certainly right that there's plenty of activity, and maybe some benefits beyond the obvious, to EDI re the feds. But I obviously didn't clarify my points, which were for the most part intended to be predictive. The "paper follows" argument is the point which I think leaves the most confusion, and I apologize for not being more careful with my definitions of terms. Once two organizations have agreed--in writing, thank you very much, with real paper and all--to use EC, there's no hassle to ordering away without felling another tree. It's that first instance contract or agreement that must have a paper follows operation. And if a government agency issues an _ab initio_ purchasing document (not an "order" under a formalized agreement already in place) then under current law (at least as of 2 months ago) paper will bygod follow. (And does.) For a huge volume of transactions, this is simply not a problem (or won't be) because conceptually the installation of prior agreements to provide subsequent fully paperless behavior is a relatively trivial matter; it could be done at several stages of the process. (Altho some are better than others: with 14,000 or so purchasing agencies, I'd hate to do it on a one-by-one approach.) This is a lawyer's perspective, but in contracts it's a perspective to be reckoned with. (And there are several "unless, of course" comments that follow.) If you are the ordering agency and you've got nothing but an electronic RFQ, PO and acknowledgement, you've got zilch when it comes to proving your case in a dispute. And if you're the vendor and you have shipped on an electronic PO, don't ask me to try to enforce payment. Unless of course: the parties have a written agreement permitting such behavior, or there's no dispute as to the text of the messages, or there's a form of verifiable electronic signature/text which gives you both a method of demonstrating what was really sent/received (and by whom), OR there's a long term relationship of doing business in this way. (And that last may be of no use vis-a-vis government purchasing.) Look, the feds aren't obligated to abide by commitments unless made by specific, certified people (contracting officers or, for orders against existing contracts, their explicitly designated representatives). The intercession of easily alterable electronic methods only creates yet another layer of potential cover, once again in the case of a disputed transaction. And as in all commerce, let's be quick to point out disputes are rarer than tax reductions, almost. But it is at that margin that rules are designed, and at that margin that serious business decisions must often be made. As for the $100K threshold: To the procuring agency, and the vendors, this simplified purchase threshold difference is of immense significance, because the burdens of a "big purchase" are so disproportionately large. That two percent addition to the pool of simplified purchases may well represent a fifty percent or greater reduction in overall (not per transaction, which is more like 95%) administrative costs to a specific agency (depending upon its profile of requirements processed). And vendor performance costs drop dramatically as well, regardless of whether EDI is involved: this is because simplified purchasing carries substantially lower reporting and socioeconomic requirements. From the EDI perspective, as the value of a requirement increases, the attractiveness of fulfilling it electronically with current capabilities diminishes, not because of the value _per se_ but because these deals tend to be less of a "commodity" requirement. As I see it, the growth of EDI based transactons soon runs into serious problems when a "best value" procurement, one that involves selection of the vendor on elements other than merely price, is involved. And the current thrust is to expand best value, not contract --oops, reduce-- it. As for the trading partner problem, I stand my ground. This is (I hope obviously) an opinion, of course. But I believe you'll find that as the feds attempt to move more and more to long term arrangements, political resistance will be encountered. It helps to remember that federal procurement is not a rational market, for many reasons. And "spread the wealth," along with "broadest possible opportunity" are indeed underlying concerns of certain factions in the constant tensions of the field. These interests are threatened by EDI (you and I may think dropping some translation software into a PC and signing on to a VAN are trivial exercises, but we remain in the minority in this opinion). In some ways, the legal issues surrounding EDI are the "shrink wrap licensing" questions of the 90s. The bottom line is that ultimately, whether through legislation (for commercial transactions, the statute of frauds issue remains), litigation (imho, if decent encryption is used as a verification tool, you can satisfy the statute of frauds "writing" requirement without legislative assistance), or regulation (those "unnecessary" changes are being wrought for the Federal Acquisition Regs even as we debate, I'm given to understand). That's because, ultimately, the law will support the reasonable flow of commerce. But "law" and "politics" are different beasts, and there _are_ serious, albeit often hidden, political agendas that are threatened by EDI, precisely because it promises to open up the process in some ways (which threaten entrenched but inefficient providers), and tighten it up in others (it can raise the threshold of participation to new players). Speaking of new players, just for grins: the last GATT round included a side agt between the US and EU permitting cross-selling in the respective govt marketplaces, to the tune of $100 billion/yr. That means that, as of Jan 96 (assuming the agreement's approved by Congress) almost half the available US government procurement dollars will be available to European competitors. Probably won't be EDI type stuff. Probably... Hmm, I figure at least five "hell Glass don't know squat" responses from this one. Thing is, these are predictions, for the most part. Why don't we just watch what happens? And in the meantime, continue to use technology to offload all that administrative garbage that clogs the arteries of commerce. Dudley Article 1449 of bit.listserv.edi-l: Path: cs.utk.edu!martha.utcc.utk.edu!darwin.sura.net!convex!news.duke.edu!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!lll-winken.llnl.gov!decwrl!get.hooked.net!news.sprintlink.net!bga.com!slip195.bga.com!trevr From: trevr@bga.com (Trevor Richards) Newsgroups: bit.listserv.edi-l Subject: Re: ISO/ANSI data standards ? Date: Sun, 12 Jun 1994 16:56:47 GMT Organization: Real/Time Communications - Bob Gustwick and Associates Lines: 50 Message-ID: References: NNTP-Posting-Host: slip195.bga.com X-Newsreader: Trumpet for Windows [Version 1.0 Rev B] In article Rolf Lippelt writes: >To: EDI-L --INTERNET edi-l@uccvma.ucop. >*** Resending note of 06/07/94 17:49 >Keith Carpenter writes: >>The EDI formats themselves are documented well, it's the data itself that >>is not so well described. >> >>For example; >>Our company is in the ocean carrier shipping industry and I would like find >>the ISO standard tables for Port identifiers (ie. Los Angeles, Hong Kong, >>etc.) and other data elements used in the X12 formats. >>--------------------------------------------------------------------------- >A quick browse through my X12 Data Element Dictionary lists the following 3 >elements: E112-Pier Name, E113-Pier Number, E114-Port Name. None of these have >a codeset. In particular, E114-Port Name is an alphanumeric data type, minumum >2 chars, maximum 24 chars and the description is: > "... Free-form name for the place at which an offshore carrier originates > or terminates its actual ocean carriage of property..." >So I would guess that almost anything is valid. Of course you would want to >ensure that your trading partner(s) understand the data that you send. >I don't know if the ocean shipping industry has a set of industry specific >port codes. I do know that the airline industry does. For example, if you look >at E5-Airport codes, the description says: > "... Code (IATA) for airport ..." >The airline industry has gotten together and assigned a code to each of the >airports in the world. For example Los Angeles is LAX, Hong Kong is HKG, >London Heathrow is LHR etc. This makes it very simple. You might want to >investigate whether something like this exists for your industry. A body called the Information Systems Agreement (201 514-5183) publishes the Ocean Transport Industry Guide to Electronic Data Interchange which contains a general introduction, implementation details for Carrier/Customer and Carrier/Terminal transactions, extensive examples AND code lists. The technical contact for this publication is Tim Huckbody (phone 201 514-5183, fax 201 514-5048). It can be ordered through Washington Publishing Company for $185 (phone 301 590-9337, fax 301 869-9460). Trevor Richards Trinary Systems Austin, TX phone : 512 345 3981 fax : 512 345 8705 e-mail : trevr@bga.com Article 1451 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!paladin.american.edu!auvm!CPCUG.ORG!hartong Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 13 Jun 1994 10:30:25 -0400 Sender: Electronic Data Interchange Issues From: Mark and Rebecca Hartong Subject: Re: Gov EDI revisted: an order ain't a contract Lines: 45 Having spent the last ten years in and around Department of Defense government procurements, I believe dudley@aol.com has hit the nail on the head. Because of the nature of public (vs private) expenditure's of funds, both improvements in technology (authentication and non repudiation) and changes to the FAR will be required before EDI can be used to more effectively by the government. The difference between how private corporations and the government set up EDI interchanges is not all that much different in concept- it's just the fed's tend to make it a bit more difficult in practice. The government makes a very clear difference between who can contract for goods and services, and who can order goods and services. By law, only warranted contracting officers can contractually obligate the government for the expenditure of public funds. The government is under no obligation to accept claims for payment for goods and services provided by an individual or corporation unless approved by a contracting officer. Once a contract has been put in place, then any government activity with funds can place orders against the contract (assuming that the contract doesn't limit the order placing to one specific government activity). This is not to different from the commercial sector- both parties have to agree in advance that they will use EDI and that they will be contractually bound by transactions generated. The number of people for a particular company who can initially accept the use of EDI on a contractual basis is very limited. The difference is that the federal government, because it has to support certain social goals (for example small business assistance), and has to be able to ensure and demonstrate that the public funds are spent to provide not only the best value for the public, but are equitably spent, has significantly more complex rules. Mark *********************************************************************** Mark and Rebecca Hartong Two Computer Scientists, One Shared Account! "Mankind in Service to Machines" *********************************************************************** Article 1452 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!howland.reston.ans.net!EU.net!Austria.EU.net!paul From: paul@eunet.co.at (Paul Gillingwater) Newsgroups: bit.listserv.edi-l Subject: Privacy of EDI Date: 13 Jun 1994 15:34:55 GMT Organization: EUnet EDV-Dienstleistungsgesellschaft m.b.H Lines: 22 Message-ID: <2thuav$dvr@c2.eunet.co.at> References: NNTP-Posting-Host: hp4at.eunet.co.at X-Newsreader: TIN [version 1.2 PL0] Dave Crocker (dcrocker@MORDOR.STANFORD.EDU) wrote: : I also suspect that limited use of privacy technology can be applied to : cover transmission of sensitive data. As an EDI newbie, I'm interested for a general perspective on how technology like TESSERA (Clipper-based PCMCIA) for both encryption and digital signature standards will apply to EDI. Has anyone started defining how this should be folded in, or is there already sufficient flexibility in the current standards to allow for various encryption and authentication mechanisms? I should mention that my focus will be UN-EDIFACT, as I'm working with the United Nations to promote EDI for electronic reporting of selected statistical information by member states. I would also be interested in corresponding with others who are interested in that particular aspect of EDI. -- paul@actrix.co.at (Paul Gillingwater) :: Home Office in Vienna, Austria If you read news with rn or trn, try EEP! the friendly .newsrc editor. Waffle users, try Boxer for Windows--FTP eunet.co.at:/pub/news/eep. Article 1455 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!paladin.american.edu!auvm!!" Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l MR-Received: by mta STATE; Relayed; Tue, 14 Jun 1994 09:05:42 +0930 Alternate-recipient: prohibited Disclose-recipients: prohibited MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Posting-date: Mon, 13 Jun 1994 23:30:00 +0930 Importance: normal Priority: normal X400-MTS-identifier: [;24509041604991/140921@STATE] A1-type: MAIL Hop-count: 1 Message-ID: <01HDIZDU430M005BP4@mr.ss.sa.gov.au> Date: Mon, 13 Jun 1994 23:21:00 +0930 Sender: Electronic Data Interchange Issues From: "Peter Murchland 226 2805 (08)" Subject: Port Codes Lines: 23 Keith Carpenter was enquiring about identifiers for ports for use by his company involved in the ocean carrier shipping industry. Having previously worked for a port authority, I am aware that there is a set of standard location codes which are utilised within various EDIFACT message standards used by international shipping companies, customs authorities and port authorities. My recollection is that the code was an ISO standard, and was referred to as the UN/LOCODE. Reference to the EDIFACT messages within the IFTM set will shed more light. If you are operating in the international shipping arena, then there may be merit in serious consideration of implementing EDIFACT messages rather than X12 messages (which I understand the US is more prone to using). ------------------------------------------------------------------ Peter Murchland Office of Information Technology Phone +61 8 226 2043 Fax +61 8 410 2981 Email Murchland.Peter@Statemail.SA.Gov.Au Mail GPO Box 1484, Adelaide, Australia 5001 ------------------------------------------------------------------ Article 1512 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!nntp.msstate.edu!paladin.american.edu!auvm!DPCDEV.DPCSYS.COM!dan Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1023 Message-ID: <9406280833.aa29409@dpcdev.dpcsys.com> Date: Tue, 28 Jun 1994 08:33:56 -0700 Sender: Electronic Data Interchange Issues From: Dan Busarow Subject: Re: Credit Card POs In-Reply-To: <9406272236.aa24341@dpcdev.dpcsys.com> from "Tom Jones" at Jun 28, 94 00:29:00 am Lines: 24 Tom Jones wrote: >Well, actually there are standards that I expected to use. Either the >ANSI X12.58 or one of the email encryption standards like PEM or PGP >should work just fine. Now the real question, would companies accept >credit card orders in this format? The folks at CommerceNet are working on this right now. They are working within the framework of HTTP and WWW, they are also looking at PEM and PGP as well as DES for encryption. Dissemination of the keys appears to be the biggest problem. Since their solution will take advantage of the interactive nature of HTTP connections, building on their work would probably require the use of I-EDI or multiple EDI transactions. Check on http://www.commerce.net for news of progress and also look for information on SHTTP (Safe HTTP) which appears to hold some promise. Dan -- Dan Busarow dan@dpcsys.com uunet!cedb!dan DPC SYSTEMS Monrovia, CA (818) 305-5733 Article 1513 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!paladin.american.edu!auvm!MORDOR.STANFORD.EDU!dcrocker Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Date: Tue, 28 Jun 1994 09:53:24 -0700 Sender: Electronic Data Interchange Issues From: Dave Crocker Subject: IETF EDI working group meeting, Wed&Thur, 27&28 July Comments: To: ietf-announce-post@cnri.reston.va.us Comments: cc: IETF-EDI@BYU.EDU Lines: 34 The IETF's EDI working group is developing specifications for the carriage of classic EDI traffic over the Internet. A draft specification for the encapsulation of EDI within MIME is nearing completion. The second deliverable for the working group is an informational document offering guidelines for use of EDI over the Internet. The working group has not begun to discuss this topic in earnest. The Toronto meetings of the working group will be used to that end. BOTH MEETINGS WILL BE MULTICAST OVER THE MBONE, TO PERMIT PARTICIPATION BY THOSE UNABLE TO ATTEND IN PERSON. It would be helpful to have some indication about participation. Please send me private mail if you plan to attend via the mbone. Meetings are scheduled for 1330-1530 Eastern time, Wednesday and Thursday. By the end of the Thursday meeting, we will produce: a) a detailed outline of the "usage" paper, b) portions of content for some of the sections, and c) individual writing assignments. Wednesday, the primary task will be to conduct a free-ranging discussion of usage issues, with some effort to begin the outline. (I also suspect that bits and pieces of useful text will emerge. The more folks who take notes with laptops, the better.) Roughly the last 30 minutes of meeting will be a summary by Walt Houser on the ECAT report on US Federal electronic commerce. Thursday will be focus entirely at producing useful output. Dave +1 408 246 8253 (fax: +1 408 249 6205) Article 1530 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!usenet.ins.cwru.edu!ns.mcs.kent.edu!news.ysu.edu!malgudi.oar.net!news.pipeline.com!not-for-mail From: morphc@pipeline.com (Chris Morphew) Newsgroups: bit.listserv.edi-l Subject: Re: X12 software survey? Date: 11 Jul 1994 09:31:36 -0400 Organization: The Pipeline Lines: 24 Message-ID: <2vrhjo$oi3@pipe1.pipeline.com> NNTP-Posting-Host: pipe1.pipeline.com >I need to know what X12 packages are on the market >today and (if possible) what they do. Please email me >if you have experience with specific X12 packages or >know of a good product list. I will summarize to this >group. >-- > >Brian Harp > >Software Architect There is a publication called "EDI World, The Source for Electronic Data Interchange Management". This month they published their list of the 1994 EDI software directory, a comprehensive, easy to read listing of the leading EDI software products. They can be reached at 2021 Coolidge Street, Hollywood, Florida 33020-2400, (305)925-5900, fax(305)925-7533. Chris Morphew Project Manager, EDI Cash Management Services The Toronto-Dominion Bank Leaders in Financial EDI Article 1532 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!howland.reston.ans.net!news.intercon.com!news1.digex.net!usenet From: artch@agriffin.cpcug.org Newsgroups: bit.listserv.edi-l Subject: Security Policy paper on ftp.sterling.com Date: 14 Jul 1994 01:40:01 GMT Organization: Athena Associates, Inc. Lines: 32 Distribution: world Message-ID: <30251h$c8c@news1.digex.net> Reply-To: agriffin@cpcug.org NNTP-Posting-Host: agriffin.cpcug.org Summary: Weiss paper on security requirements and evidentiary issues available X-Newsreader: IBM NewsReader/2 v1.02 Mr. Peter Weiss, of the Office Of Management and Budget (OMB, part of the Executive Branch of the U.S. government) has been kind enough to make the following paper available: _Security Requirements and Evidentiary Issues in the Interchange of Electronic Documents: Steps Toward Developing a Security Policy_. The Introduction begins: "This report represents continuing work by OMB to develop policies and practices to encourage the use of Electronic Commerce techniques to imporve the efficiency of government operations and service to the citizen." I have converted it from Word Perfect to a PostScript file. (The tables should be landscape, but my print driver is smarter than I am.) It has been placed on ftp.sterling.com; look for it to show up in the /edi directory as weiss01.zip 33167 bytes. The zip contains weiss.ps 99263 bytes. Thanks to Kent Landfield at Sterling Software. This document is quite interesting, not only for its content, but also for its footnotes and references. I hope you fine it useful, provocative, interesting, . . .. Artch James A.(Artch) Griffin Athena Associates, Inc. Article 1534 of bit.listserv.edi-l: Path: cs.utk.edu!news.msfc.nasa.gov!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!lyra.csx.cam.ac.uk!warwick!uknet!news From: charlesa@learned.co.uk Newsgroups: bit.listserv.edi-l Subject: LI NewsWire 1.3 now out... Date: Thu, 14 Jul 94 19:03:02 BST Organization: EUnet GB Lines: 71 Message-ID: <303uk2$a1s@marble.Britain.EU.net> NNTP-Posting-Host: neptune.learned.co.uk Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Newsreader: NEWTNews & Chameleon -- TCP/IP for MS Windows from NetManage The new edition of the LI NewsWire - issue 1.3 - is hereby published for free browsing on the Internet. Top stories this month include a report on Mead Data Central's situation, Germany's online information market, US Wests' move into European information, news from the Financial Times, Oracle, IBM, Dataware, BRS, the SGML community, among other stories and features. Electronic Documents' review of WordPerfect's forthcoming Envoy can be downloaded in both PostScript and Acrobat formats. The review pits a beta version of Envoy against Acrobat and competitors. As Envoy is still in beta, we can't release it in envoy format with embedded viewer. The NewsWire may be accessed via the World Wide Web at , and Gopher users can access the journal via . FTP access for the Envoy review is available via , if you are unable to access the InfoNet via the Web or Gopher. Access via the World Wide Web has the advantages of hyperlink Table-of-Contents, formatting, and graphics. You may find the previous paragraph in HTML below. Enjoy! Charles Ashley Learned Information charlesa@learned.co.uk -------------------------------------------------------------- LI NewsWire 1.3 Table-of-Contents: INFORMATION WORLD REVIEW Mead Data Central seeks a better owner US West buys Thomson Directories FT cleared of monopoly charge Industry growth slows in Germany ELECTRONIC DOCUMENTS Text Encoding Initiative Guidelines introduced Text summarizing software announced IBM claims capacity breakthrough for CDs First joint moves from Dataware and BRS Envoy review - PostScript Envoy review - Acrobat ONLINE & CDROM REVIEW Name authority files and humanities database searching The Internet: Implications for the information industry and database providers Automated cataloguing and retrospective conversion in the university libraries of Spain New Database Products: Business and Law The perils of Nostradamus -- IT forecasting Electronic Publishing Trends Information agents -------------------------------------------------------------- The new edition of the LI NewsWire 1.3is hereby published for free browsing on the Internet. Top stories this month include a report on Mead Data Central's situation, Germany's online information market, US Wests' move into European information, news from the Financial Times, Oracle, IBM, Dataware, BRS, the SGML community, among other stories and features. Electronic Documents' review of WordPerfect's forthcoming Envoy can be downloaded in both PostScript and Acrobat formats. The review pits a beta version of Envoy against Acrobat and competitors. Article 1584 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!europa.eng.gtefsd.com!library.ucla.edu!paris.ics.uci.edu!news.service.uci.edu!orion.oac.uci.edu!flehmann From: flehmann@orion.oac.uci.edu (Fritz Lehmann) Newsgroups: bit.listserv.edi-l Subject: Re: EDI semantics (LONG) Date: 28 Jul 1994 07:12:28 GMT Organization: University of California, Irvine Lines: 210 Message-ID: <317los$csg@news.service.uci.edu> References: NNTP-Posting-Host: orion.oac.uci.edu I sent the following message to the new list "edi-new". I am posting it here because it is about "EDI Semantics" and it touches directly on how two parties can tailor the standard to just the necessary segments and fields needed for their transactions. Those of you trying to solve immediate problems in EDI may want to skip this, since it deals with future EDI directions. ---------------------------------------------------------- The "edi-new" list is a good development. I feel that it could be even a bit more up-to-date on the possibilities of "new EDI", though, based on the archived messages I've seen. The general Electronic Data Interchange (EDI) problem is that the current EDI participants, for practical reasons, have stayed within a pretty narrow idea of EDI limited essentially to printed standards for data formats, and programs which (fairly mundanely) implement them. EDI transactions, segments and fields are now just electronic versions of printed forms containing data. What is happening in the outside world, though, is a transcending of mere data bases and data transactions, towards "knowledge bases" and "intelligent agent transactions". There is a movement going on worldwide for what is called "knowledge sharing" -- including the ARPA Knowledge Sharing Effort in the USA and similar efforts in Europe. Unlike current EDI, this aims to transmit the _meaning_ of data along with the data. This requires at least some (machine-negotiated) sharing of an "ontology" or a concept-system for describing things and events in the real world. Concepts like "person", "order", "time", "destination" and "payment" have formal conceptual definitions. A well-known attempt at this in the Artificial Intelligence community is the CYC project led by Lenat and Guha at MCC in Austin, Tex. This is one of several different concept-systems; no one concept-system serves all purposes, but they must have some common ground in order for disparate systems to communicate. A similar system is part of the proposed ANSI IRDS Conceptual Schema, in which databases describe their subjects, and themselves, in "metadata" that are logically and even philosophically based on structures of basic conceptual primitives. Another is the related enterprise-integration system of Ontek, Inc. in Laguna Hills, Cal. The designated languages for these systems are Conceptual Graphs, the Knowledge Interchange Format (KIF), and CYC's Epistemological Language, all of which are machine-usable enhancements of symbolic logic -- "position- independent" -- and are nearly inter-translatable. When these and other knowledge-based systems are better harmonized (soon, I believe), information on any subject can flow from one system into another and be "understood" by the receiving machine to the extent that common ontological ground can be established automatically. Since these are logic-based-systems using semantic primitives, they have completely extensible semantics and they won't get obsolete due to an outdated specialization level. Establishing the ontological "common ground" automatically (between, say, a purchasing agent and a selling agent) by machine- negotiation is a natural further development beyond the proposed "ICSDEF message" (Interchange Structure Definition) currently being urged by Ken Steel at U. of Melbourne as the key to "open EDI". Before any binding transactions take place, two programs define for each other their respective capabilities and needs. In the case of mismatches, they try to agree on a maximal common concept-system and on the right set of message segments and fields. The actual "standard" used for subsequent transactions is defined in this initial negotiation. This is related to the "KQML" language for interagent communication, also part of the ARPA Knowledge Sharing Effort. There's no need to render current standards obsolete -- in fact the "generic" ontologies and existing international EDI standards (if properly defined conceptually) can serve as a _starting_point_ for the two programs to tailor the standard needed for their specific relationship. In EDI now, human beings in two different organizations must negotiate to agree upon the specific protocol for Purchase Order applications, etc., and programmers then create translators to and from the local databases. The two communicating computer systems do not "know" what is in the segments and fields -- they can only check for syntactic correctness at best. The only meaning is in English language remarks and definitions in standards documents, and in the fact that human beings are checking the printed versions of the transactions. (Ken Steel has reported that 70% of EDI documents are actually paper mailed or FAXed human-to-human!) In future EDI, each system will have a conceptual definition of what it _means_ to be, say, a "confirmation", and it will be able to detect automatically whether a confirmation in a particular transaction makes any sense. At present the EDI standards have a notion of the price paid for a product, but no notion of what that product is, nor its proper specification parameters. There is just a human-readable description, an arbitrary designated part-number, or something similar. These too are becoming obsolescent. The PDES/STEP standards for manufacturers are now beginning to emerge (complicated standards for product descriptions and specifications; they now cover machined shapes, CAD specifications, assemblies, electronic components and some other areas). These will eventually be extended to almost all areas of commerce. These are also being linked into the "knowledge level" and defined conceptually, so that, coupled to intelligent EDI, a computer will "understand" automatically that a Purchase Order to ship four Mack Trucks in one Post Office Mailsack is ill-advised. Similarly, U.S. Government procurement will have built-in machine safeguards against certain unsound, nonsensical or illegal transactions. Nitin Borwankar of Sybase (nitin@sybase.com) called for the first step: the use of metadata for describing the contents of EDI fields: QUOTE: "The *meaning* of each of these transactions/segments/fields etc. is defined *out-of-band* in the X.12 standards documents which are needed to decode an encoded EDI message. I propose that the meaning of each transaction/segment/field etc. be included in the new-EDI message, in a structured way, which is human readable. Thus the meaning of the interchange is included *in-band* in the message itself." END QUOTE I agree, but, the key thing is to insure that this metadata itself is _not_ limited to a human-readable set of English descriptions dependent solely on human understanding. All of the transactions/segments/fields should in addition have _conceptual_ definitions in a knowledge representation language as described above. Any specialized EDI convention for an industry segment (common application) will have a combination of general concepts like "money" and "delivery point" etc., as well as concepts specific to that industry. Often the terms of art in the industry are well-agreed-upon (by consensus or by standards) and the specific conceptual definitions will be mainly uncontroversial. The "generic" or universal ontologies may allow novel intersector transactions (i.e. between different industries). Concepts of automobile distribution may not be known to a currency trading system, and vice-versa, but if the two need to communicate it should be possible for them to exchange sequences of long and painstaking definitions (based on generic ontology) until a valid transaction between them becomes feasible. Among other reasons for having a formal "ontology" is so that other kinds of systems within an enterprise can communicate intelligently with the EDI program. This includes Management Information, CAD data, accounting systems, manufacturing, etc. The same "widget" ordered by the Army could appear first in the EDI RFQ transaction, then in the Purchase Order, then in the CAD design system, then in a Numerical Control program for machining, then in a CIM shop-floor program, then in Inventory, then in Accounting, then in a Shipping router, then in a final EDI confirmation, then in the Army's logistics system, etc. The same entity, the widget, has a different (and incompatible) representation in each program now, so intercommunication is nearly impossible. These programs do have different purposes and need different information, but they can be integrated at the knowledge level, and EDI should fit in to this integration scheme. This is a general example of current "enterprise integration" theory. Similarly, the Medical EDI establishment can tie their work into the extensive conceptual standardization taking place at the National Library of Medicine. If a particular general medical syndrome is authorized for reimbursement, the taxonomies and semantic network in the UMLS Metathesaurus could be exploited to help determine if more specific disease reports in a transaction fall within the reimbursable general category. There are similar concept systems for treatments, procedures, and medication. (I don't know the details of current medical EDI.) Even the area of legal regulations is being studied and formalized at the conceptual level for computers, although this work is still at the early research stage. If and when such systems become practical, logical formulations of the original regulatory language can be used as a formal constraint on EDI transactions. A certain RFQ could trigger: "Sorry, this violates the regulation on minority participation in Regulation CFR XXX:xxx;x(x)iiiv because ..." The fact that EDI transactions have the effect of changing ownership and generating legal obligations means that much of the semantics will ultimately depend on business law. New tokens or "tags" can also be defined "on the fly" conceptually to adjust to specialized business needs, as Nick Szabo has suggested. A tag then will really mean exactly what you say it means. A problem with this is that a user would need to understand the intended use at a deep level and be able to express the conceptual definition correctly -- a skill not likely to be very universal. These things are already happening elsewhere -- links are already forming between different systems at the knowledge level. I would be very interested to see what the "new-EDI" thinkers (and the EDI Establishment) have to say about this kind of advanced programme for EDI. I myself don't think it's really a question of "whether" it will be done for EDI -- just "when". The "edi-new" mailing list seems well suited to be a forum to discuss what in my view will really turn out to be "EKI" where the K is for Knowledge. (The difference from other Knowledge Based Systems is that, in EDI, real ownership and legal obligations actually change.) How long this takes to develop at the "thinkers and innovators" level, and how long after that it takes to spread to the practical world of everyday EDI transactions, are hard things to predict. Yours truly, Fritz Lehmann GRANDAI Software, 4282 Sandburg Way, Irvine, CA 92715, U.S.A. Tel:(714)-733-0566 Fax:(714)-733-0506 fritz@rodin.wustl.edu ============================================================= Article 1588 of bit.listserv.edi-l: Path: cs.utk.edu!martha.utcc.utk.edu!darwin.sura.net!howland.reston.ans.net!europa.eng.gtefsd.com!paladin.american.edu!auvm!!Smith Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l Message-ID: Date: Thu, 28 Jul 1994 11:25:02 CDT Sender: Electronic Data Interchange Issues From: Gregory Smith Subject: Re: EDI and E-Mail Lines: 11 FYI, there is another list devoted to studying the use of Internet e-mail to exchange EDI transactions. To subscribe, send a message to: listserv@byu.edu Include in the message body: sub ietf-edi EDI via e-mail introduces many complications, such as how can the supplier prevent the buyer from repudiating a po (or, for that matter, how can the buyer prevent the supplier from repudiating a quote?). Article 1589 of bit.listserv.edi-l: Path: cs.utk.edu!martha.utcc.utk.edu!darwin.sura.net!howland.reston.ans.net!europa.eng.gtefsd.com!paladin.american.edu!auvm!VNET.IBM.COM!peterr Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l Message-ID: Date: Thu, 28 Jul 1994 13:16:41 EDT Sender: Electronic Data Interchange Issues From: Peter Randlev Subject: Source of ASC X12 Information Comments: cc: TStudds_+a_DISA_+lTStudds+r%DISA@mcimail.com Lines: 6 Ref: Your note of Tue, 26 Jul 1994 07:11:16 +1000 Ken Steel The official source for X12 information is the ASC X12 Secretariat. They are the Data Interchange Standards Association (DISA) at 1800 Diagonal Road - Suite 200 - Alexandria, Virginia 22314-2840. 703 / 548 - 7005 (voice) or 703 / 548 - 5738. The President of DISA is Tony Studds at TStudds_+a_DISA_+lTStudds+r%DISA at mcimail.com. Article 1590 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!europa.eng.gtefsd.com!paladin.american.edu!auvm!NETCOM.COM!hsteck Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 28 Jul 1994 09:02:47 -0700 Sender: Electronic Data Interchange Issues From: Harry Steck Subject: Re: EDI semantics In-Reply-To: <199407261954.MAA09180@netcom11.netcom.com> Lines: 131 You've approached the problem is a great way for your company. However, some of us smaller folk don't have the "EDI Resources" your company seems to have. Where, after the first five or six trading partners you have your "superset" (programming all this stuff with some type of staff, I presume), weee small companies don't have this resource, and I haven't found a "self-programming" EDI software package (some neat tools yes, but not very cost effective for a small company). Weee small folk tend to get "beat into submission" and asked to buy so and so's package to do business with "me". If you have several customers in this mode, you end up with four or five "packaged" EDI solutions running on two or three PCs. I agree Industry guidelines really help. But where do you go for cross-industry needs? Do you think the ECAT is offering a cross-industry solution? Are "industry associations" reviewing and accepting the Federal conventions? I'm optomistic that the ECAT will "motivate" an integration of Implementation conventions, just based on the size of the Fed buying power. But will they "motivate" with industry help, or inspite of industry? My worry is "government" promoted standards versus industry based consensus standards. If industry implementation guidelines are out there, then why doesn't the Fed use some of those, instead of developing there own? Harry Steck Voice: (703) 590-5871 Electronic Commerce Solutions FAX: (703) 551-0024 On Tue, 26 Jul 1994, Gregory Smith wrote: > Others have written: > > >Seems everything is dependent on "pre-arranging" things with an intended > >Trading Partner. And every Trading Partner could add his own twist to > >the standard. Seems to me if like DoD, I had 350,000 trading partners, > >I'd never get to a "standard" way of doing business. The corallary, if I > >were DoD would I want to do business 350,000 different ways? But since > >I'm only a small business, why would I want to do EDI with anybody, since? > >I have to "meet" everybody else's trading partner mandates? If the > >objective of Electronic Commerce is to increase competition, seems EDI > >(in its current state) is doing the opposite. > > and > > >This seems very complex to implement. I could have 10 different partners > >each of which want a variation of the PO standard. How do current software > >packages deal with this, or is it up to the people involved? Is the EDI > >receiving and mapping software general enough to handle these variations? > >What happens when suppliers want fields included that my accounting system > >doesn't support? > > I detect a note of frustration . Our experience isn't with thousands of > partners -- only a hundred or so. But it's been consistent among those > hundred, and we have no reason to believe it's different in the world at > large. When we bring up a new partner, we don't bother to exchange test > transactions. We go straight into parallel (paper and EDI) and usually > turn off the paper in a few days. Very seldom do we have to make changes for > a new partner. > > Although it is _possible_ to develop a limitless number of configurations of > an X12 transaction, in the real world transactions from different companies ar e very similar. On a po, most companies have N1's for one or more of the seller , the buyer, and the ship-to. They may or may not include an address and a > "human" contact, and if they do, you can either process that information or > discard it, depending on your requirements. That's the way N1 is used. > > There's a guy here who claims, "X12 is not a standard. It's a framework." > The key to operating within that framework is to have a flexible > implementation. On the incoming side, we tell our partners that if what they > send us is "legal" in X12, we'll accept it. Period. It doesn't matter if our > other partners send us the same information in a different way -- eg., use a > different segment or qualifier. The first couple of partners are rough, but > we "grow" our ability to process incoming transactions to the point where, > after perhaps five partners, we have covered enough of the variations that > subsequent partners fit right in. > > If a partner tries to send us information that is not consistent with X12, we > gently point out the error of their ways, and encourage them to change, "not > only for our benefit, but for the benefit of all your partners who adhere > to the standard." Sometimes this works . > > On outgoing transactions, we provide whatever information is available to us > and is requested by partners. However, we provide the _same_ information to > _all_ partners. Sometimes a partner may prefer that we not send a particular > segment, but we have the same attitude on outgoing as on incoming: If it's > legal X12, we have every right to send it. So, for example, our outgoing po's > have an N1 segment with an SE qualifier, even if it should be apparent that > the seller is the one who is receiving the transaction. > > As time goes by and more partners are added, we add to the information > contained in the outgoing transaction, until eventually (after just a few > partners) it contains so much that subsequent partners find everything they > want. > > The bottom line is that you can easily build up a "superset" of a transaction > that can process enough data (on incoming) or includes enough data (on > outgoing) that most partners' transactions fit into that superset. The > assumption is that we will discard data that we are sent and do not > want, and that our partners will discard data that we send that they do not > want. Telecom is cheap. Implementing a lot of partner-specific variations is > expensive. > > I admit that this may seem simplistic, but it works, especially for po's, > invoices, acknowledgements, and other "normal" business transactions. > > A big cloud can hang over this happy scenario if your partner wants you to > send data that you do not have. The underlying problem is that before EDI, > business transactions included human input, and information that existed only > in print. Since EDI is computer-to-computer, it is forcing systems to > incorporate that printed information. Sometimes we have had to waive a > "requirement" for data from one of our partners, because the partner insisted > that it could not be provided. But in the end, you will someday have to expan d your system to include that data. > > When writing our software to process EDI transactions into or out of our > databases, we took an approach that maximizes re-usability. For example, we > wrote "segment processors" to parse and process each type of segment. Segment > processors are strung together to create a "transaction processor" for each > new type of transaction. If a new partner sends a REF segment at a > point that we had not previously supported, we insert a call to the > REF segment processor at the new spot. This approach allows us to "grow" our > EDI capabilities with a minimum of programming effort. > > The first thing to do would be to sit down with the transaction maps from your > first few partners, and develop a superset map of your own. > > I do *not* support a Federal or other standard that defines the semantics of > an X12 transaction. X12 was meant to be flexible. The business world is > complex, and restricting the richness of X12 is going to make it unusable for > someone. > > Gregory Smith > Rockwell International, Collins General Aviation Division > gssmith@crems.cr.rockwell.com > Article 1583 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!howland.reston.ans.net!paladin.american.edu!auvm!WORLD.STD.COM!tni Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l Message-ID: <199407271557.AA28320@world.std.com> Date: Wed, 27 Jul 1994 11:57:01 -0400 Sender: Electronic Data Interchange Issues From: david c dreyer Subject: Re: EDI Semantics Lines: 59 Scott Kenszler wrote: >I do just the opposite. I create an 'overlay,' or subset, of the full >spec for each partner, sending only the minimum information needed. to which Greg Smith replied: > An intriguing idea in Scott's message is that possibly the cost of > customization can be brought down to where it is a viable option. > If you implement the "superset" transaction in the program that > extracts data from your database, but had an easy, convenient way > to "configure" or limit that superset when sending the transaction > to a particular partner, you would have the best of both worlds: > able to bring new partners up quickly, but still save on > transmission costs. There is still a cost of customization, as you > configure a new partner, but at least it's not programming cost.... > > Addressing Scott's concerns: Although VANs do charge on a > per-character basis, the charge is very low... two thoughts; - The need for highly efficient, re-usable code in customizing trading partner-specific use of X.12 has been addressed quite nicely by at least one vendor in the PC translator market; their solution combines object- oriented code with MS Windows drag-and-drop to allow complete mapping of all X.12/EDIFACT elements to and from any data format. You can pull up the 850 "Superset" in a window and use all or some of the "objects" for a particular partner overlay, and drag and drop to create map links to your internal data elements, i.e. very fast, little or no programming and easily customized for each partner. Don't mean to be too commercial here, but these tools do exist and address some of the trade-off identified above (not without their own price-tag, naturally ;-). - VAN charges for kilocharacters, Interchanges, Documents, etc. can create compound rates for data, and I'd be cautious about declaring them as "very low." If they were truly very low, I suspect that we'd see higher market penetration of EDI than we do. If as one study suggests there are only 31 VAN's out there, then that's part of the problem - time for some more competition. GS> BTW, in situations where we have very large transactions (eg., 832 GS> Sales Catalogs with tens or hundreds of thousands of segments), we GS> sometimes give the sender the option of bypassing the VAN and instead GS> sending the data on floppy disk, to save the cost of transmission. Out-of-band solutions like this suggest that there's still something wrong with the model, and when is compression going to become standard part of EDI interchange? Binary attachments to EDI can really put salt in the wound. David Dreyer ---------------------------------------------------------------------- THE NETWORKS, INC. PH:717-846-5928 20 W. Market St. 4th Floor FX:717-843-6228 York, PA 17401 FX:717-854-4502(p) X.400:C=USA/A=TELEMAIL/O=NETWORKS/UN=ADMIN tni@world.std.com ---------------------------------------------------------------------- Article 1602 of bit.listserv.edi-l: Path: cs.utk.edu!gatech!howland.reston.ans.net!EU.net!Austria.EU.net!newsfeed.ACO.net!paladin.american.edu!auvm!GENIE.GEIS.COM!h.parks2 Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: bit.listserv.edi-l X-Genie-Id: 4281202 X-Genie-From: H.PARKS2 Message-ID: <199408010611.AA214711485@relay2.geis.com> Date: Mon, 1 Aug 1994 05:06:00 UTC Sender: Electronic Data Interchange Issues From: Howard J Parks Subject: 860 Transaction Set Lines: 19 I have had some experience in dealing with the 860 and 869 transaction sets. I tend to group them in my mind together, because 1) both require querying against open order database, and 2) our application handled both automatically, including sending an 870 when required. For me, the most important issues were not EDI issues, but business issues. For what time period are changes allowed? Is it agreed that I am not penalized for goods shipped before a cancellation? Which parts of the order may be changed? Line Items okay, ship to address or ship on date - wait a minute! As far as EDI issues, since an 860 may be generated in a less automated fashion than an 850, it is very important that part number or ship to formats match those of the order. For instance, I have a TP whos part numbers, whenever you talk to a person, are 6 digits, but are 9 digits when transmitted via EDI (embedded digits, not just fill). If they created an 860 from a data entry screen, they may not send those extra digits. Also, you must make sure that every transaction you receive contains the minimum information you need to make correct identification of the order. This could be more than just the PO number. Article 1796 of comp.databases.pick: Path: cs.utk.edu!emory!swrinde!elroy.jpl.nasa.gov!usc!nic-nac.CSU.net!charnel.ecst.csuchico.edu!yeshua.marcam.com!MathWorks.Com!news2.near.net!news.delphi.com!usenet From: Dave Newsgroups: comp.databases.pick Subject: Re: EDI for Universe/Pick??? Date: Wed, 3 Aug 94 00:11:09 -0500 Organization: Delphi (info@delphi.com email, 800-695-4005 voice) Lines: 5 Message-ID: References: <1994Jul19.204507.5475@news.baldwin.edu> NNTP-Posting-Host: bos1g.delphi.com X-To: I've used three different products for EDI on PI, and other platforms. EDI*Port from Userbase Systems in Knoxville is the most flexible I've dealt with. Call them at 615-691-0823. They have a full range of products and services to get you going. Dave Ballance