Indonesian Information Infrastructure &
The Strategy to Implement Electronics Data Interchange (EDI)

Onno W. Purbo
Computer Network Research Group (CNRG)
Institute of Technology Bandung, Bandung 40132
FAX 62-22 251-2982
E-mail onno@itb.ac.id

Abstract
In this paper, we will report on the development of Internet in Indonesia. Having such infrastructure widely available in Indonesia, it would be advisable to use the existing Internet infrastructure to start doing EDI transactions rather than building a private proprietary VAN to support such network. Proposed strategy to use the existing Internet infrastructure will be explained. Network Security  as well as several technical aspect to interface such systems will be addressed. Several strategic as well as policy issues will be discussed. To make our life a bit easier, I have included in this paper, 

W. Houser, J. Griffin & C. Hage, “Request for Comments: 1865: EDI Meets the Internet - Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet”, January 1996.

I do hope it will help those who don’t have the time to search & download information from Internet would have the opportunity to get the required information to start with. I strongly urge you to learn from Internet - it is THE source of information for what we are going to do.

Indonesian Information Infrastructure

Indonesian Internet development can be traced back through the development of Indonesian educational & research network. The development of Indonesian education & research network has been a major trust behind the development of computer network in Indonesia and can be traced back to early 1980. UUCP Network among Indonesian universities has been a pioneering work of University of Indonesia (http://www.ui.ac.id). Their UUCP system is still in operation - although, currently, they provide the service mostly for commercial & NGOs entities. Internet development in Indonesia is quite rapid (if not exponentially grow) with approximately 20 Mbps of total speed to Internet from Indonesia as of early 1997 as shown in the figure. A list of most Indonesian Internet Service Provider (ISP) can be found in Appendix I (a more complete information can be downloaded from http://www.lp.itb.ac.id/~yc1dav/). To sustain such rapid growth, there is a strong need for human resources in Information Technology & Internet as well as other Engineering aspects to backup the rapid growth.

A rough Indonesian network topology is shown in the figure above with a total speed to Internet in access of 20Mbps. Shown in the figure the major feature of Indonesian Internet Infrastructure as of early 1997, these features are:

•	There are three (3) major Internet Exchange (IX),namely:
•	IndosatNet (http://www.indosat.net.id)
•	Satelindo (http://www.centrin.net.id)
•	TelkomNet (http://www.telkom.net.id).
Although all of these IX’s are not fully configured as an Internet Exchange due to lack of capability in doing fully Border Gateway Protocol (BGP) routing.

•	There are more than 40 registered ISP (listed partly in Appendix I) with access to either one of these exchanges or directly to Internet. Most of the Indonesian ISP are located in Jakarta. Not many ISP has connection in other Indonesian cities, some of the ISPs which has a national coverage are:
•	IndoInternet (http://www.indo.net.id).
•	RadNet (http://www.rad.net.id)
•	MegaNet (http://www.mega.net.id)
•	WasantaraNet (http://www.wasantara.net.id).
•	Institute of Technology Bandung (http://www.itb.ac.id).

•	Only WasantaraNet (http://www.wasantara.net.id) run by PT. POS Indonesia is planning to expand their network to reach 600 Indonesian cities using a low cost VSAT system.

•	Among all Indonesian ISP, only Institute of Technology Bandung (http://www.itb.ac.id) is running a dedicated system to suppot Indonesian education & research communities. ITB is currently hosting the largest Indonesian mailing list (approx. 130 mailing lists - a complete list of the mailing list is in Appendix II). ITB is also connected to about 20 education & research institutions. Major research & development activities in information technology is currently being done at ITB. This activity is part of the Asia Internet Interconnection Initiative (AI3) (http://www.wide.ad.jp).

To give some ideas on Indonesian Internet users, I am included an old report on Indonesian Internet user composition as of June 1995 shown below.

Estimated Indonesian Internet User Composition (June 1995)

The estimated user in June 1995 shows a majority of commercial users. Today, few years later, Indonesian Internet community with estimated of 60.000 Internet users a majority of them are from commercial sector. Thus, Indonesian Internet infrastructure would be feasible for anyone who wish to conduct business / commercial transactions.

It is to say Internet would be one of the feasible means to implement EDI in Indonesia in a short period of time with minimal effort in building the network.

In addition to the existing Internet infrastructure, one should aware that there is initiative by ministry of post & telecommunication to enhance Indonesian public network into 2.4Gbps network through NUSANTARA-21 initiatives (http://www.telkom.co.id/nusa21/) - it would significantly enhance the capacity our Indonesian public network.

Concept of National Information Infrastructure (NII)

It would be better to make a short overview of the brief architecture of a National Information Infrastructure (NII). From the description of an NII, we can then proposed some of strategic as well as tactical planning in implementing EDI in Indonesia.

An NII conceptually can be divided into several layers, namely,

•	Telecommunication Infrastructure which we can guess related to the services provided by telecommunication operators. We as educational institutions should rent these facilities from the existing telecommunication operators. The operators will professionally perform the services.

•	Technical Core / Expertise is related to various core technologies, standard in IT that is being used in NII. Research in this area would be define the needed technology to implement EDI in Indonesia. Technical core / expertise would be of interest for those institutions which involve in the process to collaborate among each other & build a common expertise / standard.

•	Regulatory Framework is the most difficult part of all. There are many regulations / consensus to be changed if we need to perform full fledge EDI implementation in Indonesia. However, to start with mutual collaboration like building test bed, discussion over Internet etc while retaining the current regulatory framework as it is. Funding Agencies, such as, JICA, World Bank & CIDA, would be of interest to get strong involvement in the regulatory framework.

•	Computer Network is something that Internet Technology being heavily used. Collaboration among many Internet experts as well as operators has been done for a long time since the beginning of its operation. The key to it is to enable the students at the education centers to be involve in the operation of the network to produce more people with technical knowledge of Internet technology needed to sustain the rapid expansion of Internet in many countries including Indonesia. Thus, the decisions / involvement in the computer network / Internet activities is entirely up to the particular universities / institutions.

•	IT Application is the application layer of the NII which interact directly with the end users. In our case, we would like to have an Electronic Data Interchange (EDI) implemented in Indonesia. Implementation of EDI could be done easily through the existing Internet application. A brief description on various Internet application that would be related to EDI implementation will be briefly reviewed in the next section. Frequently Asked Questions (FAQ) on how to implement EDI over Internet is reported in RFC 1865 - listed in this paper.

Major Internet Applications
To set the strategic planning in implementing Electronic Data Interchange (EDI) widely in Indonesia, we would need to know slightly on various Internet applications that can be used to facilitate the processes. A brief look at Internet application we can identify at least several major applications, namely,

•	Web  - to store various databases, to create list of indexes of various activities, to disseminate information on various research results / activities. Web would be very useful to let others know on various steps / plans to be used in implementing EDI in Indonesia.
•	Mailing list - would be needed to have two way interactions among all parties involved, such as, trading partners, shipping companies, government bodies, financial institutions. In addition, mailing list can be used as the actual EDI means such as to disseminate tender message. The partial list of Indonesian mailing lists in Internet can be seen in Appendix II. ITB welcome those who would like to have their mailing list set up using our server.
•	E-mail - would be one of the most feasible means to do EDI in Indonesia. Some of the financial institutions are currently using UUCP (E-mail services only) without any Internet capability. Thus, by allowing most of Indonesian users to use E-mail in EDI - it would open the majority of Indonesian company to interact in EDI. Several issues such as security, authentication should be carefully addressed.
•	FTP Server - to store archive of various reports, information & large files. FTP services can be used for EDI applications. However, E-mail would be a preferred way to do the transaction rather than FTP.

Strategic Planning for EDI Implementation in Indonesia.

In this section, we would like to proposed on how we should focus our strategy in implementation of EDI in Indonesia. I would strongly urge you to read carefully the RFC 1865 regarding the technicalities to enable us in understanding the strategic path to be used in the proposed implementation.

The strategies  could be divided into three (3) major strategies derived from the NII Architecture. In this paper, we will not attempt to describe the detailed tactical planning of implementation of the EDI implementation in Indonesia. A brief overview on the tactical planning will be reviewed in the next section. The strategies can be categorized as follows:

1.	Strategies in EDI implementation in Indonesia (application layer).
2.	Strategies in legal Framework to support EDI.
3.	Strategies in the telecommunication infrastructure, core IT & Internet technology.

We should be noted that among all proposed strategies, the fact that:
•	Internet is only a tool.
•	Qualified Human Resource behind it is the key to enable all of this.

Strategies in EDI Implementation in Indonesia (application layer).
EDI implementation would requires several major processes:

•	User / partner’s education should be the top priority.
•	All parties should know the EDI Technology, Implementation Convention.
•	All parties should agree on the databases to be used in authentication & security.
•	All parties should agree on how they will create the Network Entry Point (NEP).
•	Above all, all parties should agree on collaboration in doing it.

A process of collaboration among all parties / trading partners can be divided into several stages, namely,

1.	In the first stage, one has to have some knowledge on the resources & expertise of the other parties, to know the procedures to get these resources / expertise, etc. - Web application would be the perfect fit to this. Our experience in Indonesia, many of institutions in Indonesia are still using printed media to distribute such information (and most of the time difficult to ask for it) and, thus, creates some difficulties to setup the Web. This occurs mainly due to the person in charge of the Internet is normally different than the one in charge of public relations.
2.	In the second stage, leading parties / institutions should be actively involved in doing “link & match” activities among each parties. Physical contact through seminars, workshops, conferences should be followed up by virtual contact through E-mail discussions through various mailing lists. It would be easy to install mailing lists. One needs only several servers to host the list & some bandwidth to Internet. It will require sometime (might be 1-2 years) to get the results of such activities. Thus, user education would be a strong issue to be able to implement such activities.
3.	Having known each other for sometime & know exactly the strength & weakness of each parties, mutual collaboration could be initiated by keeping a win-win situation among parties. Mutual collaboration could be instantly done in many cases - sometime, regulation would be the barrier of it.

Strategies in legal Framework to EDI.
We will face a major issue of:

authentication & security in paperless transactions

Would the current legal framework fit nicely into the new dimension in doing paperless transactions in electronics world? We need to evaluate more thoroughly on how can we fit / change the current regulation to enable all of this activities to nicely work.

Being not a legal & custom expert, I regret not being able to elaborate more on this aspect. I am sure those who are involved in custom would be of interest to see how we can change the custom documents into fully electronics form.

Strategies in the telecommunication infrastructure, core IT & Internet technology.
We should divide the strategies into two major strategies:

•	Telecommunication infrastructure - running our own Value Added Network (VAN) would give the benefit of security. However, it would requires unnecessary human resources & cost involved in maintaining such network which would practically kill the network if it is not mature yet. An easier way to implement EDI by adopting Internet as a mean to perform EDI transactions - however, we need to add more network security protection to it - which fortunately can be found easily in the market place.

If VAN in Indonesia is already established (which is the case), a gateway to Internet should be performed to enable those with Internet access could use the Internet to do EDI transactions.

•	Core IT & Internet Technology - it would be beneficial to develop a core IT & Internet Technology related to EDI / Electronic Commerce. Steps to be taken should follow the following steps:
•	Collaboration with leading education & research institutions (national & international institutions).
•	Build a test -bed to see the feasibility of the system as well as the strategies in implement this in reality.
•	Involving committed agencies / institutions in doing the test-bed. I am sure many commercial vendors would like to participate in the test-bed.
•	Results / consensus made during the development stage should be published in the Internet.

Basic Strategy
Among all strategies mentioned, the basic strategies should be taken are simply:

•	Use the existing infrastructure whenever possible (Internet would be one of the best candidate).
•	Employed Qualified Human Resource would be the key to success. We should aware that this is the most difficult task in Indonesia - unfortunately, not many people are willing to invest in human resource development.

Brief Information / Technical Aspects of EDI
Before we open the discussion on tactical planning in implementing EDI in Indonesia, it might be beneficial to discuss briefly some technicalities on EDI. We basically merged EDI into two main standards, i.e.:

•	ASC X12 - In 1979, ANSI chartered the Accredited Standards Committee (ASC) X12 to develop uniform standards for inter-industry electronic interchange of business transactions-- electronic data interchange (EDI). Its main objective is to develop standards to facilitate electronic interchange relating to such business transactions as order placement and processing, shipping and receiving information, invoicing, and payment and cash application data.

•	UN/EDIFACT - United Nations Electronic Data Interchange for Administration, Commerce and Transport is maintained at DISA. It has 172 messages at various stages of development - out of which 42 Messages at Status Recommended UN/EDIFACT messages.

To a computer, an EDI message is basically an ASCII text. Shown below is an example of ANSI X.12 850 Message for Purchase Order Transaction:

ANSI X12 850 Purchase Order Transaction

ST*850*00001
BEG*00*SA*EDI-9966***850816
TAX*5-6777867
N1*ST*THE CORNER STORE*09*0799332120001
N3*601 FIRST STREET
N4*CROSSROADS*NY*10016
N3*900 EASY STREET
PER*PD*JOHN JONES**TE*415-744-8666
ITD*01*03*2.000***10**30
FOB*CC*****OR
DTM*002*851018
PO1*1*16000.00*LB*1.25000*QT*PN*100020167557
CTT*2*36000.00
SE*22*00001

Having an ASCII text message, it would be easy to pass the messages using the existing E-mail or other file transfer means through the computer network. Security & authentication would be a big issue if Internet is used.

An EDI standard will cover many type of transaction, e.g., banking / fund transfer / credit / debit transaction, custom, legal action, airline / ticketing, shipping / cargo, tender / contract, purchase order, invoice, job order, medical service, tax, reinsurance etc. Not all messages would be of interest, for example a Custom brokerage might be interested in the following messages from UN/EDIFACT standard, e.g:

	CUSCAR		Customs Cargo Report Message
	CUSDEC		Customs Declaration Message
	CUSREP		Customs Conveyance Report Message
	CUSRES		Customs Response Message

What kind of costs will a contractor typically incur if they are not already EDI capable? A contractor will need to:

1.	Purchase EDI software (prices start at $99). 
2.	Contract with a VAN service provider. Fees will vary based on services selected and traffic. As an alternative, the Internet can be used as the transport mechanism which eliminates this cost. 
3.	Do the data analysis needed to map information from their application systems into the EDI standard format, a one-time effort. 
4.	Do the programming required to create a file that can interface with EDI translation software, a one-time effort. 

Other less tangible costs may be involved such as updating policies and procedures to move from a paper-based system to an electronic-based system. Most of the costs are a one-time expenditure. A contractor can use the EDI translation software throughout their company for a number of other functions and many contractors have a corporate EDI group or resources they can use. The benefit to a contractor is that they can use the same format and transmission method for all their government contracts instead of satisfying one requirement for one contract. 

Note that some commercial off the shelf program management software applications include the capability to import and export ANSI X12 or UN/EDIFACT data. If so, the mapping process to interface with EDI translation software has already been done. 

Tactical Planning in Implementing EDI in Indonesia
As I understand, there is an effort has been going on at Indonesian custom to implement EDI using a VAN to do it. At least, all of us should agree on:

•	Standard to be used - adoption of ASC X.12 and / or UN/EDIFACT would be beneficial to make things easier.
•	Implementation Convention (IC)s.

To increase the EDI user coverage in Indonesia, we should implement several activities, such as:

•	Disseminate information on the standard & IC to be used in Indonesia. We need to have a steering committee to define the standard & IC to be used in Indonesia.
•	Disseminate information on the VAN / ways to integrate to EDI Indonesia. Web / FTP server would be a perfect means to do it.
•	Educate the Indonesian Internet user on how to interact in EDI enviroment. Education can be done through rapid discussion via E-mail / mailing list as well as through Web / FTP based information dissemination. ITB is hosting many Indonesian mailing lists in Internet & willing to host more mailing list for the benefit of Indonesian cyber community.
•	Do / activate a test-bed to implement EDI which will gain a wide acceptance in the Indonesian users, namely, using the existing Internet environment. Leading research & education institution should be invited to join this activity as they are the one who normally lead the research / implementation activities.
•	Adoption of the test-bed into a fully operational network, both via VAN and Internet.

How can we use Internet as a means to do EDI transaction? A simple drawing will show how can we create a virtual Value Added Network (VAN) over the existing public Internet network in Indonesia to be used for EDI transactions.

Trading partners both the one within the VAN as well as in the Internet can interact with each other. Agreement in various technical as well as regulatory aspect should be made prior to the operation of such system. Thus, a test-bed should be implemented.

I strongly encourage the reader to read various articles / information on InterNet, IntraNet, ExtraNet, Firewall, PGP, PEM etc. from the Internet. To start with RFC 1865 will help us to get the lead. The above diagram is a very simple diagram to show how we can interconnect varous network, it may be implemented by:

•	Interfacing between the existing VAN & Internet infrastructure.
•	Firewall - to protect corporate IntraNet from Internet attackers.
•	Virtual WAN by tunnelling through Internet to various corporate IntraNet to pass  encrypted  application layer data over Internet. This concept known as ExtraNet.
•	Pretty Good Privacy (PGP) with 1024 key or PEM can be used to add an extra protection to authenticate or to encrypt the message which will be conveyed through Internet. Internet / ExtraNet public key server should be implemented to exchange the keys - ITB currently tests the implementation of PGP over our network as well as implementation of public key server.

The EDI trading partners will not feel any changes in their applications. All extra network security measure & setup will operate in underlying layers.

It seems easy to say, in reality, a lot of it needs to be developed and tested. A lot of effort should be focused on the human resource development. A join research & development activities would be needed to adopt such technology & disseminate it for the benefit of Indonesian EDI user group.

Summary
In this paper, we have presented:

•	Report on the existing Indonesian Internet Infrastructure which grows exponentially as well as the upcoming Indonesia information super highway.
•	Internet would be a feasible mean to open the EDI user based in Indonesia. However, several technical issues, such as, network security & authentication, should be solved.
•	Several strategic planning should be implemented to meet the demand to run EDI in Indonesia - these plan should cover the EDI application layer, legal framework, telecommunication infrastructure & IT / Internet core technology. Human resource development would be one of the key issue to enable EDI in Indonesia.
•	One should aware that all of the computer power & equipment is only a tool to help us. The key to success is in employing qualified human resources in implementing the system - close collaboration in doing test-bed & standard / IC development with leading education & research institutions would be needed.
•	An EDI test-bed could be immediatly implemented betwen custom institutins and the existing Indonesian universities over the existing Internet infrastructre.

Acknowledgment
First of all, I would like to thank my colleagues from PUSDATIN & Indonesian custom to allow this research to be done & presented. I would like tothank many of my colleagues & students who help the author in preparing the materials, to name a few, I would like to thank Ir. Aulia K. Arif, Joko Yuliantoro, Luthfi as well as other Computer Network Research Group (CNRG) member (cnrg@itb.ac.id). All of these activities can be done without the support from WIDE Project in Japan, Asia Internet Interconnection Initiatives, head of Institute of Technology Bandung.

Onno W. Purbo, best student graduated from the electrical engineering department at Institute of Technology Bandung (ITB) in 1987. Received his M.Eng in semiconductor laser and fiber optics from McMaster University, Canada in 1989. His Ph.D in Silicon Devices and Integrated Circuits was granted from University of Waterloo, Canada in 1993. He has published a total of 9 papers in international journals and more than 19 papers in international conferences. A total of more than 90 publications. In 1992, listed in a book "American men and women of science". In 1996, winning the "Adhicipta Rekayasa" Award from the Association of Indonesian Engineer. Currently active as:

•	Member at Electrical Engineering Department ITB.
•	Active at Inter University Center on Microelectronics ITB, at Computer Network Research Group as well as at Microelectronics Processing & Devices Research Group.
•	Serving as network coordinator in several netwoking activities.
•	Member of several task forces within Institute of Technology Bandung (ITB).
•	Consultant for the development of information system in several ministries as well as in several industries / commercial institutions.
•	Member of several national steering commitee / task force, such as, NUSANTARA-21 & Academic Information Infrastructure.
•	Member of expert groups at regional level:
•	South East Asia Ministry of Education Organization (SEAMEO): for the development information network for higher education in SEA countries.
•	United Nation (UN) Economic and Social Commission for Asia and The Pacific (ESCAP): Reviewing Computerization Development in the Public Sector.
•	Asia Internet Interconnection Initiative (AI3) ITB Team.

His research interest mainly in developing packet radio technology especially for TCP/IP computer network. He also actives research in Integrtated Circuit technology and microelectronics.

Appendix I
Profile of Most Indonesian Internet Service Provider (ISP)
(a more complete information at http://www.lp.itb.ac.id/~yc1dav/internet/index.htm)

Appendix II
List of Major Indonesian Mailing Lists.

E-mail Mailing List	Comments	
ybnet-l@itb.ac.id	Amateur Radio	
webauthor@itb.ac.id	Discussion on Site Preparation & Various Techniques	
wayang@itb.ac.id	Discussion on Wayang (Puppet Show)	
unpad@itb.ac.id	Alumni Universitas Padjajaran (UNPAD)	
unibraw@itb.ac.id	Alumni Universitas Brawidjaja (UNIBRAW)	
unair@itb.ac.id	Alumni Universitas Airlangga (UNAIR)	
tk-l@itb.ac.id	Alumni Chemical Engineering ITB	
tenis-meja@itb.ac.id	Table Tennis Discussion	
tcp-group@itb.ac.id                                                              	Relay tcp-group@UCSD.EDU	
taruna-bakti@itb.ac.id	Alumni SD/SMP/SMA Taruna Bakti, Bandung	
sysop-l@itb.ac.id	Network Operator AI3/ITB	
suroboyoan@itb.ac.id	Arek Suroboyo	
surabayapost@itb.ac.id	Surabaya Post Magazine	
strada@itb.ac.id	STM Strada Mailing List	
stock-market@itb.ac.id	Stock Market in Indonesia	
smpn5bdg@itb.ac.id	Alumni SMP 5 Bandung	
smp1sby@itb.ac.id	Alumni SMP 1 Surabaya	
sman82@itb.ac.id	Alumni SMA 82 Jakarta	
sman5bdg@itb.ac.id	Alumni SMA 5 Bandung	
sman3ygy@itb.ac.id	Alumni SMA 3 Yogyakarta	
sman3bdg@itb.ac.id	Alumni SMA 3 Bandung	
sman28jkt@itb.ac.id	Alumni SMA 28 Jakarta	
sman21jkt@itb.ac.id	Alumni SMA 21 Jakarta	
smada@itb.ac.id	Alumni SMA 2 Surabaya	
sea-games@itb.ac.id	SEA Games	
sdm@itb.ac.id	Human Resource Development	
satelit-l@itb.ac.id	Satelite Technology	
research-announcement@itb.ac.id	Research Annoucement at ITB	
raja-net@itb.ac.id		
radar-l@itb.ac.id	Students at Microwave Lab. ITB	
persib-l@itb.ac.id	Supporter of PERSIB	
persebaya-l@itb.ac.id	Supporter of PERSEBAYA	
psm@itb.ac.id	Paduan Suara Mahasiswa	
pau-mikro@itb.ac.id	Relay pau-mikro@ee.umanitoba.ca	
pat-itb@itb.ac.id	Pendidikan Ahli Teknik Komputer - ITB	
otomotif@itb.ac.id	Discussion on Automotive Technology	
negerikita@itb.ac.id	Discussion on Negeri Kita	
nt-iis@itb.ac.id	NT - Internet Information Server	
n21-iwg@itb.ac.id	N21 - Internet Working Group	
n21-sc@itb.ac.id	National Steering Committee - NUSANTARA-21	
n21@itb.ac.id	Public Discussion on - NUSANTARA-21	
midi@itb.ac.id	MIDI Music	
mesin-its@itb.ac.id	ITS Mechanical Engineering	
merdeka-users@itb.ac.id	User of merdeka.itb.ac.id (free UNIX).	
m88-l@itb.ac.id	Alumni Mesin ‘88 ITB.	
m75@itb.ac.id	Alumni Mesin ‘75 ITB	
loedroek-l@itb.ac.id	Loedroek ITB.	
kongres@itb.ac.id		
kimia@itb.ac.id	Chemistry	
kaji-islam@itb.ac.id	Kajian ISLAM	
jobs@itb.ac.id	Job Announcement / Opening	
its_ml@itb.ac.id	Alumni ITS	
itb75@itb.ac.id	Alumni ITB Angkatan 75	
itb@itb.ac.id	ITB big family.	
isdn-forum@itb.ac.id	ISDN Technology	
indonesia-press@itb.ac.id	Indonesia Press / Journalists	
indonesia-japan@itb.ac.id	Indonesia-Japan Collaboration	
indonesia-ix@itb.ac.id	Indonesia Internet Exchange (IX)	
indonesia-canada@itb.ac.id	Indonesia-Canada Collaboraton	
if-l@itb.ac.id	Informatics ITB	
iap@itb.ac.id	Ikatan Ahli Perencana Wilayah	
iagi-net@itb.ac.id	Ikatan Ahli Geologi Indonesia	
hukum@itb.ac.id	Discussion on various aspect of law & legal framework	
hee-net@itb.ac.id	Higher Engineering Education - Network	
ham-digital@itb.ac.id	Relay Ham-Digital@UCSD.EDU	
graphic-design@itb.ac.id	Graphics Design	
gps-comm@itb.ac.id	Indonesian GPS Community	
gd-l@itb.ac.id	Geodesi ITB	
fuel-cell@itb.ac.id	Discussion of Fuel Cell	
ft-l@itb.ac.id	Engineering Physics ITB	
freebsd-questions@itb.ac.id	FreeBSD	
freebsd-hardware@itb.ac.id	FreeBSD	
freebsd-hackers@itb.ac.id	FreeBSD	
freebsd-emulation@itb.ac.id	FreeBSD	
fkm-unair@itb.ac.id	Fakultas Kesehatan Masyarakat UNAIR	
fk-net@itb.ac.id	Fakultas Kedokteran (?)	
fi88-l@itb.ac.id	Alumni Physics ‘88 ITB	
fi90-l@itb.ac.id	Alumni Physics ‘90 ITB	
fi-l@itb.ac.id	Physics ITB	
english-courses@itb.ac.id	English Course Distance Learning	
elits_ml@itb.ac.id	Electrical Engineering ITS	
elektro-usakti@itb.ac.id	Electrical Engineering Univ. Trisakti, Jakarta	
el688@itb.ac.id	Course S2 ITB EL688: Data Communication	
el670@itb.ac.id	Course S2 ITB EL670: Computer Network	
el312@itb.ac.id	Course S1 ITB EL312: Semiconductor Device	
ekonomi-indonesia@itb.ac.id	Indonesian Economics	
eftui@itb.ac.id	Electrical Engineering Universitas Indonesia (UI)	
ecoscience-indonesia@itb.ac.id	Ecoscience	
dokter@itb.ac.id	Physician Mailing List	
atm-forum@itb.ac.id	ATM Technology	
arema-l@itb.ac.id	Arek Malang	
ar-l@itb.ac.id	Architecture ITB	
ar-91@itb.ac.id	Alumni Architecture ‘91 ITB	
ai3@itb.ac.id                                         	Relay ai3@wide.ad.jp	
ai3-partners@itb.ac.id	Relay ai3-partners@wide.ad.jp	
ai3-staff@itb.ac.id	Staff AI3 di ITB	
aceh-net@itb.ac.id	Aceh	
81-l@itb.ac.id	Electrical Engineering ITB ‘81	
86-l@itb.ac.id	Electrical Engineering ITB ‘86	
88-l@itb.ac.id	Electrical Engineering ITB ‘88	
89-l@itb.ac.id	Electrical Engineering ITB ‘89	
90-l@itb.ac.id	Electrical Engineering ITB ‘90	
91-l@itb.ac.id	Electrical Engineering ITB ‘91	
92-l@itb.ac.id	Electrical Engineering ITB ‘92	
94-l@itb.ac.id	Electrical Engineering ITB ‘94	
acehnet@yuma.acns.colostate.edu	Aceh	
adnet@uad.ac.id	Dosen Universitas Ahmad Dahlan, Yogyakarta	
aitisa@rccsun.ait.ac.th	Mahasiswa Indonesia di Thailand	
atinanet@fbgeo1.tuwien.ac.at	Mahasiswa Indonesia di Austria	
bhk@maillist.cs.orst.edu	Alumni Bunda Hati Kudus, Jakarta.	
bisa+network@uclink2.berkeley.edu	BISA=Berkeley Indonesian Student Association	
bkkbn@listserv.syr.edu	Keluarga Berencana	
bumi-net@geoinfo.tuwien.ac.at	Kebumian & Geodesi.	
caltex@caltex.stanford.edu	Keluarga Besar PT. Caltex Pacific Indonesia (CPI)	
ccnet@m-net.arbornet.org	Keluarga Besar SMA Kanisius, Jakarta	
ekuin@cs.wisc.edu	Ekonomi, bisnis & sekitarnya.	
eiudp-net@sfu.ca	Staf EIUDP (Eastern IndonesiaUniversity Development Project) in Vancouver and Jakarta	
fica-net@cs.wisc.edu	Fellowship of Indonesian Christians in America (FICA)	
fish-net@sfu.ca	Fishery.	
forestry-ind@mbe.ece.wisc.edu	Forestry.	
forum@bison.mb.ca	Forum Komunikasi Mahasiswa Indonesia di Kanada.	
gama-net@budi.ee.umanitoba.ca	Keluarga Besar Universitas Gajah Mada, Jogyakarta.	
gema@grfn.org	Gereja Mahasiswa Bandung	
iccn@dbs.informatik.uni-muenchen.de.	Indonesian Christian Computer Network	
id-jp@dok07.dokkyomed.ac.jp	Indonesia Japan	
ids@listserv.syr.edu	Jaringan Kajian Pembangunan Indonesia	
ie-its@indo.net.id	Teknik Industri (Industrial Engineering) - ITS	
ilunift@makara.cso.ui.ac.id	Alumni Fakultas Teknik, Universitas Indonesia.	
INDONESIA@vm.gmd.de	Mahasiswa Indonesia di Eropa	
indonesia-forum@cool.mb.ca	Forum Indonesia-Amerika	
indo@ask.uni-karlsruhe.de	Mailing List Indonesia	
apakabar@clark.net	Berita & Pandangan “Lain” Tentang Indonesia
(moderator John “apakabar” MacDougall)	
indonesia-bc@sfu.ca	Mahasiswa Indonesia di British Columbia, Canada	
indo@rantau.stanford.edu	Forum for ICS (Indonesian Club at Stanford)	
Isanet@gwuvm.gwu.edu	Indonesia di George Washington University in Washington DC	
indoz-net@cc.utas.edu.au	Indonesian in Australia	
ipb-net@macc.wisc.edu	Alumni IPB	
isa@maillist.cs.orst.edu	Indonesian Students in Oregon State University, Corvallis, Oregon, US.	
isg@bison.mb.ca	Indonesian Student's Group (in Winnipeg, Canada)	
is-lam@isnet.org	Diskusi Tentang Islam.	
dialog@isnet.org	Diskusi Tentang Muslim - NonMuslim	
hikmah@isnet.org	Pertanyaan & Jawaban Ttg. Kristen Oleh ISNET	
indonesians@janus.berkeley.edu	The first Indonesian mailing list	
kekl@iastate.edu	Alumni Keluarga Eks forum for SMA Ketapang alumni Kolese Loyola, Semarang.	
kmki@ask.uni-karlsruhe.de	Keluarga Mahasiswa Katolik Indonesia	
Maluku-net@sfu.ca	Maluku	
tumoutou@unb.ca	Sulawesi Utara	
marsud-net@efn.org	Alumni SMA Fons Vitae I (Marsudirini) mailing list	
netzaga@peak.org	Alumni SMA Kolese Gonzaga Jakarta	
paroki@paroki.org	Catholicism or issues in the Catholic religion	
paroki_asia@wave.ec.t.kanazawa-u.ac.jp	Indonesian Catholic Community in Asia Pasific regions.
	
pau-mikro@ee.umanitoba.ca	Anything on IT & Microelectronics.	
bedug@isnet.org	Pengajian Staid III net	
PermiasFC@ColoState.Edu	Indonesian Students in Colorado State University, CO.	
petra-net@iastate.edu	SMAK Petra II Surabaya Alumnae Mailing List.	
indonesia@wharton.upenn.edu 	Indonesians who reside in the city of Philadelphia, its surroundings.	
pl@mit.edu	Alumni of SMA Pangudi Luhur, Jakarta.	
ppi@agouti.hds.univ-compiegne.fr	PPI France Net	
ml-ppihiro@ue.ipc.hiroshima-u.ac.jp	Indonesian Students in Hiroshima	
ppi-jt@papilio.tutics.tut.ac.jp	Indonesians studying in Central Japan and the alumni	
ppikyoto@kais.kyoto-u.ac.jp	PPI Kyoto	
ppinet@athena3.cent.saitama-u.ac.jp	PPI-Net	
prob-net@doit.wisc.edu	math, physics, ece, etc, problems	
rantau@virtual.ogrd.wsu.edu	Minangkabaus (West Sumatran) in foreign soil.	
recis@tamu.edu	Regina Pacis Alumni mailing list	
ricci@mcfeeley.cc.utexas.edu	Alumni SMA Katolik Ricci, Jakarta	
diskusi-sara@mbe.ece.wisc.edu	Discussion on SARA (Suku, Agama, Ras, dan Antar golongan) in Indonesia	
sn-pusat@indo.net.id	Lembaga Seni Pernafasan SATRIA NUSANTARA PUSAT	
scitech@wave.ec.t.kanazawa-u.ac.jp	Indonesian Science and Technology (IPTEK).	
semi-cond@mbe.ece.wisc.edu	all about semi-conductor	
smarp@umich.edu	Regina Pacis Bogor Alumni mailing list	
smak-1@doit.wisc.edu	Alumni SMAK-1 (Yayasan BPK Penabur KPS) Jakarta.	
smak-3@mbe.ece.wisc.edu	Alumni SMAK-3 (Yayasan BPK Penabur KPS) Jakarta.	
smandel-ml@golgi.eijkman.go.id	Guru, staf, pelajar dan alumni SMA Negeri 8 Jakarta	
sn-sby@indo.net.id	Tenaga Dalam Satria Nusantara	
tmitb@nusantara.net	Petroleum and Geoscience within the alumny and faculties of Petroleum Engineering, ITB	
TOPNet@mcfeeley.cc.utexas.edu	Affiliates of St. Aloysius - Bandung	
trisakti-net@doit.wisc.edu	Alumni/staff of Usakti Jakarta	
ui-net@macc.wisc.edu	Alumni + staff of Universitas Indonesia, Jakarta	
uksw-club@mcfeeley.cc.utexas.edu	alumni dan staff  Universitas Kristen Satya Wacana	
ml-unhas_net@ue.ipc.hiroshima-u.ac.jp	Alumni and Staff of Hasannudin University	
unpar@wave.ec.t.kanazawa-u.ac.jp	alumni of Universitas Katolik Parahyangan (UNPAR)	
weather@cumulus.upthb.bppt.go.id	Discussion in the field of Atmospheric Science	

Appendix III
Major EDI & Electronic Commerce Resources on the Internet

American National Standards Institute
(http://www.ansi.org/home.html)
This service will let you find information on ANSI's mission and role , the latest news about the ANSI federation, a catalog of published American National Standards, and much more!

International Organization for Standardization
(http://www.iso.ch/)
The International Organization for Standardization (ISO) is a worldwide federation of national standards bodies from some 100 countries, one from each country. ISO is a non-governmental organization established in 1947. The mission of ISO is to promote the development of standardization and related activities in the world with a view to facilitating the international exchange of goods and services, and to developing cooperation in the spheres of intellectual, scientific, technological and economic activity.

Electronic Messaging Association (EMA)
(http://www.ema.org:80/ema/ema-home.htm)
The Electronic Messaging Association (EMA) champions the development and use of secure global electronic commerce. As a membership forum, EMA enables businesses that use or are exploring messaging technologies to work in a unique partnership with providers of those technologies. User members of EMA, involved in any and all aspects of electronic commerce, come from all industries. Vendor members offer a wide range of telecommunications and computing services, including electronic mail, networks, directories, computer facsimile, electronic data interchange, paging, groupware, and voice mail. 

The Institute for Information Management
http://www-iwi.unisg.ch/index.html
The Institute for Information Management (Institut für Wirtschaftsinformatik, IWI) at the University of St. Gallen focuses on information management in business and administration. Three departments exist at the moment: Groupware applications, work-flow and document management (Prof. Dr. Andrea Back-Hock), information management, process engineering and computer aided software engineering (Prof. Dr. Hubert Österle) and information markets and communication (Prof. Dr. Beat Schmid).

•	Electronic Commerce
(http://www-iwi.unisg.ch/links/elcomm/index.html)
•	EDI-Workshop
(http://www-isi.unisg.ch/iwi4/ch/em/papers/edifact/html)
•	Business Engineering
(http://www-iwi.unisg.ch/iwi2/be/reaction.html)
•	The non-market preconditions of Electronic Markets
(http://www-iwi.unisg.ch/events/rpabs5.html)
•	Competence Center for Electronic Markets
(http://www-iwi.unisg.ch/iwi4/cc/em/index.html)
•	Competence Center TeleCounter
(http://www-iwi.unisg.ch/iwi4/cc/tc/index.html)

Electronic Commerce Association 
(http://www.globalx.net/eca/)
The Electronic Commerce Association (ECA) is a non-profit organization established to advance electronic commerce and business use of technology in Canada. The association has over 400 members from the public and private sectors. The ECA holds regular seminars on topics such as Electronic Document Management, Commerce on Internet, and EDI. Discussions focus on available technologies and the impact that they have on the way we conduct business. 

Ross Priory Research Symposium
(http://www-iwi.unisg.ch/events/rosspr.html)
The Department of Management Science, Strathclyde Business School and the Institute for Information Management, University of St. Gallen have organized a symposium at Ross Priory, Scotland to bring together researchers from various European countries to discuss current issues in the development of Electronic Markets. 

The Center for Electronic Commerce (http://www.iti.org/cec/)
Electronic Commerce World Institute (http://www.ecworld.org/)

The Health Industry Business Communications Council
(http://www.hibcc.org)
HIBCC is an industry-sponsored and supported nonprofit organization. Our primary function is to facilitate electronic communications by developing appropriate standards for information exchange among all health care trading partners. Our broad mission has involved HIBCC in a number of critical areas, including electronic data interchange message formats, bar code labeling data standards, universal numbering systems, and the provision of databases which assure common identifiers.

Department of Defense Info Center
(http://www.gap.net/ecic2.html)
	EC/EDI (DoD) Paper
	(ftp://asc.dtic.dla.mil/pub/edi/html/execsum.html)

Workgroup for Electronic Data Interchange - Health Care System (gopher://cscns.com/11/News and Information/Medicine/wedi)
In November 1991, the Workgroup for Electronic Data Interchange (WEDI) was established in response to the challenge to reduce administrative costs in the nation's health care system. A voluntary, public-private task force, WEDI developed an action plan to streamline health care administration by standardizing electronic communications across the industry. 

FedWorld
(http://www.fedworld.gov/)
The National Technical Information Service (NTIS) introduced FedWorld in November 1992 to help with the challenge of accessing U.S. Government Information on-line. In an electronic age when more and more government agencies are racing to get on-line, FedWorld can help you keep up with the flood of information worldwide. We are providing a comprehensive central access point for locating and acquiring government information. 

Federal Electronic Commerce Acquisition Team
(http://www.gsa.gov/ecapmo/)
The Federal Electronic Commerce Acquisition Program Management Office, (ECAPMO) formally the Federal Electronic Commerce Acquisition Team or ECAT has made various draft reports and documents available via Internet for your review and comments. Currently there are four directories: 3050 Draft.IC, (3050 Draft Implementation Conventions) Fed.IC, (Federal Implementation Conventions) March.Architecture.Final, (Streamlining Procurement Through Electronic Commerce) and ConOps (Concepts of Operations) 

National Institute for Standards and Technology
(http://www.nist.gov/)
Electronic Commerce
(http://waltz.ncsl.nist.gov/HPCC/commerce.html)

The IITF Web Server
(http://iitf.doc.gov/)
IITF CAT - Summary for Putting the Info Infra to Work  (http://iitfcat.nist.gov:94/doc/summary.html)

National Product Data Exchange Resource Center
(http://elib.cme.nist.gov/nipde/Intro.html)
The National Product Data Exchange Resource Center is managed by the U.S. Product Data Association (US PRO). The Resource Center is located at the National Institute of Standards and Technology (NIST). All data herein is maintained by US PRO and does not represent the views of NIST in any manner. 

Federal EDI Implementation Guides
(http://snad.ncsl.nist.gov/dartg/edi/fededi.html)

CommerceNet
(http://logic.stanford.edu:80/cit/commercenet.html)
CommerceNet is an open, Internet-based infrastructure for electronic commerce, created and operated by a consortium of major Silicon Valley users, providers and developers under the auspices of Smart Valley, Inc. CommerceNet seeks to revolutionize the Valley's core electronics, software, and information service industries by making interaction between customers, suppliers, and development partners as efficient as interactions among internal departments. 

Thomas Ho's favorite Electronic Commerce WWW Resources
(http://www.engr.iupui.edu:80/~ho/interests/commmenu.html)

Roger Clarke's Electronic Commerce
(http://www.anu.edu.au/people/Roger.Clarke/EC/index.html)

Klaus' Corner
(http://www.premenos.com/klaus/)

EDI Help Desk
(http://www.wwa.com/unidex/edi/)

Buyer's Guide to Electronic Commerce
(http://www.wentworth.com/e-com.com/buyersguide/)

Electronic Commerce Resource Guide
(http://www.ecrc.gmu.edu/)

IETF EDI Working Group FAQ
(http://www.va.gov/publ/standard/edifaq/index.htm)

EDI Resources at Washington Publishing Company
(http://www.wpc-edi.com)

Center for Electronic Commerce
Industrial Technology Institute
1-800-292-4ITI, ext. 4153
(http://www.iti.org/cec/)

Data Interchange Standards Association
(the secretariat for ASC X12 and the PAEB)
Tel: 1-703-548-7005
(http://www.disa.org/)

Electronic Commerce Resource Center
Tel: 1-210-732-1141
(http://www.saecrc.org/)

Premenos
(which includes X12 and EDIFACT standards online!)
(http://www.premenos.com/)

Appendix IV
EDI Glossary

AIAG:Automotive Industry Action Group 

ANSI:American National Standards Institute A private, non-profit membership organization that coordinates the development and approval of voluntary consensus standards in the United States 

ANSI ASC X12: ANSI Accredited Standards Committee X12 The committee was chartered by ANSI in 1979 to develop uniform standards for the electronic interchange of business documents 

ECR: Efficient Consumer Response Utilized by the Grocery Industry 

DEX/UCS: Direct Exchange UCS 

DISA: Data Interchange Standards Association Secretariat for ANSI ASC X12 

DSD:Direct Store Delivery 

EDI: Electronic Data Interchange A generic term for computer-to-computer
transmission 

EDIA: Electronic Data Interchange Association Wrote the original UCS and WINS standards; current acts as Secretariat for the Ocean, Rail, Motor and Air EDI standards. Hosts the annual Pan American EDI conference.

EDICA: Electronic Data Interchange Council of Australia The Australian EDI administrative organization 

EDICC: Electronic Data Interchange Council of Canada The Canadian EDI administrative organization 

EDIFACT: EDI for Administration, Commerce and Trade International EDI Standard set by the UN and administered in the US by DISA.

EFT: Electronic Funds Transfer The electronic transfer of funds from payer to payee through the banking system

Hub: Also called sponsors, hubs are large companies, very active in EDI, that strongly encourage their paper-based business partners to begin using EDI. 

ISO: International Standards Organization. 

JIT: Just-In-Time Manufacturing. 

NEX/UCS: Network Exchange UC. 

NRF: National Retail Federation. 

POS: Point-Of-Sale. 

Proprietary Standards: Industry specific or company specific data formats that do not comply with ASC X12 standards. 

Trading Partner: Vendor or other party with whom business is conducted. 

Transaction Set: A complete business document such as an invoice, a purchase order, or a remittance advice. 

VAN: Value Added Network.

Appendix V
EDI Mailing Lists in Internet

The following mailing lists provide forums for discussing EDI issues: 

edi-l 
General discussion of EDI issues. To subscribe, send an e-mail message to listserv@uccvma.ucop.edu, where the body of the message contains the following single line of text: 

		subscribe EDI-L first_name last_name 

ietf-edi 
Discussion of EDI over the Internet. This list was very active when it was the forum for developing a standard for doing EDI via SMTP and MIME. Currently, it is not very active. To subscribe, send an e-mail message to LISTSERV@BYU.EDU, where the body of the message contains the following single line of text: 

subscribe ietf-edi first_name last_name 

edi-new 
Discussion of new EDI standards and paradigms. This list is maintained manually. To subscribe, send an e-mail to edi-new-request@tegsun.harvard.edu, where the body of the message contains the folowing single line of text: 

subscribe edi-new first_name last_name 

open-edi 
Discussion of the Open-edi Reference Model. This list is owned by Klaus-Dieter Naujok, who is the UN/ECE/TRADE/WP.4 Liaison Rapporteur. To subscribe, send an e-mail message to majordomo@utu.premenos.com, where the body of the message contains the following single line of text: 

subscribe open-edi 

ecat 
Forum for the U.S. Electronic Commerce Acquisition Team (ECAT). To subscribe, send an e-mail message to listserv@forums.fed.gov, where the body of the message contains the following single line of text:

subscribe ecat first_name last_name

Network Working Group
Request for Comments: 1865
Category: Informational	W. Houser
Dept. of Veterans	Affairs
J. Griffin
Athena Associates
C. Hage
C. Hage Associates	
January 1996

                         EDI Meets the Internet

                    Frequently Asked Questions about
           Electronic Data Interchange (EDI) on the Internet

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This memo is targeted towards the EDI community that is unfamiliar
   with the Internet, including EDI software developers, users, and
   service providers.  The memo introduces the Internet and assumes a
   basic knowledge of EDI.

Table of Contents

   1. Introduction ................................................    4
   1.1.  What is this document ....................................    4
   1.2.  What do you mean by electronic data interchange (EDI) ?  .    4
   1.3.  What are the X12 Standards that I should be aware of ?  ..    4
   1.4.  To whom do I send comments and suggestions ? .............    5
   1.5.  How can I get a copy of this document? ...................    5
   2. General Information .........................................    6
   2.1.  What is the Internet ?  ..................................    6
   2.2.  Is there a difference between EDI and
         electronic commerce (EC) ? ...............................    6
   2.3.  What makes the Internet useful for EDI ?  ................    6
   2.4.  Does this means we will now have to coordinate our
         EC/EDI activities with the Internet?  ....................    7
   2.5.  How do I find the addresses of other Trading partners
         on the Internet if I don't have to coordinate my EDI
         activities with a central organization or VAN?  ..........    7
   2.6.  How fast is the Internet?  ...............................    7
   2.7.  What about reliability of the Internet?  .................    7
   2.8.  What are RFCs and where can I get them ?  ................    8

RFC 1865                 EDI Meets the Internet             January 1996

   2.9.  Where can I get general information about the Internet?  .    8
   3. Getting Connected To The Internet ...........................    9
   3.1.  What do I need to get to use the Internet?  ..............    9
   3.2.  What software is used to support electronic mail?  .......    9
   3.3.  What types of client-server or server-server
         protocols exist on the Internet?  ........................   10
   3.4.  What methods exist to broadcast information across
         the Internet?  ...........................................   12
   3.5.  What are the ways to connect to the Internet ?  ..........   13
   4. Organizational Issues .......................................   15
   4.1.  Why is the way we currently do EDI so limiting to its
         growth?  ..................................................  15
   4.2.  My organization has an internal automated system for
         processing requisitions and issuing purchase orders, but it
         does not create the X12 formatted EDI transactions; what
         should we do ?  ...........................................  16
   4.3.  My organization already has a dial-in bulletin board
         service (BBS) where we post transactions; should we
         keep it? ..................................................  16
   4.4.  My organization currently has a Trading Partner
         Agreement with each trading partner we're currently
         doing business with. Can we keep them ?  ..................  16
   4.5.  It would be nice to get more trading partners and/or
         more competition, but I'm worried about getting too many
         transactions to be able to handle them.  Has this been a
         problem ?  ................................................  17
   4.6.  Does this mean that I'll receive more messages ?  .........  17
   4.7.  If we see a transaction posted on VAN, how do we
         respond in electronic format ?  ...........................  18
   4.8.  My organization has an established bilateral
         relationship (such as an existing contract.  Can we
         send these transactions via the Internet ?  ...............  18
   5. The Role Of Value Added Networks ............................   18
   5.1.  What is a VAN?  ................... .......................  18
   5.2.  What is an Internet Service Provider (ISP)?  ..............  19
   5.3.  How might an ISP be used for EDI?  ........................  19
   5.4.  Doesn't EDI presume the services of companies called
         Value Added Networks (VANs)?  .............................  19
   5.5.  If I can use X12 protocol and my VAN to send
         transactions, what is the benefit of using
         the Internet?  ............................................  20
   5.6.  Can we expect VANs to offer connections to other VANs
         via the Internet?  ........................................  20
   5.7.  How can I use the Internet directly for exchanging EDI
         messages without going through a VAN?  ....................  20
   5.8.  Can the ISA 06 or 08 identify any entity other than the
         'end' Trading Partners (i.e. a routing entity) ?  .........  21

RFC 1865                 EDI Meets the Internet             January 1996

   5.9.  Can we specify both the recipient's address and their
         VAN address in the ISA ?  ................................   22
   5.10. Are there other options for routing EDI X12
         messages ? ...............................................   22
   6. US Federal Involvement ......................................   22
   6.1.  What is the commitment of the US Federal Government
         to EDI ?  ................................................   22
   6.2.  What is the timetable for the Federal effort ?  ..........   23
   6.3.  Will the US Government use the Internet to send
         EDI transactions ?  ......................................   23
   6.4.  I heard the US Government prohibited commercial use
         of the Internet?  ........................................   24
   6.5.  The US Government is using both Internet and OSI
         E-mail protocols.  What should one consider when
         choosing which to use ?  .................................   24
   6.6.  How is the US Government using VANs to distribute
         business opportunities?  .................................   25
   6.7.  How would use of the Internet for Federal procurement
         change this RFQ process?  ................................   25
   7. EDI Resources On The Internet ...............................   26
   7.1.  Are EDI Standards available on the Internet ?  ...........   26
   7.2.  Are EDIFACT Standards available on the Internet ?  .......   28
   7.3.  The EDI X12 standards are quite complex.  How do we
         decide what X12 transactions to implement and how ?  .....   29
   7.4.  What Implementation Conventions (ICs) are available
         over the Internet ?  .....................................   29
   7.5.  How can a trading partner keep up with all these
         implementation conventions (ICs) and revisions in
         X12 and EDIFACT? .........................................   31
   7.6   Where can I get information on EDI translation
         software ? ...............................................   31
   7.7.  How do I keep in touch with others pursuing EDI and
         Electronic Commerce on the Internet ? ....................   32
   7.8.  Can I get messages that have been previously posted
         to the EDI mailing lists ? ...............................   35
   7.9.  How do I make EDI related material available
         to the Internet community ? ..............................   35
   7.10. Where are EDI Archives on the Internet ? .................   35

   8. Security Considerations .....................................   36
   8.1.  What security measures are needed to connect to the
         Internet ?  ...............................................  36
   8.2.  How do we go about protecting our system ?  ...............  36
   8.3.  Is there good publicly available software I can use?  .....  37
   8.4.  How good are electronic or digital signatures ?
         Can they be used in court ?  ..............................  38
   8.5.  Are there other US government standards publications
         I should be aware of?  ....................................  38

RFC 1865                 EDI Meets the Internet             January 1996

   9. References ..................................................   39
   10. Credits ....................................................   40
   11. Authors' Addresses .........................................   41

1. Introduction

1.1.  What is this document

   This document is informational in nature and attempts to answer
   frequently asked questions concerning the use of the Internet for
   Electronic Data Interchange (EDI).  The primary audience is the EDI
   community that is unfamiliar with the Internet, including software
   developers, users, and service providers.   The reader needs some
   understanding of EDI.  Informational RFCs are prepared by the
   Internet Engineering Task Force (IETF) to improve understanding and
   effectiveness in the use of the Internet.

1.2.  What do you mean by electronic data interchange (EDI) ?

   Except as noted, the document refers to EDI as the use of the

        1) X12 standard developed by the ANSI Accredited Standards
           Committee X12 or

        2) EDIFACT[1] standard United Nations Economic Commission for
           Europe (UN/ECE), Working Party for the Facilitation of
           International Trade Procedures (WP.4).

   The differences between these standards is beyond the scope of this
   FAQ.  Both standards activities are managed in the US by:

                Data Interchange Standards Association, Inc,
                1800 Diagonal Road, Suite 200
                Alexandria, Virginia, 22314-2852
                Voice: 703-548-7005
                FAX: 703-548-5738

   There are numerous other standards one could use for EDI, but
   discussion of them is not in the scope of this document.

1.3.  What are the X12 Standards that I should be aware of ?

   ACCREDITED STANDARDS COMMITTEE (ASC) X12 Standards are available from
   DISA at the address specified in Question 1.  The following is a good
   starting set of X12 standards.

       1.  ASC X12S/94-172, An Introduction to Electronic
           Data Interchange, DISA 1994 Publications Catalog

RFC 1865                 EDI Meets the Internet             January 1996

       2.  ASC X12.3 Data Element Dictionary
       3.  ASC X12.5 Interchange Control Structure
       4.  ASC X12.6 Application Control Structure
       5.  ASC X12.22 Segment Directory
       6.  ASC X12.58 Security Structures

1.4.  To whom do I send comments and suggestions ?

   Readers are invited to add questions; please include an answer if you
   know or want to suggest one.  Of course corrections and comments are
   welcome; send them to the IETF-EDI mail list by subscribing as
   described in question 7.6.  Or a send your comment to
   houser.walt@forum.va.gov.

1.5.  How can I get a copy of this document?

   Request for Comments documents (RFC) are available by anonymous FTP.
   Login with the username "anonymous" and a password of your e-mail
   address.  After logging in, type "cd rfc" and then

        "get rfc1865.txt".

   A Web address for the RFC is:

      ftp://ds.internic.net/rfc/rfc1865.txt

   RFC directories are located at:

        o  Africa at:        ftp.is.co.za    (196.4.160.2)
        o  Europe:           nic.nordu.net   (192.36.148.17)
        o  Pacific Rim:      munnari.oz.au   (128.250.1.21)
        o  US East Coast:    ds.internic.net (198.49.45.10)
        o  US West Coast:    ftp.isi.edu     (128.9.0.32)

   RFCs are also available by mail.  Send a message to:
   mailserv@ds.internic.net. In the body type:

        "FILE /rfc/rfc1865.txt"

   NOTE: The mail server at ds.internic.net can return the document in
   MIME-encoded form by using the "mpack" utility.  To use this feature,
   insert the command "ENCODING mime" before the "FILE" command.  To
   decode the response(s), you will need "munpack" or a MIME-compliant
   mail reader.  Different MIME-compliant mail readers exhibit different
   behavior, especially when dealing with "multipart" MIME messages
   (i.e., documents which have been split up into multiple messages), so
   check your local documentation on how to manipulate these messages.

RFC 1865                 EDI Meets the Internet             January 1996

2. General Information

2.1.  What is the Internet ?

   It is the inter-working of existing corporate and government networks
   using commonly used telecommunications standards.  It is not a new
   physical network, although some new facilities may be needed.
   Rather, it is based on mutual interests of users to communicate more
   effectively via electronic message and file transfers.  Internet
   communications may be interpersonal (person-to-person) E-Mail or
   process-to-process like EDI.  Messages may be inquiries to shared
   databases and responses. Messages may be entire files.

2.2.  Is there a difference between EDI and electronic commerce (EC) ?

   Electronic Data Interchange (EDI) is defined as the inter-process
   (computer application to computer application) communication of
   business information in a standardized electronic form.  Electronic
   Commerce includes EDI, but recognizes the need for inter-personal
   (human to human) communications, the transfer of moneys, and the
   sharing of common data bases as additional activities that aid in the
   efficient conduct of business.  By incorporating a wide range of
   technologies, EC is much broader than EDI.  However, the focus of
   this document in on EDI, not electronic commerce.

2.3.  What makes the Internet useful for EDI ?

   The greatest benefits will derive from:

      o  Adoption of common standards and proven inter-operable systems,

      o  Adoption and deployment of a distributed Directory Service
         capability, so that one can readily contact electronically any
         other organization in the world.

      o  Explicit commitment by participating organizations to
         cooperatively route traffic, work to resolve addresses, and
         meet required standards.

      o  Ubiquitous network coverage from many service providers. This
         allows the customer to choose the level of service needed.

      o  Layering of applications (such as EDI) over existing, proven,
         applications.

      o  A standards process with reference implementations which
         all vendors have equal access.  (a.k.a. a level playing field).

RFC 1865                 EDI Meets the Internet             January 1996

      o  Widely available public domain software including but not
         limited to applications, protocol/transports and multiple
         platform development tools.

2.4.  Does this means we will now have to coordinate our EC/EDI
      activities with the Internet?

   The Internet is not an organization or government agency.  You use
   the Internet to do business like you would use the telephone.  The
   same Internet connection your organization uses to send electronic
   mail would be the one you use to send EDI transactions.  Software
   developers write EDI translators, packages or templates for your e-
   mail system so that you can handle your own EDI transactions.  Your
   EDI activities do not need to be coordinated, but your connection to
   the Internet does.

2.5.  How do I find the addresses of other Trading partners on the
      Internet if I don't have to coordinate my EDI activities with
      a central organization or VAN?

   The Internet works by assigning names or "domains" to
   networks/companies/machines.  This is called the Domain Name Service
   (DNS). It works from a distributed tree structure.  The Internet
   requires registration of your Internet Protocol (IP) address and
   Domain Name in the Domain Name Service (DNS).  Your internet service
   provider can do this for you or assist you in contacting the right
   people to get your assigned addresses and domain names.

2.6.  How fast is the Internet?

   For a modest amount of data with a dedicated connection, a message
   transmission would occur in a matter of seconds, unless the ISP
   selected one of the trading partners is overloaded.  The maximum
   delay over the internet backbones is at most a few seconds.  Like the
   interstate highway system, speed depends on how close you and your
   trading partner are to Internet backbones.  Unfortunately, some areas
   may lack the capacity or "bandwidth" to handle the workload your
   organization requires.  Contact your local Internet Service Provider
   for details on service in your area.  Also, the more you are willing
   to spend, the better the service.  The Internet is inexpensive, but
   (contrary to popular mythology) it is not free.

2.7.  What about reliability of the Internet?

   For high reliability mission critical applications, redundant ISPs
   may be used (with separate backbones), and redundant mail servers at
   separate locations can be used. A single internet email or server
   address can be used to transparently route to any of the redundant

RFC 1865                 EDI Meets the Internet             January 1996

   servers or network connections.

   If a dedicated Internet connection is used to transmit information,
   e.g., via SMTP (see questions 3.2 and 3.5), then the message is
   delivered directly to the trading partner's system and delivery is
   assured. If a part time store and forward connection is used, then
   the integrity of the message depends on the ISP or other computers
   used in the forwarding of a message.

2.8.  What are RFCs and where can I get them ?

   RFC stands for Request For Comments.  The RFC series of notes covers
   a broad range of topics related to computer communications.  The core
   topics are the Internet and the TCP/IP protocol suite.  There are
   three categories of RFCs today, Standards Track, Informational, or
   Experimental.  Many of the RFCs describe de-facto standards in the
   Internet Community.  Copies of RFCs are often posted to the USENET
   newsgroup comp.doc and obtainable from archive sites such as
   ds.internic.net.

                        ftp://ds.internic.net/rfc/

2.9.  Where can I get general information about the Internet?

   Your local bookstore probably has one of the many recent introductory
   publications on the Internet.  In addition, look for (or have someone
   get you) the following bibliographies for free:

         RFC 1175
             Bowers, K., LaQuey, T., Reynolds, J., Roubicek, K.,
             Stahl, M., and A. Yuan, "FYI on Where to Start -
             A Bibliography of Internetworking Information",
             08/16/1990 (FYI 3)

                    ftp://ds.internic.net/rfc/rfc1175.txt

         RFC 1463
             Hoffman, E., and L. Jackson, "FYI on Introducing the
             Internet -- A Short Bibliography of Introductory
             Internetworking Readings for the Network Novice",
             05/27/93 (FYI 19)

                    ftp://ds.internic.net/rfc/rfc1463.txt

   The reader may want to look at the Frequently Asked Questions (FAQ)
   document for the newsgroup alt.internet.services.  This FAQ, as well
   as all Usenet FAQs, can be retrieved via ftp from rtfm.mit.edu in the
   directory /pub/usenet/news.answers.  These FAQs are also available

RFC 1865                 EDI Meets the Internet             January 1996

   from ftp.sterling.com in the directory /usenet/news.answers.

3. Getting Connected To The Internet

3.1.  What do I need to get to use the Internet?

   You need to know your existing telecommunications connectivity,
   address resolution, and routing capabilities.  Then you need to
   establish and operate an Electronic Mail gateway and/or other
   application gateway, e.g., for the file transfer protocol (FTP).
   Larger organizations may supply their trading partners with the
   TCP/IP software and X12 translator interfaced to E-mail or FTP.

3.2.  What software is used to support electronic mail?

   a) Simple Mail Transfer Protocol (SMTP) Servers

      A dedicated internet connection usually uses SMTP software to send
      and receive messages. The SMTP server may transfer messages to the
      "spool" area for incoming email in the file system, may queue the
      messages for transmission via UUCP, may hold mail in a POP server,
      or may transfer the message to a proprietary email system.

   b) Unix-to-Unix Copy (UUCP) Servers

      A UUCP server is used to transfer messages when a store and
      forward is used, either between machines within a WAN, or to
      another machine with a dialup link.

   c) Post Office Protocol (POP) mail Servers

      A POP server holds email which can later be retrieved by a client
      application run by the user, typically on a PC which might not be
      running 24 hours a day.  The TCP/IP protocol is used either over a
      LAN or dialup SLIP connection to retrieve messages.

   d) Mail User Agents (Mail Readers)

      Uses or applications employ client programs to retrieve and
      display email messages from the file system mail spool area, or
      from another server computer using POP or some other proprietary
      protocol (e.g. Microsoft-Mail). This mail user agent (UA) software
      is also used to compose and send email via a POP server or system
      email.

      The mail user agent may also process attached files using a
      proprietary format within a mail message, using one of the common
      de-facto standards, or using the Multipurpose Internet Mail

RFC 1865                 EDI Meets the Internet             January 1996

      Extensions (MIME) internet standard.  Among other things, MIME
      permits the identification and concatenation of message parts
      (called "body parts") into a single message that can traverse the
      Internet using the SMTP protocol.  The Work in Progress, "EDI in
      MIME"  provides the necessary standards for MIME compliant user
      agents to identify EDI body parts.  A MIME compliant mail reader
      can process the contents of the messages and dispatch data to
      external software. For example, files can be dragged to file
      system directories, images can be displayed, and audio data can be
      played.  In the case of EDI, a message formatted according to the
      MIME-EDI specification could be automatically transferred to an
      EDI processing program.

   e) Automated Mail Processing

      A typical Mail User Agents is an interactive application. However
      there are automated email message processing programs which can
      sort incoming mail, process forms returned by others, or in the
      case of EDI data, transfer the message contents to the EDI system.
      Messages formatted according to the MIME EDI specification can be
      properly recognized by any MIME compliant mail processing program.

3.3.  What types of client-server or server-server protocols exist on
      the Internet?

   Internet email is typically used for two party messaging. The FTP,
   gopher, and HTTP protocols allow many users, possibly anonymous, to
   retrieve data from a central source. For example, corporate catalogs
   can be restricted by potential customers.

   a) File Transfer Protocol (FTP)

      Companies with existing connectivity to the Internet may use FTP
      to transfer files to one-another or to their VAN.  This solution
      employs the same TCP/IP used for SMTP.  Furthermore, Internet
      documents such as EDI in MIME Work in Progress are available via
      FTP on the FTP server "ds.internic.net."

   b) gopher service protocol.

      Gopher service is a way of organizing selected documents and files
      on an Internet server in a simple tree menu, so that users on
      other Internet computers can find them easily.  Most gopher menus
      are also linked to other gopher menus elsewhere, so that users can
      easily jump from one Internet server to another.  There are
      thousands of gopher servers in operation worldwide.

RFC 1865                 EDI Meets the Internet             January 1996

   c) The Hypertext Transfer Protocol (HTTP)

      HTTP defines http-server and http-clients that comprise the World
      Wide Web (WWW).  WWW was developed by the European Laboratory for
      Particle Physics (CERN) as a tool for exchanging multimedia data
      between researchers.  Although there is also no specification for
      graphics in HTTP, most web browsers are graphical in nature.
      Mosaic, available free from the National Center for Supercomputer
      Applications (NCSA), provides a Graphical User Interface (GUI)
      that facilitates user access to information on the Internet.
      Mosaic interprets hypertext based information on the WWW, as well
      as to other linked Index/Directory services such as Archie, FTP,
      Gopher, and X.500 Directory information.  Mosaic also supports on
      line Graphic Interchange Format (GIF), Joint Photographic Experts
      Group (JPEG), Motion Picture Experts Group (MPEG), QuickTime, and
      other document, image, and audio types.  Vendors have developed
      product catalogues using Mosaic servers.

   d) WHOIS

      WHOIS servers generally offer information about the organization
      to which they belong.  There are many WHOIS servers scattered
      throughout the Internet.  To obtain a list of registered WHOIS
      servers, anonymous FTP to rtfm.mit.edu and get the file
      /pub/whois/whois-servers.list.  You can:

       o   run a client program on your own machine to access the
           WHOIS server,

       o   telnet to a site which hosts the server, eg: telnet to
           whois.internic.net and type help to access the full online
           help

       o   send an email message to retrieve information from the
           database.  eg: send email to mailserv@internic.net with
           a command in the Subject field.  Any information in the
           body part of message will be ignored.  ie.

                Subject:  whois <search string>

           Therefore, to find information on the Internic Registration
           Service, the subject should contain: whois internic

           Moreover, to obtain help information on this service you can
           send two separate email with the following in their subject
           line, respectively:

RFC 1865                 EDI Meets the Internet             January 1996

                             help
                             whois help

3.4.  What methods exist to broadcast information across the Internet?

   There are also some usual methods to broadcast messages to multiple
   recipients as described below:

   a) Usenet News

      Usenet news is a cooperative broadcast of messages to all
      participants.  Messages are organized into categories called
      newsgroups, and there are over 10,000 newsgroups carried by the
      major ISPs.  Individual customers typically subscribe to some
      subset of these which is of interest to the organization.
      Messages are typically held for a week or two, then either
      archived or discarded.  Some newsgroups are free form, i.e. anyone
      can post a message, while others are "moderated", i.e. require
      approval prior to posting.

      Though not currently used for any type of EDI, Usenet news could
      be used to broadcast RFQs. For example, comp.newprod is used to
      announce new products, and misc.jobs.wanted is used to announce
      job openings.

   b) Mailing Lists

      If the interest is limited, a mailing list may be used in lieu of
      a newsgroup.  These are typically used for discussion groups or
      announcements of a particular nature.  Mailing lists are typically
      open, i.e. anyone can "subscribe" by sending an email message to a
      server. For discussion groups, anyone can send a message to the
      server which is then rebroadcast to all subscribers.  Since
      Internet email is extremely inexpensive, there is normally no
      charge for use of a mailing list, except for the content of
      e-magazines, etc.  Sponsors of an email list typically provide the
      list as a public service.

      For example, a mailing list could be used to broadcast EDI RFQs,
      etc.  Vendors might subscribe to various lists related to their
      product or service in order to receive messages sent by potential
      customers. Mailing lists could be provided by large companies for
      internal use, by industry organizations, or VANs.  For example, a
      firm or government agency could sponsor various mailing lists for
      EDI RFQ's, new product announcements, etc. related to procurement.
      The organization could easily allow other potential customers to
      use the same mailing lists to contact vendors.  All parties would
      benefit, and the improved access to vendors from an open mailing

RFC 1865                 EDI Meets the Internet             January 1996

      list would more than offset the cost to support the mailing list
      server. Thus service might be available for free.

3.5.  What are the ways to connect to the Internet ?

   The following provides a general overview of connectivity options now
   available:

   a) Dedicated Connection

      Typically a leased telephone line is used to connect a gateway
      computer or Typically a leased telephone line is used to connect a
      gateway computer or bridge/router of a corporate LAN/WAN to the
      router of the Internet Service Provider's (ISP) Point-Of-Presence
      (POP, not to be confused with the Post Office Protocol). The
      connection may be of various types and speeds, e.g.  modem, ISDN,
      DS0, or DS1 line.

      With a dedicated connection, the SMTP protocol is typically used
      to deliver email directly to a trading partners system. Also,
      real-time client server applications can be run directly with a
      trading partners system, including information transferred using
      the FTP and HTTP protocols.

      Some ISPs provide optional services even with dedicated
      connections.  For example, store and forward email on an ISP
      server can be used as a backup for a direct SMTP server operated
      by a trading partner.  The ISP may offer disk space on their FTP
      and HTTP servers with a high speed connection to the Internet.
      For example, a trading partner might use a 14.4Kb modem for
      dedicated email transfers and use a 1.5Mb connection operated by
      the ISP to distribute FTP and HTTP information.

   b) On-demand Connection

      An on-demand connection operates like a dedicated connection,
      except a dialup ISDN or modem connection is used. If the link
      remains idle for a certain period of time, the connection is
      dropped.  Some ISPs offer dial-out capability so any inbound or
      outbound traffic can reestablish the link. However, many ISPs
      require their customers to dial-in, so only outbound traffic and
      regular polling will establish the link. In the latter case, store
      and forward would likely be used for email, and the ISP servers
      would be used for FTP and HTTP information.

RFC 1865                 EDI Meets the Internet             January 1996

   c) Part-time Polled Connection

      The Unix-to-Unix Copy (UUCP) protocol is typically used for email,
      news, and (rarely) file transfers.  A client organization
      periodically dials the ISP and transfers email and Usenet news for
      the organization, then disconnects.  Typically, the client polls
      the ISP at regular intervals, e.g. every 20 minutes, though some
      ISPs dial out when a message is to be delivered.  Outgoing email
      can be sent immediately, or queued for transmission with a
      specified maximum delay.

      A UUCP connection may be used to transfer messages to an arbitrary
      number of people or automated mail processing programs.  A single
      UUCP connection may also route messages to other systems, e.g.
      divisions within a corporation.  UUCP and store-and-forward are
      synonymous.

      Since UUCP is only used to transfer mail and news messages,
      interactive internet client-server applications like FTP and HTTP
      are not available, except using a server provided by an ISP. Thus
      a separate dialup account might be needed to retrieve information
      from other FTP or HTTP servers. UUCP might be used for automated
      email transfer, and a on-demand dialup connection would be used
      for interactive internet client applications.

      Though UUCP accounts imply a delay (up to the polling interval) in
      processing a message, many ISPs allow a customer supplied script
      to process messages immediately on the ISP's machine.  Though UUCP
      can be used to transfer files directly, usually files are
      transferred by encoding them within an email message.
      Transmission within internet email messages is much more widely
      supported and can be gatewayed into proprietary systems.

   d) Dial-up Shell Account

      With a dial-up account, a single user with a personal computer
      running a terminal emulator connects to the ISP's computer.  Mail
      readers, news readers, HTTP browsers, etc. can be run on the ISP
      machine. Data on the ISP machine can be transferred to the
      personal computer manually using a protocol like X-Modem, Z-Modem,
      or Kermit.

      The ISP's host computer may run one of the usual UNIX command line
      (shell) programs, or may use a custom BBS or other menu driven
      user interface. A proprietary client-server program may be used in
      lieu of a terminal emulator to provide a graphic user interface.
      Some of the proprietary GUI clients provide access to selected
      internet applications, e.g. gopher.

RFC 1865                 EDI Meets the Internet             January 1996

      A dialup ISP typically has a direct internet connection, however
      very low cost providers might only have a UUCP connection to the
      Internet. Some large proprietary networks such as CompuServe do
      not offer a direct internet connection, and only support UUCP
      email and, sometimes, Usenet news gateways to the Internet.

   d) Personal Serial Line Internet Protocol (SLIP) or Point to Point
      Protocol (PPP) Account

      A SLIP/PPP account is also available as a cross between the on
      demand and dial- up. Like the on-demand account, a single user can
      connect to an ISP and run mail reader, news reader, FTP, HTTP
      browser, etc. client applications directly from a personal
      computer.  Unlike the on-demand account, the dial-out computer
      functions as a client only and not a server, and would be used by
      a single user rather than as a gateway to a LAN.

      With a SLIP/PPP account, the POP (Post-Office-Protocol) protocol
      is used for a user's mail reader client to retrieve messages
      stored in the ISP's server.  Unlike, UUCP, the POP servers hold
      mail for a single user (i.e. individual email address).

      With a SLIP/PPP connection any standard TCP/IP application is tied
      directly into the internet.  Thus unlike the proprietary GUI
      software supplied by the ISP, any TCP/IP client application can be
      used.

      A program such as TIA (The Internet Adapter) can be run on a shell
      account which allows a standard UNIX shell account to function as
      a SLIP/PPP account.  However, some ISPs do not support TIA as they
      charge extra for SLIP.

4. Organizational Issues

4.1.  Why is the way we currently do EDI so limiting to its growth?

   There is a tendency for each organization to establish is own rules
   and administrative policies, leading to rising costs of dealing with
   multiple trading partners, each in turn with its own requirements and
   procedures.  However, new technologies and business practices are
   necessary if EDI is to move beyond the 30 to 40,000 organizations
   presently using EDI.  According to Department of Labor and Internal
   Revenue Service statistics, there are about 6.2 million entities with
   employees and about 14 million other "business" entities.  A business
   that wants to sell chairs, for example, would have to check with many
   different customers to see if they had any requirements.  By making
   it possible for a business to use a common method to look for
   customers, the barriers entering to the electronic marketplace are

RFC 1865                 EDI Meets the Internet             January 1996

   greatly eased.  This does not mean that there is only one source that
   everyone goes to for a list of current business opportunities.
   Rather, a prospective supplier only needs to go to a single
   electronic marketplace.  To communicate with each other, the various
   participants in electronic commerce need to harmonize their
   procedures and processes.  Examples include common trading partner
   registration and the adoption of standard implementation conventions
   for EDI messages.

4.2.  My organization has an internal automated system for processing
      requisitions and issuing purchase orders, but it does not create
      the X12 formatted EDI transactions; what should we do ?

   You could enhance your existing system, for example, by adding EDI
   translation software.  VANs often offer EDI "translation"
   capabilities that convert flat text files into EDI X12 or EDIFACT
   format.  This translation software may be designed with a particular
   technical solution in mind; carefully consider how the software would
   be used and what applications and telecommunications software would
   need to interact with it.  You don't want to inadvertently lock
   yourself into using only one supplier.

4.3.  My organization already has a dial-in bulletin board service
      (BBS) where we post transactions; should we keep it?

   Yes, but that puts you in the role of being your own VAN.  By acting
   independently, organizations have established their own dial-up
   electronic bulletin board system with their own unique, but
   functionally equivalent, operating rules.  Your BBS will be a little
   different that the next organization's, making it difficult for
   suppliers to access.  By getting transactions from the VANs who
   specialize in moving information, your organization will get the
   widest circulation possible.  You will be able to reach trading
   partners you may not even know existed, resulting in more competitive
   bids.  Because of their idiosyncratic nature, BBS are not consistent
   with the idea of a "single face to industry" espoused by the Federal
   Government.

4.4.  My organization currently has a Trading Partner Agreement
      with each trading partner we're currently doing business with.
      Can we keep them ?

   In the short run you may want to keep some Agreements in place to
   cover unique circumstances.  But be careful not to create conflicting
   agreements and directions for your trading partners.  Follow the
   procedures common to your particular line of business.  In the long
   run, less is better.  Hopefully, the introduction of EDI into common
   commercial practice will eliminate the need for EDI-specific

RFC 1865                 EDI Meets the Internet             January 1996

   agreements.

4.5.  It would be nice to get more trading partners and/or more
      competition, but I'm worried about getting too many transactions
      to be able to handle them.  Has this been a problem ?

   The answers to this and related questions presupposes a willingness
   to participate in the open bidding process.  While this process is a
   legal requirement for government agencies, many private organizations
   choose not to adopt the practice.  The technology of the Internet
   facilitates competition, but the cost of putting these practices in
   place limit their value.  This is a business decision, not a
   technical one.  Will companies competitively procure critical
   supplies absent a long term relationship with the supplier? For
   essential inputs that will make or break customer satisfaction and
   productivity, the benefits of competition may not be worth the risks.

   Many organizations experience some increase in the number of
   transactions; for competitive procurements, the winning bid should be
   significantly better than those received prior to using the
   electronic system.  The impact of an increase in volume needs to be
   evaluated on a situation by situation basis.  For example, your
   acquisition support system may need to be re-engineered to quickly
   handle bids by ranking and presenting them to your buyers in low to
   high order.  Your new or enhanced system should make it easy to
   receive and reply to any inter-personal messages that are sent and
   linked to a bid (that is, an SMTP/MIME message or the EDI X12.864
   text message transaction set).

4.6.  Does this mean that I'll receive more messages ?

   There is a strong likelihood the number of messages will increase as
   There is a strong likelihood the number of messages will increase as
   you reach more and more trading partners.  After a reasonable trial
   period, your EDI trading partners should be relying on EDI and
   disinclined to use alternative forms of communication that don't fit
   EDI/EC.  Once you use EDI/EC to communicate with a trading partner,
   you should consider discouraging the use of telephone calls or fax
   messages or other non-EDI/EC messages by pointing out the fact that
   telephone or fax messages are processed more slowly.  By using
   electronic messaging, you can establish a written and dated audit
   trail.  Your application system can route the message to the buyer
   and "attach" it to a "case file".  However, if your organization does
   not use automated systems, you will want to adjust your approach to
   dealing with non-EDI messages.

RFC 1865                 EDI Meets the Internet             January 1996

4.7.  If we see a transaction posted on VAN, how do we respond in
      electronic format ?

   This function is typically handled by applications software, not by
   the Internet.  For example, a vendor that wishes to bid on a
   particular Request For Quotation (RFQ) would prepare a bid (X12-843)
   and send it via their VAN of choice.  The identification information
   in the interchange control header (ISA) and functional group header
   (GS) will be interpreted by your VAN and forwarded to the buyer's VAN
   or to the buyer directly, depending on the reply address.  VANs may
   reject messages from unregistered sources; otherwise they are
   forwarded to (or otherwise made available to) the buyer.  If a buyer
   is using dial-up access to a VAN, then they will have to call-in for
   their messages.

4.8.  My organization has an established bilateral relationship
      (such as an existing contract.  Can we send these transaction
      via the Internet ?

   Yes, the Internet can be used to send transaction sets to existing
   trading partners via SMTP or FTP messages.  VANs were typically used
   for bilateral relationships between companies, whereas the Internet
   is useful for establishing multilateral relationships.  These
   bilateral relationships are usually quite stable, but both parties
   had to agree to share the same VAN or get their VANs to interconnect.
   Multilateral relationships are between organizations that don't
   necessarily have existing relationships and may be rather ephemeral.
   The Internet is suited to dynamic multilateral relationships that may
   later evolve into static bilateral relationships between companies
   using VANs.  Therefore, the issues concerning the Internet (security,
   availability, etc.) are manageable in the early stages of forming a
   relationship.  If your current VAN is not capable of using the
   Internet, you may need an alternative route for those messages.
   Later, as the business relationship matures, the use of VANs may be
   appropriate as the level of communication becomes more important.
   For example, unless your system has a directory of all registered
   trading partners, you lack the capabilities to screen and validate
   transactions that arrive at your site.

5. The Role Of Value Added Networks

5.1.  What is a VAN?

   The use of EDI over the Internet is in the early stages, although the
   technology and services are developing remarkably rapidly.  In the
   past, organizations doing EDI typically have relied on specialized
   firms called Value Added Networks (VANs) for technical assistance.
   Many of these organizations will look to their VAN for assistance in

RFC 1865                 EDI Meets the Internet             January 1996

   using the Internet.  VANs specializing in EDI applications provide
   technical support, help desk and troubleshooting for EDI and
   telecommunications problems.  They assist in configuration of
   software, upgrades to telecommunications connectivity, data and
   computer security, auditing and tracing of transactions, recovery of
   lost data, service reliability and availability.  Some EDI specific
   services can include broadcasting an RFQ to a collection of vendors,
   or storage of EDI information for later search and retrieval.

5.2.  What is an Internet Service Provider (ISP)?

   VAN services have typically used proprietary network or a network
   gatewayed with a specific set of other proprietary networks.  In
   contrast an Internet Service Provider (ISP) offers generic network
   access (i.e. not specific to EDI) for all computers connected to the
   internet. A direct internet connection permits real time computer-
   computer communication for client-server applications.
   Alternatively, a part time internet connection can be used to access
   internet servers using an on-demand basis, or access another system
   via email which includes a store and forward method.  Internet email
   may be used as a gateway to proprietary networks if the proprietary
   network has an email gateway.

5.3.  How might an ISP be used for EDI?

   Internet email can be configured for a dedicated connection with
   real-time transfers, or a store and forward method (like traditional
   VANs), or a combination of the two, e.g. where a direct delivery to a
   trading partners system is used when a link is operational, and a
   store and forward from an ISP is used as a backup.

   A large organization can connect their network to the Internet at an
   internet exchange point, however, most use a commercial ISP, either a
   major backbone provider, or local resellers of service off one or
   more backbones. The ISP provides technical assistance and access to
   local telecommunications links.

5.4.  Doesn't EDI presume the services of companies called
      Value Added Networks (VANs)?

   EDI only specifies a format for business information; the
   transmission of the information is covered under other standards. A
   real world analog is sending a business form from one company to
   another. The "form" could be sent via US mail, US Registered mail,
   via private carrier (UPS/FEDEX) or simply faxed between the
   companies.  EDI only requires that the trading partners follow the
   content standards.

RFC 1865                 EDI Meets the Internet             January 1996

5.5.  If I can use X12 protocol and my VAN to send transactions,
      what is the benefit of using the Internet?

   The Internet E-mail standards have hierarchical address spaces that
   are defined and updated in what the Internet calls "domain name
   servers."  Unfortunately, X12 has a flat address space.  So, when you
   send an interchange (not via the Internet) to a partner who is on a
   different VAN, your VAN must do a table look up to figure out what
   VAN the receiving party is on.  If you use only X12 without the
   Internet, before you can send a message to this partner, you must
   first contact the recipient's VAN and have them add you as an entry
   to his VAN's table.  If the ISA contained the VAN ID of the
   recipient, then you could (in theory) send interchanges to partners
   via the VAN interconnects without having to notify the recipient's
   VAN first.  However, this theory needs to be worked out in practice.
   In contrast, thanks to the domain name service, Internet e-mail users
   (and Postal users) don't have to call up their service provider
   before sending a message across an "interconnect" to another service
   provider.

5.6.  Can we expect VANs to offer connections to other VANs via the
      Internet?

   All VANs connected to the Internet are connected to one another, thus
   avoiding most of the problems of interconnecting proprietary
   networks.  VANs can then focus on services to their customers such as
   automatic bid submission, market and business opportunity analysis,
   and translation software.

5.7.  How can I use the Internet directly for exchanging EDI messages
      without going through a VAN?

   You and your trading partner must agree on one of the Internet
   protocols for exchanging messages and then agree upon some details
   with the exchange.

   a) Email based messaging

      The simplest and most widely supported means of exchanging
      messages is via internet email. Typically, the IETF-MIME
      encapsulation specification would be used to enclose the EDI
      data within the email message, and the trading partners would
      need to agree upon an encryption method for secure email,
      typically PEM or PGP (see question 8.4).

      The trading partners would then exchange:
          1. The internet email address for EDI messages
          2. An internet email address for personal communications

RFC 1865                 EDI Meets the Internet             January 1996

             related to EDI
          3. Agreement on the encryption and digital signature
             protocols, including email acknowledgment, e.g.
             support for the "Return-Receipt-To:" email header,
             or X.400 extended email header fields.
          4. Public Keys for PEM or PGP encryption and digital
             signatures.  (or private keys for DES encryption)
          5. Agreement on the format of the message, e.g. IETF MIME/EDI.

      A convention for naming email addresses might be
      established, e.g. edi@edi.xyzcorp.com for messages,
      ediinfo@xyzcorp.com for an automated response for human readable
      information on establishing internet EDI, and
      edisupport@xyzcorp.com for a personal contact.

   b) FTP based messaging

      To exchange EDI messages via FTP, some setup information must be
      included in the trading partner agreement. Typically, an account
      would be created for each trading partner for a FTP login,
      including a password. Typically, each X12 or EDIFACT message
      would be stored in a file, and the trading partner agreement would
      define the conventions for naming files and directories for
      the messages.

      The trading partner agreement would include:
          1. FTP login name and password
          2. Machine(s) from which the login will be accepted
          3. Additional security protocols, e.g. Kerberos[?]
          4. Directory and file naming conventions
          5. File encryption protocols and keys
          6. Wrappers around EDI data, e.g. MIME/EDI headers,
             PEM/PGP wrappers, etc.

   There are several compression routines and utilities available for
   virtually any computer system that uses the Internet.  Many of these
   utilities will convert across platforms (say UNIX to Mac, UNIX to PC,
   and vise versa) and are available for free from one of several ftp
   archive servers.  Use of these compression routines should be used
   with care when one is employing an encryption technique such as PEM
   or PGP.

5.8.  Can the ISA 06 or 08 identify any entity other than the
      'end' Trading Partners (i.e. a routing entity) ?

   Yes, although the ISA06 and ISA08 elements are supposed to be used to
   identify the sender and receiver of the interchange, the receiver of
   the interchange could be a clearinghouse (as well as a VAN) that

RFC 1865                 EDI Meets the Internet             January 1996

   processes the interchange and then forwards the data to the ultimate
   recipient.  In this case, you could put the receiver ID of the
   clearinghouse into the ISA08. The clearinghouse would probably have
   to determine the ultimate recipient of the message by looking inside
   the transaction set (or perhaps by using the GS03).  Alternatively,
   you could put the receiver ID of the ultimate recipient into the
   ISA08 and the clearinghouse would route the interchange based on the
   ISA08 value (just as a VAN does).

5.9.  Can we specify both the recipient's address and their VAN
      address in the ISA ?

   There was an X12 DM (data maintenance) request proposed to the X12
   standards committee for a change to the ISA segment (X12 header
   information) that would allow users to specify the recipient's VAN,
   in addition to the recipient's ID.  The intent was to provide a
   hierarchical address in the ISA.  The top level would be the VAN ID,
   and the next level would be the recipient ID.  To date, this DM has
   not been approved.

5.10.  Are there other options for routing EDI X12 messages ?

   Yes, the GS02 and GS03 data elements can be used for a second level
   of routing.  The GS03 is the application receiver's code.  Some EDI
   users use the GS03 for routing a functional group to a particular
   department or application within the receiver's corporation.  For
   example, you could use the ISA08 to identify the receiver as "Acme
   Corporation" and use the GS03 to identify the receiving application
   as the "Purchasing department (within Acme Corporation)".  Many EDI
   users simply put the same value in the ISA06 and the GS02, and put
   the same value in the ISA08 and the GS03.  Interestingly, there are
   VANs that will broadcast a message.  Other VANs will map the value of
   the ISA08 into a distribution list VAN mailbox ids maintained by the
   VAN.  Thus, each recipient receives the exact same copy of the
   interchange and the value of the ISA08 is not changed by the VAN.

6. US Federal Involvement

6.1.  What is the commitment of the US Federal Government to EDI ?

   In the Federal Information Processing Standard (FIPS) 161-1 for
   Electronic Data Interchange[2], the US Government committed to using
   EDI X12 and EDIFACT standards in the exchange of business information
   with trading partners already using EDI.  On October 26, 1993,
   President Clinton signed an Executive memorandum requiring Federal
   agencies to implement the use of electronic commerce in Federal
   purchases as quickly as possible.  As the initial step the
   President's Management Council (PMC) Electronic Commerce Task Force

RFC 1865                 EDI Meets the Internet             January 1996

   (ECTF), chaired by the Administrator, Office of Federal Procurement
   Policy (OFPP), chartered the Federal Electronic Commerce Acquisition
   Team (ECAT) memorandum.  The PMC gave ECAT the task of defining the
   architecture for the government-wide electronic commerce acquisition
   system and identifying the executive departments or agencies
   responsible for developing, implementing, operating, and maintaining
   the Federal electronic system.

   ECAT has become the Federal Electronic Commerce Program Management
   Office (ECA-PMO).  The National Institute or Science and Technology
   (NIST) maintains an HTML home page for the ECA-PMO:

              http://snad.ncsl.nist.gov/dartg/edi/fededi.html

6.2.  What is the timetable for the Federal effort ?

To implement EC and to achieve his objectives for EC, the President
set forth the following four milestones:

      1)  By March 1994, define the architecture for the
          government-wide EC acquisition system and identify
          executive departments or agencies responsible for
          developing, implementing, operating, and maintaining
          the Federal electronic system.  The ECAT identified
          the architecture and recommend actions that each agency
          should take.  These documents are available via ftp at
          ds.internic.net in the directory /pub/ecat.library.

                 ftp://ds.internic.net/pub/ecat.library/

      2)  By September 1994, establish an initial EC capability
          to enable the Federal government and private suppliers
          to exchange standardized requests for quotations (RFQs),
          quotes, purchase orders, and notice of awards and begin
          government-wide implementation.

      3)  By July 1995, implement a full-scale Federal EC system
          that expands initial capabilities to include electronic
          payments, document interchange, and supporting data bases.

      4)  By January 1997, complete government-wide implementation
          of EC for appropriate Federal purchases, to the maximum
          extent possible.

6.3.  Will the US Government use the Internet to send EDI transactions ?

   According to the ECAT, achieving the following objectives are
   essential for a successful ubiquitous government EDI capability:

RFC 1865                 EDI Meets the Internet             January 1996

      1)  E-mail systems may be used as the transport medium for EDI
          transactions.

      2)  FTP, FTAM, SMTP, X.400, or X.400 compatible substitutes
          are the preferable transport methods for EDI.

      3)  EDI functionality must be supported such that the user can
          choose between the Internet Protocol Suite (IPS) and Open
          Systems Interconnection (OSI) protocol support.

      4)  Directory services will be provided through the X.500 model
          as services become available.

      5)  Initial implementation of X.400 shall support the user agent
          services defined in P2 and P22 protocols.

      6)  By 1996, the X.400 implementations shall contain the
          services defined in the X.435 specification.

      7)  The Internet network may be used for EDI transactions when
          it is capable of providing the essential reliability,
          security, and privacy needed for business transactions.

6.4.  I heard the US Government prohibited commercial use of the
      Internet?

   The Internet contains many Internet Service Providers (ISPs), each
   with its own internal policies governing the conduct of its
   customers. One of the largest ISPs is the National Science
   Foundation.  At one time, NSF adopted what is called the Acceptable
   Use Policy of the National Science Foundation (NSF) was intended to
   prevent commercial uses of the original NSF-sponsored Internet
   telecommunications backbone.  However, the growing number of
   commercial providers and backbones now part of the Internet have made
   this policy obsolescent.  NSF is currently reducing its direct
   support in favor of subsidies to universities and other NSF sponsored
   organizations. Today the US Government is actively encouraging
   commercial uses of the Internet.

6.5.  The US Government is using both Internet and OSI E-mail
      protocols.  What should one consider when choosing which to use ?

   For more than a decade, Federal policy has been to promote the Open
   Systems Interconnection (OSI) telecommunications protocols developed
   by international standards bodies.  Despite this policy, Government
   agencies, like the private sector, have invested far more in Internet
   than OSI compliant products.  Marshall T. Rose's "The Internet
   Message"[3] compares the two alternative protocol suites and finds

RFC 1865                 EDI Meets the Internet             January 1996

   clearly in favor of the IPS for messaging in general.  For EDI
   specifically, the advantages of the IPS are its simplicity, wide
   availability, and security provided by Privacy Enhanced Mail (PEM,
   see below).  IPS lacks a number of desirable features and incurs
   something of an efficiency penalty for binary transfers.  On the
   other hand, the OSI standard for messaging handling service (X.400)
   promises a complete solution for EDI; the X.435 protocol includes
   responsibility notifications, X.500 directory support, EDI-specific
   addressing, message store support, message security, and other EDI-
   specific services.  Unfortunately, only a handful of X.435 products
   have actually reached the market, their interoperability is not
   assured, and their prices are substantially greater than for their
   IPS counterparts.  X.400 addressing tends to lock the customer into
   the domain of the service provider, whereas SMTP/MIME addresses are
   independent of the provider, permitting the customer to take his/her
   business elsewhere relatively easily.  The bottom line is that a lot
   more organizations do EDI via the Internet than via OSI.

6.6.  How is the US Government using VANs to distribute business
      opportunities?

   Presently, VANs make EDI request for quotation (RFQ) transactions
   available to their subscribers (along with other services).  For
   example, a VAN client may ask that all RFQs for chairs be forwarded
   immediately to them but the client is not interested in being
   notified about RFQs for paper products.  When a VAN sends an RFQ to a
   specific client mailbox, the VAN modifies the "to address" to that of
   the client.  In this way, a vendor need only subscribe to a VAN that
   is certified to receive and post the RFQs.  The vendor then sees a
   single source for all RFQs of interest, regardless of which buying
   organization originated them.  The screening and filtering process
   performed by the VANs prevents the spread of electronic "junk" mail.
   However, a trading partner could use an email filtering program to
   filter and sort email, saving on VAN charges.

6.7.  How would use of the Internet for Federal procurement change
      this RFQ process?

   Initially, very few changes may be apparent.  New and existing VANs
   will use the Internet to collect and disseminate EDI transactions;
   trading partners may be totally unaware of the change in technology.
   Prices may fall as VANs share telecommunications resources through
   Internet Protocols rather than maintain their own costly proprietary
   telecommunications services.  Instead of competing with VANs, the
   ubiquitous connectivity of the Internet offers VANs even greater
   business opportunities.  General purpose Internet Service Providers
   (ISPs) do not typically offer EDI specific services, but they can
   provide an alternative means to transfer EDI messages at a small

RFC 1865                 EDI Meets the Internet             January 1996

   fraction of the cost of typical EDI VANs.

   The impact of an organization's moving EDI onto the Internet,
   independent of a VAN, is more difficult to assess.  In the view of
   some, the introduction of the Internet in the near term (1-5 years)
   adds additional interfaces and complexity to the organization's
   existing EDI environment.  This may in the short term increase costs
   and raise new costs.  But a corporate commitment to an open systems
   environment through the use of Internet Protocols offers the
   potential for a greater interoperability, integration of application
   systems, and therefore the promise of higher performance and lower
   costs.  Some organizations will be able to get to these benefits
   others will pay for a set of largely incompatible services.  The
   return on investment largely depends on one's ability to consider EDI
   on the Internet as a part of the organization's overall information
   systems strategy and the organization's plans for a presence on the
   Internet.

7. EDI Resources On The Internet

7.1.  Are EDI Standards available on the Internet ?

   The Data Interchange Standards Association (DISA)  has a World Wide
   Web server at "http://www.disa.org/"  This Web server has
   considerable information, including a list of new standards, a list
   of all the X12 transaction sets, meeting minutes, calendar of events,
   and lists of courses.  Unfortunately, as of this date, the X12
   standards are not available electronically.  [soap ...] Hopefully
   that will be added soon.  [...soap].  DISA has also set up a gopher
   server (gopher.disa.org) and an FTP server (ftp.disa.org).

   The principle documents regarding ANSI ASC X12's planned alignment
   with EDIFACT are available on the World Wide Web.  The alignment plan
   adopted by a mail ballot of X12 in December 1994/January 1995 is at

                   http:/www.disa.org/info/alinplan.html

   The "floor motion" adopted at the X12 meeting in February 1995 is at:

                 http:/www.disa.org/meetings/alinmotn.html

   The following mail lists and exploders support X12 and EDIFACT
   standards development work.

RFC 1865                 EDI Meets the Internet             January 1996

   ------------------
   X12G Mailing list:
   ------------------

      This is a fully open exploder set up to support X12G.

      To subscribe send an e-mail message to:

                       x12g-request@snad.ncsl.nist.gov

      The text of the message should only contain the following:

                                subscribe x12g

      After you subscribe, you can broadcast your messages to the
      participants (who have subscribed) via the address

                           x12g@snad.ncsl.nist.gov.

   ---------------------
   FED-REG Mailing list:
   ---------------------

      This new exploder is concerned with the federal EDI Registry and
      the implementation of IMPDEF within the registry, the  EDI Viewers
      and Editors, and the use of IMPDEF to upgrade EDI products.  The
      nature of this mailist calls for informal discussion focusing on
      pragmatic issues.

      To subscribe send an e-mail message to:

                      fed-reg-request@snad.ncsl.nist.gov

      The text of the message should only contain the following:

                              subscribe fed-reg

      Messages intended for the fed-reg list should be sent to:

                          fed-reg@snad.ncsl.nist.gov

   -------------------------
   X12C-IMPDEF Mailing list:
   -------------------------

      This exploder deals with formal discussion in the context of X12
      regarding the evolution of IMPDEF. If would expect that
      discussions in the context of the "fed-reg" exploder result in

RFC 1865                 EDI Meets the Internet             January 1996

      formal DMRs submitted to "x12c-impdef" and X12C.  Anyway, the
      process will be defined and controlled by the appropriate X12C
      authority.

      To subscribe send an e-mail message to:

                    x12c-impdef-request@snad.ncsl.nist.gov

      The text of the message should only contain the following:

                            subscribe x12c-impdef

      Messages intended for the fed-reg list should be sent to:

                        x12c-impdef@snad.ncsl.nist.gov

      See section 7.7 for additional EDI related mailing lists.

7.2.  Are EDIFACT Standards available on the Internet ?

   You can access the EDIFACT standards via GOPHER from the
   International Telecommunications Union (gopher://info.itu.ch).  Here
   are the general directions in getting to the standards.

          1. Launch the gopher client as gopher info.itu.ch
          2. Select entry 11 (UN and international organizations)
          3. Select entry 1 (UN EDITRANS, UN/EDIFACT (EDICORE))
          4. Select entry 3 (UN-EDIFACT Standards Database (EDICORE))
          5. Select entry 1, Publications.

   If you want the actual standards, select 1, Drafts. You will get

           D93A (which becomes the standard S94a)
           D94A (which will be next year's standard).

   If you want the UNTDED, select 2.  If you want the UNTDID, select 3.
   When you get to the lowest level directory in which ever path you
   choose, press D (i.e.  upper case D) to download. Choose the protocol
   that suits and you are the proud owner of an EDIFACT Standards
   Directory.

   For electronic mail retrieval, send your message to itudoc@itu.ch
   with no subject and the following message body:

   START
   GET ITU-1900
   END

RFC 1865                 EDI Meets the Internet             January 1996

7.3.  The EDI X12 standards are quite complex.  How do we decide what
      X12 transactions to implement and how ?

   There are a number of generic implementation conventions (ICs) or
   guidelines; most ICs are prepared on an industry-by-industry basis.
   Be sure that both you and your current trading partners are working
   from the same set.  The Federal Electronic Commerce for Acquisition
   Program Management Office has been promoting the 3040 version
   throughout the government and the private sector.  Older versions may
   be used in accordance with the ASC X12 rules.  Certain ICs are
   published by the Data Interchange Standards Association (DISA);
   contact DISA at the address above for information about ICs for your
   applications.  Certain ICs as well as the X12 standards may be
   obtained through:

                   Washington Publishing Company
                   c/o EDI Support Services
                   P.O. Box 203
                   Chardon, OH 44024-0203

                   US Phone     (800) 334-4912
                   Non-US Phone (216) 974-7650
                   Fax          (216) 974-7655

7.4.  What Implementation Conventions (ICs) are available over the
      Internet ?

   The US. Federal Implementation Guidelines for Electronic Commerce for
   Acquisition are available for free via FTP at ds.internic.net.  These
   cover X12 transaction sets 810, 820, 824, 836, 838, 840, 843, 850,
   855, 864, and 997.  The path is pub/ecat.library/fed.ic/xxx where xxx
   can be acrobat.pdf, postscript or ascii file formats.

              ftp://ds.internic.net/pub/ecat.library/fed.ic/

   The SPEEDE/ExPRESS Project, funded by the National Center for
   Education Statistics of the U.S. Dept. of Ed., publishes an
   Implementation Guide for X12 transaction sets 130, 131, 146, 147, and
   997.  The July 1994 versions (each in WordPerfect and in Postscript)
   may be retrieved by anonymous FTP at admissions.carleton.ca.  The
   WordPerfect 5.1 files are found in /pub/wp_speede_2 while the
   Postscript files are found in /pub/ps_guide_2.

               ftp://admissions.carleton.ca/pub/wp_speede_2/
                ftp://admissions.carleton.ca/pub/psguide_2/

   Complete directions for retrieving these files can be found in the
   AACRAO gopher at AACRAO-DEC.NCHE.EDU.  Choose the SPEEDE/ ExPRESS

RFC 1865                 EDI Meets the Internet             January 1996

   menu item, then Publications, and then select a version of the
   Implementation Guide.  Note that guidelines are sometimes referred to
   by the release/version designation (currently 3040).

   The Defense Information Systems Agency (DISA) Center for Standards is
   the designated configuration manager for DoD Electronic
   Commerce/Electronic Data Interchange (EC/EDI) standards.  The DoD
   EC/EDI Standards repository system, available via anonymous FTP from
   ftp.sterling.com in the /edi/DoD-edi/ directory, contains DoD EDI ICs
   separated into two categories, User and Test.

                    ftp://ftp.sterling.com/edi/DoD-edi/

   Test conventions are identical to User, except that the condition
   designator for all applicable transaction sets, data segments and
   data elements used by that convention are designated as Mandatory for
   test purposes.  Implementation convention files, both user and test
   versions, can be downloaded either individually or all together in
   compressed self-extracting files.  All the implementation files are
   available, when decompressed, in both WordPerfect 5.1/5.2 (.WP) file
   format and Standard Exchange Format (SEF) test files which are for
   use with EDISIM software or any other EDI software that conforms with
   the EDISIM .SEF file format.

   The /DoD-edi/2003_User & _Test directories contain draft DoD
   Implementation Conventions based on ANSI X12 Version 2 Release 3
   (2003):

        840  Request for Quotation
        843  Response to Request for Quotation
        850  Purchase Order
        997  Functional Acknowledgement

   The /DoD-edi/3010_User & _Test directories contain draft DoD
   Implementation Conventions based on ANSI X12 Version 3 Release 1
   (3010):

        810  Invoice:
        810  Commercial
        810  Progress Payment
        810  Public Voucher
        840  Request for Quotation
        843  Response to Request for Quotation
        850  Purchase Order
        997  Functional Acknowledgement

   Additional 2003 and 3010 based conventions may be added in the near
   future.  3010 based conventions will never progress to approved

RFC 1865                 EDI Meets the Internet             January 1996

   status but will be used temporarily by various DoD agencies to
   implement phase I of the DoD Electronic Commerce (EC)/Electronic Data
   Interchange (EDI) in Contracting Report.

   The /DoD-edi/3050_User directory contains draft DoD Implementation
   Conventions based on ANSI X12 Version 3 Release 5 (3050):

        840  Request for Quotation
        843  Response to Request for Quotation
        850  Purchase Order
        855  Purchase Order Acknowledgement
        860  Purchase Order Change Request - Buyer Initiated
        865  Purchase Order Change Acknowledgement/Request - Seller
             Initiated

   Note that the ICs in the /DoD-edi/3050_USER directory were developed
   as a means to express DOD requirements for an ANSI X12 3050 based
   transaction set.  They are not approved for implementation.  They
   have been submitted to the Federal IC configuration management
   process for adoption throughout the federal government.  Since they
   are subject to Federal review and are based upon a standard not yet
   released, changes can be anticipated.  (See ECA PMO above)

7.5  How can a trading partner keep up with all these implementation
     conventions (ICs) and revisions in X12 and EDIFACT?

   The US government is trying to standardize electronic communications
   internally and with it's 300,000 plus suppliers.  This requires
   standardization of the standards process and cross communication
   between programs.  The IMPDEF message and the NIST Federal IC
   Registry will place electronic versions of all its ICs on the
   Registry - both full federal ICs and individual agency ICs - so that
   any trading partner can download and use them.  In combination with
   message data compliance checking as well, smaller firms should be
   able to get into EDI and start benefitting both themselves and the
   government.

7.6.  Where can I get information on EDI translation software ?

   Several commercial trade magazines publish periodic guides to EDI
   translation software.  Under commission by the US Government, the
   Logistics Management Institute (LMI) of McLean, Va. published "A
   Guide to EDI Translation Software, 1994 Edition."  The guide
   describes the features and characteristics of EDI software offered by
   more than 60 vendors.  Commercial organizations can get copies for
   $20 each by sending a check made out to the Logistics Management
   nstitute.  Federal agencies may have up to five free copies by
   sending requests to

RFC 1865                 EDI Meets the Internet             January 1996

                   Logistics Management Institute
                   Attn. Library
                   2000 Corporate Ridge
                   McLean, Virginia, 22102-7805

   You can fax a typed request to the LMI library at (703) 917-7597 or
   send a request to library@lmi.org.  Requests for hard copies of the
   Guide must include the requester's name, organization, address,
   telephone number, and number of copies desired.  All requests should
   cite Report IR421RD1.  If you have questions about the Guide, you can
   contact the author, Harold Frohman, at (703) 917-7286 or send him an
   Internet message at hfrohman@lmi.org.   A somewhat older LMI report
   (1992), but still quite relevant, is EDI Planning and Implementation
   Guide (DL204RD1, August 1992).

7.7.  How do I keep in touch with others pursuing EDI and Electronic
      Commerce on the Internet ?

   There are several EDI related mailing lists on (and off) the
   Internet.  Information on subscription follows below.

   ----------------------
   IETF-EDI Mailing list:
   ----------------------

      The IETF-EDI list has been established as a forum for discussing
      methods of operating EDI transactions over the Internet, and for
      discussing specifications which permit such operation.  This list
      is therefore focused on the technology of Internet usage of EDI,
      rather than on more general aspects of EDI technology or use.

      To subscribe, send an e-mail message to:

                             LISTSERV@BYU.EDU.

      The text of the message should only contain the following:

                           sub ietf-edi <your-name>

      Messages intended for the ietf-edi list should be sent to:

                              IETF-EDI@BYU.EDU.

RFC 1865                 EDI Meets the Internet             January 1996

   -------------------
   EDI-L Mailing list:
   -------------------

      The EDI-L list is target towards more general EDI discussions.
      The edi-l mailing list is also gatewayed to the USENET newsgroup
      bit.listserv.edi-l.

      To subscribe, send an e-mail message to:

                           listserv@uccvma.ucop.edu

      The text of the message should only contain the following:

                         subscribe edi-l <your-name>

      Messages intended for the edi-l list should be sent to:

                            EDI-l@uccvma.ucop.edu

   ---------------------
   EDI-NEW Mailing list:
   ---------------------

      This list complements ietf-edi in the sense that it promotes
      discussion of new approaches to edi and the extension of edi
      beyond its traditional domains.

      To subscribe, send an e-mail message to:

                      edi-new-request@tegsun.harvard.edu

      The text of the message should only contain the following:

                        subscribe edi-new <your-name>

      Messages intended for the edi-new list should be sent to:

                          edi-new@tegsun.harvard.edu

RFC 1865                 EDI Meets the Internet             January 1996

   ----------------------
   SPEEDE-L Mailing list:
   ----------------------

      The main purpose of this list is for discussions of Educational
      EDI Standards.

      To subscribe, send an e-mail message to:

                           listserv@vtvm1.cc.vt.edu

      The text of the message should only contain the following:

                    SUBSCRIBE SPEEDE-L firstname lastname

      Messages intended for the speede-l list should be sent to:

                           speede-l@vtvm1.cc.vt.edu

   ----------------------
   OPEN-EDI Mailing list:
   ----------------------

      The main purpose of this list is for UN/EDIFACT users to review
      the work of JTC1/SC30.

      To subscribe, send an e-mail message to:

                          majordomo@utu.premenos.com

      The text of the message should only contain the following:

                              subscribe open-edi

      Messages intended for the open-edi list should be sent to:

                          OPEN-EDI@utu.premenos.com

   ------------------
   ECAT Mailing list:
   ------------------

      The Federal Electronic Commerce for Acquisition Team (ECAT) has
      established an open mail list for those interested in ECAT
      activities.

RFC 1865                 EDI Meets the Internet             January 1996

      Information sent to the forum address is automatically distributed
      to all forum members. This forum is available 24 hours a day, 7
      days a week. Currently, only ASCII text messages up to 250kb are
      supported.  For best results when sending messages to this forum,
      each line should be limited 70 characters followed by a carriage
      return.  Also, your name and email address should be included in
      the body of messages sent.

      To subscribe, send an e-mail message to:

                           listserv@forums.fed.gov

      The text of the message should only contain the following:

                      subscribe ecat firstname lastname

      Messages intended for the ECAT list should be sent to:

                             ECAT@forums.fed.gov.

7.8.  Can I get messages that have been previously posted to the EDI
      mailing lists ?

   Yes.  Messages that have appeared on the ecat, edi-l, edi-new, fed-
   reg, x12c-impdef and ietf-edi list are available via FTP from

                     ftp://ftp.sterling.com/edi/lists/

7.9.  I have EDI related material I'd like to make available to the
      Internet community.  How do I do that ?

   If you have an existing Internet connected site, you can make the
   information available via FTP or WWW.  If you do not wish to go to
   the effort, send mail to Kent Landfield at

                         edi-archive@sterling.com

   Sterling Software is making the archive publicly available to the
   community.  Anyone who wants to distribute EDI related documents may
   contact Sterling to make your documents publicly available on
   ftp.sterling.com.  For example, the Department of Veterans Affairs
   has posted numerous studies and training materials on EDI which are
   available to the public at ftp.sterling.com/edi/va/.

7.10.  Where are EDI Archives on the Internet ?

   Some have been discussed previously while others have not.  Here is a
   very incomplete list of sites that archive EDI related material and

RFC 1865                 EDI Meets the Internet             January 1996

   make that information publicly available.

          o  ftp://admissions.carleton.ca/pub/
          o  ftp://ds.internic.net/ietf/edi/
          o  ftp://ds.internic.net/pub/ecat.library/
          o  ftp://ftp.sterling.com/edi/
          o  ftp://ftp.swin.edu.au/pub/edi/
          o  ftp://prospero.isi.edu/pub/papers/security/
          o  ftp://turiel.cs.mu.oz.au/pub/edi/

          o  http://snad.ncsl.nist.gov/dartg/edi/fededi.html
          o  http://waltz.ncsl.nist.gov/ECIF/ecif.html
          o  http://www.disa.org/
          o  http://www.acq.osd.mil/ec/
          o  http://www.ietf.cnri.reston.va.us/
          o  http://www.premenos.com/standards/EDIStandards.html

8. Security Considerations

8.1.  What security measures are needed to connect to the Internet ?

   Internet security measures can be placed in two broad categories:
   protecting your system from intruders and protecting the content and
   integrity of your messages.  With respect to the latter, EC/EDI
   transactions of nominal value and sensitivity do not require special
   security requirements.  However, if the information has any sensitive
   aspects, you will need to take measures discussed below.  Competitors
   might intercept your bids and undercut your proposal.  Or they could
   monitor your purchases and shipping notices to determine your firm's
   production capacity.  To ensure confidentiality of the message, your
   e-mail system should offer some means of encrypting the message in a
   manner only the intended recipient can read.  Trading partners are
   responsible for satisfying existing rules and regulations relating to
   computer security and privacy.  For example, bid data received by
   government systems is subject to the appropriate controls.  Trading
   partner financial account data is likewise subject to disclosure
   restrictions.  To thwart those who might tamper with a message to
   divert delivery by changing the "ship-to" address, digital signatures
   can attest to the integrity of the message.  Digital signatures can
   also authenticate messages, preventing pranksters or rivals from
   submitting false orders.

8.2.  How do we go about protecting our system ?

   The weakest link in most systems are people and passwords; your
   current practices for managing both will apply to use of the
   Internet.  Steps you can take include:

RFC 1865                 EDI Meets the Internet             January 1996

      o  Obtain, study, implement, and enforce the NIST FIPS (112) on
         passwords.  Make the practice of safe computing a condition of
         continued employment and let your staff know it.

      o  Conduct a risk assessment as described in Appendix M of the
         Federal Electronic Commerce for Acquisition Team report
         Streamlining Procurement Through Electronic Commerce.  This
         documents is available via ftp at ds.internic.net in the
         directory /pub/ecat.library.

      o  Apply the recommendations from NIST Special Publication 800-9,
         Good Security Practices for Electronic Commerce, Including
         Electronic Data Interchange as appropriate.

      o  Establish necessary internal and external "Firewalls."  See
         John Wack and Lisa Carnahan, "Keeping Your Site Comfortably
         Secure: An Introduction to Internet Firewalls," NIST Special
         Publication 800-10, undated.

      o  Review RFC 1281[4] Guidelines for the Secure Operation of
         the Internet and RFC 1244 Holbrook and Reynolds "Site Security
         Handbook"

      o  Review Cheswick and Bellovin's "Firewalls and Internet
         Security - Repelling the Wily Hacker," Addison-Wesley [5]

      o  Consider implementing active countermeasures in your firewalls.
         See "There Be Dragons" by S. Bellovin, Proceedings of the Third
         Usenix UNIX Security Symposium, September 1992[6].  You can
         contact Bellovin at smb@ulysses.att.com.

8.3.  Is there good publicly available software I can use?

   These are several free, publicly available, security tools one can
   obtain via ftp from one of many good archives.  If your company uses
   UNIX systems to connect to the Internet or has UNIX systems connected
   to the Internet get and use the following tools:

     1.  The Purdue University COAST - Security Archive (Computer
         Operations, Audit, and Security Tools, run by Gene Spafford)
         is located at coast.cs.purdue.edu and mirrored in a few places,
         including ftp.sterling.com.
     2.  COPS available from ftp.cert.org in /pub/tools
     3.  TIGER available from net.tamu.edu in pub/

   These tools are a series of scripts and programs that will alert you
   to many well-know problems and holes in UNIX systems and how to fix
   them.

RFC 1865                 EDI Meets the Internet             January 1996

   The Computer Emergency Response Team (CERT) at Carnegie Mellon
   University can assist with computer break-ins as well as provide
   notices of security activity on the Internet.  The US Department of
   Energy's Computer Incident Advisory Capability (CIAC), located at
   Lawrence Livermore National Laboratory, can provide assistance at
   ciac@llnl.gov or at 510-422-8193.  CIAC offers software and documents
   on their anonymous ftp server at ciac.llnl.gov.  Both CERT and CIAC
   are members of the Forum of Incident Response and Security Teams
   (FIRST), a global organization to foster cooperation and coordination
   among computer security teams worldwide.

8.4.  How good are electronic or digital signatures ? Can they be used
      in court ?

   Properly used, these signature systems are better than existing paper
   based authentication and forgery detection technology.  You will find
   a clear and concise description of how these signatures work in Gary
   Ratterree's RIPEM Beginner's Guide; contact Ratterree at
   grayr@cs.tamu.edu.   Other references include:

                ftp://ftp.tis.com/pub/PEM/    for Privacy Enhanced Mail
                ftp://ftp.rsa.com/            for PEM
                ftp net-dist.mit.edu:/pub/PGP for Pretty Good Privacy
                                              (PGP)

   An "infrastructure" for public keys is not required to use public key
   encryption or digital signatures. In the absence of such an
   infrastructure, the encryption protocol and the public keys would
   need to be exchanged bilaterally, such as part of the trading partner
   agreement.  A public key infrastructure would provide a secure means
   to obtain a public key without a need for a manual key exchange.

   But digital techniques will become more convenient with the arrival
   of additional infrastructure and support systems.  The US government
   is taking steps to ensure the admissibility in court of such systems.
   We anticipate that the necessary regulatory and legal infrastructure
   will be in place about the same time as the necessary directory and
   certificate services and other supporting systems come on-line.  We
   expect to see expansion of several government pilot programs in the
   later half of 1994.  NIST recently published a report on the Public
   Key Infrastructure (PKI) and related policy issues; for information
   contact the NIST Computer Security Division at 301-975-2934.

8.5.  Are there other US government standards publications I should
      be aware of?

   Yes.  Here is a sample of those you will often hear mentioned.

RFC 1865                 EDI Meets the Internet             January 1996

      1. Federal Information Processing Standard (FIPS) Publication
         46-1, Data Encryption Standard, January 1988.

      2. FIPS Publication 65, Guideline for Automated Data Processing
         Risk Analysis, August 1979.

      3. FIPS Publication 113, Computer Data Authentication, May 1985.

      4. FIPS Publication 180, Secure Hash Standard - (SHS), May 1993.

      5. FIPS Publication 186,  Digital Signature Standard - (DSS),
         May 1994.

      6. NIST Special Publication 800-9, Good Security Practices for
         Electronic Commerce Including Electronic Data Interchange,
         December 1993.

   The FIPS standards may be ordered from the

              U.S. Department of Commerce
              National Technical Information Service
              Springfield, VA 22161.

9. References

   [1] UN/EDIFACT (Electronic Data Interchange for Administration,
       Commerce and Transport) Syntax Rules (ISO 9735), March 1993,
       United Nations Economic Commission for Europe (UN/ECE), Working
       Party for the Facilitation of International Trade Procedures
       (WP.4)

   [2] FIPS Publication 161-1, Electronic Data Interchange (EDI),
       National Institute of Standards and Technology, April 1993.

   [3] The Internet Message: Closing the book with electronic mail,
       Marshal T. Rose., Prentice Hall, Englewood Cliffs, New Jersey,
       1993.

   [4] Pethia, R., Crocker, S., and B. Fraser, "Guidelines for the
       Secure Operation of the Internet", RFC 1281, Software
       Engineering Institute, Trusted Information Systems, Inc.,
       Software Engineering Institute, November 1991

   [5] Firewalls and Internet Security - Repelling the Wily Hacker,
       by Cheswick and Bellovin, Addison-Wesley, 1994,
       ISBN 0-201-63357-4

RFC 1865                 EDI Meets the Internet             January 1996

   [6] There Be Dragons, S. Bellovin, Proceedings of the Third
       Usenix UNIX Security Symposium, Baltimore, Maryland, September
       1992.  USENIX Association, ISBN 1-880446-46-4

10. Credits

   James A.(Artch) Griffin <artch@AGRIFFIN.CPCUG.ORG> is credited with
   co-authorship as he prepared the ECAT FAQ which I used (or perhaps
   abused) as the base document.  Artch was judicious and patient as he
   watched his original text being rewritten over and over.

   Carl Hage contributed detailed explanations and clarifications of the
   various Internet protocols and services and how EDI can employ them.

   I would like to thank the following people for their comments and
   specific contributions: Kent Landfield, Mike Bauer, Kit Lueder, Eric
   Christ, Betsy Bainbridge, Bob Lyons, Kirby Spencer, Sally Hambridge,
   Ed Levinson, Warren Smith, Steve Bass, Jerry Johnson, Randy
   VandenBrink, John Pillay, Jim W.C.  Smith, Mark Charles, Jean-
   Philippe Favreau.  I apologize if I omitted any one of the many folks
   who responded to my many calls for comments.

   I greatly appreciate Kent Landfield for his editorial assistance
   during final preparation of this document.  Sterling Software
   graciously hosted the work in progress for ftp access and review,
   saving many bits of Internet SMTP traffic.

   Finally, I am grateful for the patient cooperation of the IETF
   Working Group and the participants of the IETF-EDI and EDI-L lists.
   It's a nice cyberplace to work!

      WRH, Washington, DC.

RFC 1865                 EDI Meets the Internet             January 1996

11. Authors' Addresses

   Walter Houser
   Department of Veterans Affairs
   810 Vermont Avenue
   Washington DC, 20240

   Phone: 202-786-9572
   EMail: houser.walt@forum.va.gov
          houser@cpcug.org
   http://www.va.gov/

   James A. (Artch) Griffin
   President, Athena Associates
   18924 High Point Drive
   Gaithersburg, Maryland 20879

   Phone: 301-972-2502
   EMail: agriffin@cpcug.org

   Carl Hage
   C. Hage Associates
   1180 Reed Ave #51
   Sunnyvale, CA 94086

   EMail: carl@chage.com
   http://www.chage.com/chage/