1 REM Ins{nd av Bo Kullmar SYSOP <1789> 1987-08-30 11.49.25 (KERMIT) \verf|rt fr}n COM/Oden: (256298) 87-06-09 00.59 @BITNIC: SCOTT (Scott Earley) (flera mottagare) Subject: X.400 paper from Queen's College ------------------------------------------------------------ %Original date: Mon, 08 Jun 87 17:31:56 EDT %TF: E52675.MAI %FROM: Scott Earley %Sender: BITNIC X400-L List 591 Read file DSKA:E52675.Y00<62,120,FREARN> Filens storlek {r ungef{r 28115 tecken. I got this from Bob Cavanaugh several months ago. It offers a broad scope of current work in the X.400 area. I've just begun to monitor this list, my apologies if this is old news to all. --Scott PS: the only version I have has carriage control. --------------- X.400 - Bringing It All Together ABSTRACT The growing number of electronic messaging networks have of- fered our clients a wealth of opportunities for increased scholarly communications and joint research with colleagues in distant locations. However the lack of standardization in messaging approaches used by various networks and elec- tronic messaging systems has made it difficult and sometimes impossible to offer a coherent and consistent human inter- face to these valuable facilities. This has inhibited more extensive use of these services by many of our less- technical clients. This paper describes, in layman's terms, the basic features of the CCITT X.400 suite of electronic messaging standards with emphasis on aspects which will substantially benefit our clients. Some views on the stages of implementation of X.400 messaging systems are presented along with examples of capabilities which will be available at each stage. Possible future extensions of the X.400 standards to handle additional needs of our clients are also discussed. The presentation concludes with an overview of QK-MHS/VM, an implementation of the X.400 standard for VM/SP under continuing development at Queen's. The goals of the project are outlined, current status reviewed, and future plans discussed. X.400 - BRINGING IT ALL TOGETHER X.400 - BRINGING IT ALL TOGETHER X.400 - BRINGING IT ALL TOGETHER X.400 - BRINGING IT ALL TOGETHER ________________________________ INTRODUCTION INTRODUCTION INTRODUCTION INTRODUCTION ____________ Most of us who work with computers daily have been using electronic messaging internally within our own organizations for many years. At Queen's, and I'm sure at most other institutions, we have found that as more and more of the people with whom we communicate come "on line", electronic messaging can substantially change the way we work. It truly is a new communications medium which has been ably de- scribed by many others. Over the past few years, the usefulness of electronic messaging in the academic environ- ment has increased dramatically as a result of: the rapid growth in terminal and communicating microcom- puter population, campus networks linking both central and departmental computing systems, each with their own messaging facil- ities, NetNorth with its links to BITNET and EARN connecting our institutions to hundreds of others in Canada, USA, Europe, Asia and the Middle East, gateways linking campus networks, NetNorth, BITNET, and EARN to other education and research networks spanning most of the free world, sharply growing use of commercial electronic messaging systems such as ENVOY 100, and the availability of electronic conferencing systems, such as the University of Guelph's CoSy system. The result of the above developments has been an extensive, but complicated, communications capability supporting the educator, researcher, and administrator in our institutions. Conference Proceedings, Computer Conferencing and Elec- _______________________________ tronic Messaging, University of Guelph, January 22-23, ________________ 1985. X.400 - Bringing it all together 1 WHY DO WE NEED TO BRING IT ALL TOGETHER? WHY DO WE NEED TO BRING IT ALL TOGETHER? WHY DO WE NEED TO BRING IT ALL TOGETHER? WHY DO WE NEED TO BRING IT ALL TOGETHER? ________________________________________ The haphazard growth of academic computing networks and gateways between these networks has, in most cases, outrun the facilities available in the software systems we have used to provide access to these networks. Most of us have attempted to use electronic messaging facil- ities provided by the operating system vendor on the host system to which we have access. These facilities usually have one or more of the following limitations: the message format is proprietary and does not conform to any international standard or even a de facto stand- ard, electronic address support is very system-dependent, no support for "intermediaries" such as network gateway servers, and no support for institutional directories blocking the use of people-oriented addressing. Although local modification of vendor-provided facilities can overcome many of these deficiencies, it is usually in- advisable because: modifications are costly to maintain as operating system environments are continually being upgraded, the basic design of vendor-supplied messaging facilities often makes the necessary functions difficult to in- clude, and some systems are provided without source code making modifications either very risky, very difficult, or even impossible. If all the above did was make life difficult for those of us who provide these electronic messaging systems to our users, provide provide provide we could cope. However, in most cases these problems are painfully obvious to our clients, unduly complicating their use of electronic messaging or even blocking access to col- leagues with whom they wish to communicate. Some institutions have written their own messaging sys- tems, either because of unavailability or limitations of vendor systems. X.400 - Bringing it all together 2 At Queen's, we have had a relatively homogeneous internal electronic mail environment with a very large VM/CMS central system connected to departmental VAXen using JNET and UREP. Our standard messaging system on VM/CMS, IBM's Professional Office System (PROFS), gave our clients the ability to communicate with anyone on the VM/CMS system or the depart- mental systems. With the introduction of NetNorth and subse- quently BITNET and EARN, PROFS continued to serve our clients well with the exception of a growing number of non-IBM systems where user identifiers could exceed 8 char- acters. However, with the introduction of the ARPA gate- way and gateways to other networks, the limitations in our electronic messaging environment became acute. We created alternate facilities to PROFS to provide gateway access but this required people to move to a very different electronic messaging environment, a difficult change for some of our non-technical clients. An increasing number of our staff were beginning to use EN- VOY 100 as well as our internal electronic messaging systems which required them to sign on to multiple systems every day. Others had discovered electronic conferencing systems, again requiring them to sign on regularly to yet another system. For some of our clients, the "multiple mailbox" problem was an inconvenience. For others, the differing procedures on each system were too confusing, leading to their withdrawal from some or all electronic messaging. Clearly, we had to do better. A PROPOSAL FOR CHANGE A PROPOSAL FOR CHANGE A PROPOSAL FOR CHANGE A PROPOSAL FOR CHANGE _____________________ The possible solutions to our problems were obvious. Either we had to build additional functions into PROFS or create another full-function electronic messaging environment. In fact, we decided to do both by designing an external, release-independent interface between PROFS and a totally new messaging environment. Once the decision had been made to build a new messaging system, a number of other technical decisions had to be made. One of the first was a decision on a common elec- tronic messaging format. We rejected a number of alter- natives due to their restrictive nature leaving only two Although a large number of systems now exist on NetNorth/BITNET/EARN which can handle user identifiers longer than the RSCS limit of 8 characters, in reality, few users seem to select identifiers in excess of the RSCS limit. X.400 - Bringing it all together 3 real possibilities: the ARPA RFC821/RFC822 format or the newly accepted X.400 Message Handling Systems standards. The choice seemed obvious to us. For a common mail format to be effective for our needs, it must be the "highest com- mon denominator" of all the messaging capabilities that we might anticipate requiring. At this point in time, the X.400 standards provide the richest environment. Once cap- tured in X.400 format, an electronic message can be con- verted to any other known format without ambiguity. This is an exceedingly important capability since we have no expec- tation that a homogeneous electronic messaging environment will evolve in the near future. Other features in the X.400 standard quickly convinced us that a full X.400 implementation would provide the best function for our new electronic messaging environment. Building on a strong base such as X.400 gives us hope of a long lifetime for the investment in development time as well as the chance that commercial software might become avail- able in the future as a viable alternative to continuing our own development and maintenance. WHAT IS X.400? WHAT IS X.400? WHAT IS X.400? WHAT IS X.400? ______________ X.400 is a suite of standards developed under the auspices of the CCITT with the strong likelihood that they will also be adopted by the International Standards Organization. These standards follow the Open Systems Interconnect (OSI) 7 layer reference model, primarily within the Application layer (layer 7). As with all OSI standards, X.400 is in- tended to be vendor and architecture independent, facilitat- ing the exchange of messages between dissimilar systems. Eight standards in the range X.400 to X.430 have been ac- cepted, but since the X.400 standard outlines the basic services detailed by the rest, I will refer to the entire suite as X.400. The Consultative Committee on International Telephony and Telegraphy (CCITT) is an international organization supported by telecommunications suppliers and regulators which establishes standards for international telecommu- nications. The eight standards are: X.400 System Model - Service Elements X.400 - Bringing it all together 4 One of the most attractive features of X.400 is the rigorous separation of the "envelope" and the "contents". Analogous to physical mail, the electronic envelope is examined by electronic letter sorters, known as Message Transfer Agents (MTA), which route the item to its ultimate destination. The envelope contents is simply a bit-stream; only the end- nodes need to be able to interpret the contents. As a re- sult, anything that can be coded as a binary bit-stream can be sent as an X.400 message. Once a message reaches its destination MTA, the contents are passed to a User Agent (UA), the part of the messaging sys- tem which interprets the contents of an X.400 message and presents it to the client. One type of envelope contents was defined by X.400, Interpersonal Messaging (IPM). Simi- lar to our current text messaging concepts, IPM also allows for imbedded facsimile and digitized voice. An IP-Message may consist of a number of body parts kept logically sepa- rate within the envelope. A body part may be a collection of other body parts such as a forwarded message. The sepa- ration of body parts allows a system which is incapable of handling an element such as digitized voice to at least dis- play the text portions of the message, while acknowledging the presence of other parts that it could not handle. Multiple body parts also allow for simple programmatic manipulation of the individual parts. For example, an elec- tronic message might include a report plus a second body part with comments attached by the sender. The receiver could choose to forward on the report minus the comments without having to revert to editing out the comments as would be the case in most systems today. Most of our current electronic messaging systems use a cryptic and inflexible addressing scheme based upon a client identifier or mailbox, a host system code, and perhaps one or more domain names. X.400 specifies a flexible addressing structure which will be supplemented with proposed directory standards now being drafted. Although this address struc- ture may specify an "electronic ID", most implementations are using a more natural form based upon client name, organization, electronic messaging domain(s), and the ISO two character country code. For example, my X.400-style ad- dress could be X.401 Basic Service Elements and Optional User Facil- ities X.408 Encoded Information Type Conversion Rules X.409 Presentation Transfer Syntax and Notation X.410 Remote Operations and Reliable Transfer Server X.411 Message Transfer Layer X.420 Interpersonal Messaging User Agent Layer X.430 Access Protocol for Teletex Terminals X.400 - Bringing it all together 5 Bob Cavanagh/Queen's,Computing Services/NetNorth,ENVOY,CA Two types of domain have been defined. An Administrative Message Domain (ADMD) represents a public carrier's service such as ENVOY 100 for Telecom Canada. A Private Message Do- main (PRMD) represents a private organization or a consor- tium such as NetNorth. The standard assumes that Administrative Messaging Domains will interconnect Private Message Domains. While this will almost certainly be the case in Europe where the PTT administrations fully control communications, it is not yet clear how this will develop in North America. Regulatory decisions on this issue will have considerable effect on the makeup (and cost) of academic networks. HOW CAN IT HELP? HOW CAN IT HELP? HOW CAN IT HELP? HOW CAN IT HELP? ________________ While it will be many years before use of the X.400 stand- ards become universal, their presence will be felt in a num- ber of ways. In the near term, X.400 will almost certainly become the common denominator for mail conversion in many systems. Commercial electronic messaging services, such as Telecom Canada's ENVOY 100, are adopting X.400 at least as a gateway to their systems, offering an opportunity for private organizations to send and receive ENVOY mail through their own internal mail systems. Later, as more systems develop X.400 gateway capability, "single access" messaging will allow our clients to commu- nicate electronically with a much larger selection of corre- spondents than is now possible. More capable User Agents will become available to utilize the voice annotation and facsimile features of the standard. X.400 addressing with directory support will become widely used to eliminate the need to know an electronic identifier for an individual. Along with these full X.400 implementations on multi-user systems should come personal workstation User Agents, adding even more flexibility to our messaging environment. Postal, Telephone and Telegraph X.400 is in the mail, Computerworld, April 21, 1986, p. _____________________ 31 X.400 - Bringing it all together 6 Although explicitly designed to utilize OSI protocols for transport of messages, the X.400 standards may also be used with other transport mechanisms such as RSCS protocols used on NetNorth. Such alternate transport mechanisms may be used both as a "bridge" into X.400 and as a long-term cost- saving approach by using existing networks to transport X.400 messages. In the long term, the X.400 standards will almost certainly be extended. Some of the expected features of these exten- sions include support for distributed conferencing systems (probably in the form of a distribution agent) and support for program to program communication where a "virtual cir- cuit" connection is not required or not possible. QK-MHS/VM - MORE THAN JUST X.400 QK-MHS/VM - MORE THAN JUST X.400 QK-MHS/VM - MORE THAN JUST X.400 QK-MHS/VM - MORE THAN JUST X.400 ________________________________ Over the past year and a half, Queen's has been developing an X.400 implementation for the IBM VM/SP operating system, which has been named QK-MHS/VM. As well as an imple- mentation of the X.400 standards, QK-MHS/VM was designed to provide a gateway to other electronic messaging systems and to utilize non-OSI transport mechanisms when appropriate. Features of QK-MHS/VM include: a Message Transfer Agent running under the standard VM/SP system, a User Agent integrating the handling of all X.400 mes- sages and VM/SP reader files, a gateway service machine giving PROFS users the ability to send and receive X.400 messages, addressing support compatible with CDNnet (Canadian re- search network), DFN (German Research Network), and ENVOY/MHS, message queues maintained on disk, independent of the VM spooling system, and message transport (MTA to MTA) currently supported using the Remote Spooling Communications Subsystem (RSCS) and an OSI implementation based upon software developed by IBM labs in Toronto and Heidelberg, West Germany. In the near future, a gateway to the Columbia MAILER will provide access to non-X.400 messaging systems on NetNorth/BITNET/EARN as well as gateways attached to these X.400 - Bringing it all together 7 systems. An enhancement to the PROFS gateway will allow us- ers of CMS NOTE access to X.400 facilities. The initial part of the system was developed as a deliv- erable under Queen's Corporate and Scientific Program agree- ment with IBM Canada and is available, for the cost of distribution, to other VM/SP sites. QK-MHS/VM is written largely in PASCAL/VS and is distributed with full source code. QK-MHS/VM is being used by IBM's European Networking Centre (ENC) to provide the X.400 portion of their VM/SP support for DFN. This system, dubbed PROFS400, was demonstrated at the Hannover Fair, CeBIT 86 in March of this year . X.400 messages were exchanged between systems of a number of manufacturers, most of whom were running EAN, the X.400 mes- saging system developed at the University of British Columbia. Session and Transport support was provided by software developed at the European Networking Centre or by other organizations under contract to the ENC. X.25 support was provided through an IBM Series/1 minicomputer running the RPS operating system and an IBM Program Product devel- oped at IBM's Toronto Laboratory. The Session and Transport software has been acquired by Queen's as a result of the joint work with the ENC. As a result, this software will also be available under the same terms as QK-MHS/VM. QK-MHS/VM is running at a number of sites in a test mode. At Queen's, we have not yet put it into production pending availability of gateway support to the Columbia MAILER and NetNorth/BITNET/EARN gateways. We expect to be running it in a full production mode before September of this year. QK-MHS/VM: PLANS FOR THE FUTURE QK-MHS/VM: PLANS FOR THE FUTURE QK-MHS/VM: PLANS FOR THE FUTURE QK-MHS/VM: PLANS FOR THE FUTURE _______________________________ Although message transport via OSI mechanisms may now be demonstrated, the approach taken by the ENC has some limita- tions. The Session and Transport software were developed as a research project and were not created as production soft- ware. As a result, a significant rewrite of these functions IBM shows X.400 links at Cebit, Computerworld, March 24, ______________________________ 1986, p. 12 X.400 Messe-Mail CeBIT 86, Technical Report Number 8602, _________________________ IBM Deutschland GmbH, Europaishes Zentrum Fur Netzwerkforshung, Tiergartenstr. 15, D-6900 Heidelberg, West Germany. (in German) X.400 - Bringing it all together 8 will be required. In addition, the ENC is finding that most customers would prefer to have X.25 support provided by an IBM 37X5 communications controller rather than the Series/1 approach. As a result, Queen's is currently looking into 37X5-based X.25 support and will likely embark on a major rewrite of the Session and Transport software. Production quality OSI support is essential to providing full access to ENVOY/MHS when it becomes available late in 1986 or early 1987. The User Agent in QK-MHS/VM currently provides only basic features. Enhancement of this User Agent is necessary to bring it up to the level of functionality that is normal in most electronic messaging software. A PC User Agent should also be developed to give personal workstation users access to electronic messaging without requiring mainframe logon capability. Although QK-MHS/VM now contains a rudimentary directory facility, this should be greatly expanded into a full insti- tutional directory containing physical and electronic deliv- ery information about all members of the institution, including students. Such a directory will enable the cor- rect routing of messages from the primary institutional MTA to central computing systems, departmental systems, personal workstations, or even to Post Office printers for those who have no access to electronic facilities. Clearly, an institution like Queen's cannot handle a project like this alone. Our strategy has been to make QK-MHS/VM available, complete with source code, as early in the development cycle as possible with the hope that other institutions would see value in participating in the development. We are encouraging interested parties to take on portions of the development, returning the results of their efforts to us for integration with the base system or inclusion in a "contributions" portion of the distribution tape. (256298)------------------------------ (256472) 87-06-09 19.59 /14 rader/ @QUEENS.NETNORTH.CA: Andrew.S.Hooper (flera mottagare) Subject: Queen's College/Queen's University ------------------------------------------------------------ %Original date: Tue, 9 Jun 87 12:48-0400 %TF: E24714.MAI %FROM: Andrew.S.Hooper@QUEENS.NETNORTH.CA %Sender: BITNIC X400-L List Please note that the paper is from Queen's UNIVERSITY, not Queen's College. The latter is in Brooklyn, the former in Kingston, Ontario, Canada. For completeness, there is another Queen's University in Belfast, and several other cities called Kingston. Maybe monarchs think they are unique :-) Andy Hooper 613-545-2019 Computing and Communications Services Queen's University, Kingston, Ontario (256472)------------------------------