Jump Over Left Menu
Issue 16: September 1991
- Project shoestring: pilot for a JANET IP Service
- JANET IP Service at the Atlas Centre
- Harwell Subroutine Library
- RAL-CGM Release 2.0
- The SGML Project
Project shoestring: pilot for a JANET IP Service
This article also appeared in the July 1991 edition of Network News.
An operational pilot (called Shoestring) for the planned JANET IP Service (JIPS) has been underway since March 1991. The aims of the pilot include:
- installation of the basic infrastructure necessary to run the JIPS;
- exploration of the performance issues that relate to the JIPS;
- development of the set of requirements on institutions wishing to connect to the JIPS, along with advice on how best to meet these requirements;
- gathering of operational experience of the policy framework set out by the (then) Computer Board in January 1991 when it asked that the JIPS be set up.
It is expected that the Shoestring pilot will continue until invitations to connect to JIPS are issued to institutions. At present it is still anticipated that this will be possible in October 1991. The rest of this article describes progress to date (mid July) in achieving the aims stated above.The pilot is being carried out as a co-operative venture between approximately fifteen institutions within the community, all of whom are providing expertise, effort and in some cases loans of equipment. The JNT is very grateful for the high level of commitment and enthusiasm shown by members of the pilot, without whom such rapid progress would not have been possible.
When launched, the JIPS will consist of a JANET-wide backbone of routers set up to carry IP traffic between connected sites. The technology used will be so-called "IP tunnelling" ie the use of JANET's X.25 service to encapsulate and deliver IP traffic. The backbone of routers is being established in the pilot by placing one router at each of the JANET NOCs (Network Operation Centres). These routers will constitute the management framework for the JIPS. When an institution connects to the JIPS it will be assigned a tunnel to the NOC router at the NOC that serves its normal X.25 connection to JANET.
The routers that have been chosen for this task are cisco AGS/3 devices. These have been purchased and installed for all NOCs (except Belfast where the router is now on order for installation before the start of the JIPS). The configuration and subsequent management of the backbone routers is being contracted to the London NOC (at ULCC). To date the pilot's backbone has consisted of Cisco routers placed at ULCC, RAL and EUCS (and loaned by the institutions involved in the latter two cases). Following successful configuration of the NOC routers, it is now scheduled that the permanent backbone will be established at the end of July.
The objective of the establishment of a backbone for JIPS is to allow central management of the service. This will comprise routing decisions (i.e. to make the best use of the underlying JANET X.25 service), statistics gathering, and (where necessary) the enforcement of access control policy. To achieve this the architecture being adopted for the connection of an institution to JIPS is that the institution will connect via a single router, placed at the end of the tunnel provided by the router at the NOC normally serving the institution. The institution's router will not be required to participate in the routing exchanges used by the backbone - it will be required only to pass all JIPS traffic to the nominated NOC router. (The institution will have to provide JIPS management with details of which IP networks exist on site, so that these can be made known to the backbone, but these will be loaded into static tables, not deduced dynamically.)
Shoestring Pilot Connectivity
A schematic diagram of the pilot network to date is shown in the accompanying figure. This shows the NOC sites, with those institutions connected as part of the pilot. (Apart from Bath and Belfast, all NOC sites are also participating institutions.) New pilot sites, that will connect immediately after the NOC backbone is established, are also shown. Note that the links shown between the NOCs are the X.25 links, not necessarily IP tunnels. In fact the NOC routers will be fully interconnected (ie each will have a tunnel to all the others) in the first instance. This should provide the most efficient IP path through the backbone, albeit at the expense of some tunnels being lightly used most of the time.
Access to the Internet abroad is accomplished via the London NOC. For access to the rest of Europe the route is via the use of the IXI network to the router established at NIKHEF in Amsterdam as part of the RIPE initiative. For access to the US and the rest of the world, the "fatpipe" to NSFNET is used. In order for institutions connected to the Shoestring pilot to be able to interwork with the Internet, it is necessary that they are registered with the appropriate RIPE and Internet authorities. The somewhat labyrinthine procedures for doing this have now been understood and successfully completed for the networks attached to the pilot. In future this should be a very straightforward process, completed as part of the JIPS connection procedure.
In order to make effective use of IP connectivity, it is necessary that an institution has access to the Domain Name Service (DNS). This is the basic name-to-address translation mechanism used in the IP environment, and may be roughly compared to the use of the NRS in the Coloured Books environment. However, unlike the NRS, it is implemented as a hierarchical system of communicating nameservers, each of which is responsible for both holding name-to-address translation information for systems in the domain it serves (so that other DNS nameservers may access this information) and for providing translation facilities for users of systems in its domain. (In fact a user may query any nameserver in the Internet to resolve a translation. Normally, however, it is more efficient and reliable to use a nameserver "close to home" ie on the same local network.) Use of the DNS will have to be coordinated on a national basis, with a DNS nameserver for the entire UK.AC community (or "ac.uk" in DNS ordering!) run as a central JIPS entity. This will be supplemented by DNS nameservers at each institution connected to the JIPS, each of which will be responsible for the maintenance of name and address information for systems within the institution.
Up to now there has been a relatively small need for centralised DNS facilities in the UK, and this task has been carried out on a semi-formal basis by UCL. With the inauguration of the JIPS, responsibility for this task on behalf of "ac.uk" will be taken over by the London NOC, although they will continue to work closely with UCL at the outset. Within the pilot, a number of institutions have now successfully configured their local DNS nameservers and connected them to the global DNS, allowing access to name-to-address translation throughout the Internet. The experience gained in doing this is being collated so that subscribers to the JIPS will have the benefit of practical advice and guidelines.
Within the pilot a number of tests have already been made to assess the likely performance of IP over JANET. Not surprisingly, this has proved to be a complex area, as the number of variables is high.
So far, tests have been made across the JANET 2 Mbps infrastructure, but with the routers connected at 1 Mbps. Throughput values of up to 800 Kbps at user level have been obtained with careful tuning, although it needs to be emphasised that these are obtained under near-ideal conditions. Moving to 2 Mbps has uncovered some low-level engineering bugs in the routers which are currently under investigation by the manufacturers. (The emergence of operational problems with network equipment when line speeds of 2 Mbps are used is not confined to routers - there have been problems reported with some X.25 switches as well. It appears that once again the JANET community is at the leading edge of technology, pushing suppliers' equipment to its limits, and helping them iron out the inevitable bugs that are only found when such systems are subjected to in-service use.)
From the limited information obtained so far, it is clear that current IP technology, in the end systems and in the routers, will be capable of placing a heavy load on the facilities of JANET Mark II. It is also clear that our links to the outside world, and to the rest of Europe in particular, will for the immediate future offer considerably less throughput than will be obtainable over JANET.
Requirements on Sites Wishing to Connect
Pilot experience is leading to an increasingly well-defined set of requirements that will be placed on institutions wishing to connect to the JIPS when announced. These will include the following.
- The institution will have to provide an IP router that will connect to its JANET CPSE and act as the single point of attachment from the institution to the JIPS. Normally the purchase of this router will be the responsibility of the institution. However the use of network installation funding to do this may in some cases be acceptable where such a purchase is part of the institution's overall networking strategy. (For example, where an institution is planning to install a router funded from network installation money as part of its networking strategy, it would be acceptable to fund from the same source an upgrade to this router so that it can connect to the JIPS.) Institutions that host NOCs will be allowed to connect direct to the NOC router, provided that they do so only to access the JIPS, and do not do so in order to perform local routing.
- The institution will have to run a managed DNS nameserver for the use of its IP systems. This will require a suitable host. (A Unix system is the most popular choice for this within the pilot, as the relevant software is available either from the supplier or from the public domain.) There will be the need to resource some effort to maintain the institution's nameserver.
- Before connection can be made, the institution will have to ensure that all IP networks on site that can access the JIPS have legal network numbers, ie numbers that have been properly registered with the Internet authorities. This is a very straightforward process, and one that can usefully be done in advance of applying to connect to the JIPS.
Because the JIPS backbone routers will handle all IP routing decisions on behalf of the institutions connected to the Service, it will not be necessary that the latter's routers have the full functionality of a backbone router. (In fact an institution's router will be required to forward all JIPS traffic direct to a designated backbone router, and will not take part in the exchange of routing information with the backbone routers.) This means that it will be possible to utilise a less functional unit than (for example) the cisco products. However, it should be borne in mind that management of routing is not the only consideration when making the decision. For example, some institutions may have a requirement to perform some access control at the JIPS connection point - for example, either to disallow outside access to certain services, or to prevent access to JIPS by certain classes of institution user. In such cases a more functional unit will also be required.
In the category of less functional routers, participants in the pilot have successfully used Netcomm's ECB and Sun's X.25 routing product (part of their Sunlink X.25 package) to connect to the backbone. It is planned that detailed advice will be available to institutions wishing to connect to the JIPS on the relative merits of these and possibly other routing devices as a means of connecting.
When the Computer Board laid out the policy framework for the JIPS, it did so on the basis of advice provided by the JNT to the Network Advisory Committee. This advice was in turn based upon recommendations made by the JNT's Advisory Group on IP protocol issues (the DoDAG).
As was explained at the Aberdeen Networkshop, the Computer Board decided that, in the interests of protecting existing connectivity, and of ensuring that its policy of a timely transition to OSI remained effective, not all possible protocols that can run over IP should be allowed to run over the JIPS. The Computer Board laid down three categories of service.
- Supported services, to comprise services over IP which would be fully supported by the JIPS. These were to comprise TELNET, ARPA-FTP and X-Windows.
Strongly discouraged services, to comprise services over IP which it was felt were not in the interest of the community
as a whole. These were to comprise the following:
- The use of SMTP to transfer mail, particularly internationally. Here there was considered to be a real danger of fragmenting the excellent level of connectivity enjoyed via the use of Grey Book mail.
- The use of NFS as a fileserving protocol. Here there were considered to be serious security and scalability problems which would make the system unworkable, coupled with worries over the possible adverse effect on traffic levels and hence on the rest of the service.
- The use of TCP/IP to carry OSI applications (rather than the ISO CONS). Here the concern was that effort should not be diverted from the established transition strategy, which involves the use of a CONS infrastructure to carry such applications.
- The use of TCP/IP to carry proprietary lower-layer protocols. Here it was considered that if this was necessary (and if agreement was obtained from the Head of the JNT to do so) that more efficient use of JANET's resources could be obtained by running these directly over X.25.
- Permitted services, to comprise any service that does not fall into one of the above categories. Such services would be allowed but were not to be given a guaranteed level of support within the JIPS.
One of the Shoestring pilot's remits was to study whether this policy framework was appropriate in practical use, and to make recommendations to the JNT accordingly. This process has started already, and interest has focused on the areas of limited use of NFS in the provision of access to read-only, public-domain software archives (where the security issues are not so relevant), and in allowing some use of SMTP (where a number of UK experts feel that there is added value to be gained in the use of SMTP). It is as yet too early to report on the results of this process, as it is necessary to gather operational experience before reaching a recommendation.
It has not been possible in this article to explain in any level of technical detail the reasoning behind the issues handled within the pilot. For those that are interested in further information there is a mailing list "janet-ip@jnt" on which are published the minutes of the regular pilot meetings. These minutes also catalogue the various papers generated by the pilot - most of these are available upon request to those interested. Approach the JIPS Service Manager (Bob Day, R.A.Day@uk.ac.jnt) in the first instance.
Equally importantly, users at sites participating in the pilot are encouraged to try out its facilities and provide feedback. If you are located at one of the sites contact your Computing Services to find out how access to the pilot is arranged at your site!
Bob Day, Joint Network Team
JANET IP Service at the Atlas Centre
Atlas Centre users who have read Bob Day's article on the progress of "Project Shoestring" may wonder how they will benefit from an IP service over JANET. Put simply, users at remote sites will be able to utilize a range of facilities which will enable them to make better use of the Atlas Centre's facilities.
The Cray Service
At present, users do not have direct access to the Cray; they have to use it via a "front-end". The use of IP changes all this and opens up a range of possibilities. IP is a communications protocol used extensively on local area networks and, having been around for a number of years, it has given rise to a wide variety of diverse applications which offer very good communications functionality. These include:
- Enables users to login to remote hosts.
- Usually referred to as simply FTP, this is a powerful interactive file transfer program; not to be confused with the non-interactive Blue Book FTP which readers are more likely to have previously encountered. ARPA-FTP allows users to examine remote file systems, create and delete directories, send and receive both text and binary files, together with a range of other facilities.
- X-Windows offers a window based graphical user interface for bitmapped displays, such as those found on workstations, and allows applications to create any number of windows containing both text or graphics on suitable graphical displays attached to the network. With such a facility, it would be possible, say, to run graphics applications such as UNIRAS on the Cray and display the results directly to windows on a workstation in another country.
By the end of the year, we hope to provide a new UNIX-based Cray front end to supplement the existing CMS and VMS services. A key function of this new front end will be to provide full TCP/IP support, including X-Windows, so that users can enjoy X-Windows services without placing the heavy load, associated with interactive usage, directly upon the Cray. It is for this reason that use of X-Windows directly on the Cray is not being encouraged.
With the arrival of the new front end and the advent of UNICOS 6.0, users can look forward to a range of new performance, programming and debugging tools for X-Windows to help to increase their productivity on the Cray. (See Nigel Jagger's article "UNICOS 6.0" in the previous issue for more information.)
The IBM Service
Remote IBM users will also benefit from the introduction of the JANET IP Service. Currently, some users only have line mode access to the IBM. Those who have experienced this will appreciate that it is far from an ideal means of interaction, as CMS was designed for full screen mode 3270 terminal access. IP access offers some relief to this situation.
- A variant of telnet, mentioned earlier, tn3270 allows remote logins whilst emulating a 3270 terminal. Some versions support graphics.
- This is an X-Windows version of the above but also provides the option of 3179 colour graphics support.
Both IBM and VMSFE users will also be able to use ARPA-FTP, in addition to the existing "Blue Book" FTP services, together with a wide range of applications designed to make working over a network easier and more functional.
For users based at "Shoestring" pilot sites, some of these facilities may already be available and they are welcome to try them. The full JANET IP Service, or "JIPS" for short, is scheduled to start in October, and, with the Cray Unix front end likely to arrive at a similar time, I would encourage users to ensure that their local computing centres register for connection to the JANET IP service at the earliest opportunity. Once sites are connected, suitably equipped and connected hosts, workstations and PCs will be able to communicate directly with machines both at RAL and around the world. Larger machines and workstations are likely to have existing connections to site Ethernets. Personal computers, however, will probably require some additional hardware and supporting software; talk to your local computing centre about what is required for your machine.
Paul Cahill Applications and User Support
Harwell Subroutine Library
A formal agreement has recently been concluded between Harwell and the Numerical Analysis Group at the Atlas Centre concerning the future development and marketing of the Harwell Subroutine Library. As you will recollect from earlier articles in Flagship, the Group moved from Harwell to Rutherford Appleton Laboratory just over a year ago, and while it was at Harwell one of its main responsibilities was for the Harwell Subroutine Library. Since then, the situation has been somewhat in limbo with Harwell continuing to market the codes and the intellectual property rights on current development work being in some doubt.
The agreement has resolved these issues and we believe also provides significant side-benefits for users of the main supercomputers at the Atlas Centre. The main points of the agreement are that the Harwell Subroutine Library will continue to be developed and supported by the Numerical Analysis Group and will be marketed by Harwell with revenues shared between SERC and Harwell. The Library will be updated on a regular basis, the current release being Release 10 as presently marketed by Harwell.
As part of the agreement, the Atlas Centre will have royalty free licences for the use of the Harwell Subroutine Library on both the IBM 3090/600 and the CRAY X-MP. Release 10, which is a significant upgrade on the version currently at the Atlas Centre, will be available shortly and details on how to access the codes will be broadcast on News on the IBM 3090. Documentation on the subroutines available and details of how to use them will be held by User Support.
In the first instance, enquiries about use should be directed to Jonathan Wheeler, Applications and User Support, Atlas Centre (US@UK.AC.RL.IB) although the Numerical Analysis Group will, of course, answer any detailed enquiries and are happy to consult on the use of HSL subroutines.
Users wishing to mount and use HSL on machines in their own University can obtain licences through Harwell (Elizabeth Thick, Bldg 424.4, Harwell) although arrangements are in place for royalty free licences for collaborative research work, for which enquiries should be addressed to the Numerical Analysis Group.
A routine for calculating the eigenvectors and eigenvalues of real unsymmetric matrices, EB12, will shortly be available. This routine is designed to be particularly useful for computing eigensystems of large sparse systems and only products of vectors by the matrix are required from the user. An appendix to a Rutherford report contains a detailed specification sheet on the use of this routine. Details of how to access this code will be given shortly in a IBM 3090 News message.
Duff, LS. and Scott, J.A. (1991). Computing selected eigenvalues of sparse unsymmetric matrices using subspace iteration. Report RAL-91-056, Rutherford Appleton Laboratory.
Iain Duff, Numerical Analysis Group
RAL-CGM Release 2.0
RAL-CGM release 2.0 is now available. The changes since the last release can be broken into two parts, first the changes to the main program (and the way it operates), and second, changes and updates to the individual output drivers. Along with the listed changes go bug fixes and performance improvements. These will be considered in the following sections.
The major improvement is the inclusion of several environment variables affecting the way in which RAL-CGM operates.
- A directory name to override the default data directory pathname (specified at installation time). Note that the name must include the trailing delimiter ('/' on Unix systems).
- CGMMENUFONT (X-Windows only)
- Override default font used by X-Window menus.
- A text string specifying the Output driver, see option '-D' in RAL-CGM manual page.
- A number indicating how many errors RAL-CGM allows before abandoning processing. Setting CGMERRCOUNT to 0 will allow any number of errors.
- A text string to set a default GDP type. See option '-G' in RAL-CGM manual page.
- Takes the value 'ON' or 'OFF'. 'ON' will turn verbose messages on. See option '-V in RAL-CGM manual page.
Disk Drive Architecture
This diagram was written as a CGM, output from RAL-CGM as encapsulated PostScript and originally included in a IBM DCF document which was sent to a PostScript printer. In order to be printed in FLAGSHIP the encapsulated PostScript file was converted to an IBM 4250 page segment.
A second group of environment variables is now available to change the output defaults for individual drivers. Currently available are CGMPSOPT, CGMVGAOPT, CGMXWOPT and CGMIGLOPT.
For the setting of these variables refer to the options available for the required driver.
The only major improvement to the X11 driver is the introduction of pixmap backing store for servers which are not capable of handling backing store themselves. This means that all exposure events are handled properly, even on simple window managers: i.e. if the window is covered and then uncovered, the picture will refresh correctly.
This driver has been quite dramatically improved. There is now full support of colour PS. (It should be noted that colour PS can not be sent to B/W PS devices - this is a PS deficiency!) The driver can now produce encapsulated PS (EPSF), this means that output from RAL-CGM can now be easily included into your PS documents. For users of the IBM, who are using PostScript output devices, (which are rapidly becoming popular within RAL) this provides a simple method of importing diagrams into DCF documents. The diagram in this article was written as a CGM, and then included in a recent CCD document in this manner. Also, it is now possible to turn on and off the picture border that the PS driver used to place around the output and to specify "Landscape" or "Portrait" orientation. All of these options are independent, and can be mixed at will. Indeed for encapsulating images into documents the normal form would be EPSF without the picture border.
The driver for the Silicon Graphics IRIS has been modified to allow random frame access, and now uses pop-up menus to control the display.
This is a completely new driver. It provides an output device for IBM PC compatibles, with VGA style graphics. The driver is complete and responds to all the standard CGM elements, with the exception of user defined patterns. The driver will compile with Microsoft C only.
The only significant change to the system code is for the VAX. The input/output format for binary CGMs has been changed so that RAL-CGM will read and write files that are interchangeable with most other common packages (e.g. UNIRAS), on the VAX.
RAL-CGM has proved to be a very popular package, with over a hundred requests for it, ranging from people in Informatics Department at RAL, to someone from the University of New Orleans in America!
RAL-CGM has found many uses within the Central Computing Department, too. Large amounts of video footage have been made from CGMs, some of which have even arrived as part of an ordinary mail message! It has even been shown that in some cases it is as easy to draw a diagram by typing it in as a clear text CGM as it is to use a design package; the diagram included with this article was prepared in this way.
The source code is still available through the Kent University software distribution scheme, but now there is a second way of getting software from Kent, that is via NIFTP.
The PC version of the code will be available in an executable format from Lancaster pdsoft, however the details of this are not yet available. RAL-CGM is being distributed by the following routes:
- UNIX Systems
- via the Netlib software distribution system at the University of Kent, as detailed below;
- VAX/VMS Systems
- from RAL as detailed below;
- IBM VM/CMS Systems
- from RAL by contacting Roy Platon
- IBM PC and Compatibles
- from pdsoft system at the University of Lancaster. We are awaiting details of this distribution method, and will update you in a future FLAGSHIP.
Obtaining a copy for UNIX systems
RAL-CGM for UNIX can be obtained either on a tape or over the network. The end result of all methods is to have a tarfile, which we will discuss further on.
There are three ways to get your tarfile, two over the network, or you can get it on a tape.
- RAL-CGM via NETLIB over the network
- Send to firstname.lastname@example.org a mail message whose body contains a single line:
send encoded.tar from ralcgmYou should receive a number of big files and a single small file which contains a script and instructions to glue the separate files back into a large file (the size of which will be around 1.7 Mb). Name this, say, tarfile, then
uudecode tarfileshould produce a file called tarfile.z. (Warning: some UNIX systems may not have the uudecode command. It is hoped, however, that every installation will have at least one machine - Sun for instance - that does. Failing this get the tarfile on a QIC tape, see below).
zcat tarfile.z > ralcgm.taror
uncompress tarfile.z mv tarfile ralcgm.tarwill generate the original tar file, of about 3.8Mb, (the the former will leave tarfile.z on your filestore, the latter will not). To deal with this tarfile, see the following section.
- RAL-CGM via NIFTP
- Unfortunately at the current time this distribution method is untested. An update on this will be issued in a future FLAGSHIP.
- RAL-CGM on a QIC Tape
- To obtain RAL-CGM on a tape, send a QIC24 tape (any length is long enough) to: Tim Hopkins, Computing Laboratory, University of Kent The tarfile which you require is on this tape, see following section for how to unpack this.
How to Unpack the tarfile
- Create a directory with a suitable name, for instance "ralcgm".
- If you have the tarfile already on your machine, copy the ralcgm tarfile to that directory.
- cd to that directory.
- If you have the tarfile, issue the following command:
tar -xvof ralcgm.taror, if the tarfile is on tape:
tar -xvof /dev/rstO
NOTE: The device name (rstO in the above) is system dependent.
This will create the correct directory structure. The top directory will contain a file called README which gives instructions on how to complete the installation.
Obtaining a copy for VAX/VMS systems
RAL-CGM for VAX/VMS can be obtained over the network with the following VAX command:
$TRANSFER/CODE=FAST - UK.AC.RL.VE::RALCGM1.BCK - RALCGM1.BCK RALCGM DISTRIBUTION
This will fetch a copy of the VAX/VMS saveset, about 4 Mbytes, called RALCGMl.BCK from a VAX at Rutherford.
To install RAL-CGM from the saveset:
- create a directory with a suitable name such as RALCGM;
- copy the RALCGMl.BCK file to that directory;
- set default into the directory;
- issue the following command:
$BACKUP/LOG RALCGM1.BCK/SAVE/ - SELECT=[RALCGM...]*.* [...]This will unravel the saveset into the correct directory structure. The top directory will contain a file called README which gives instructions on how to complete the installation.
RAL-CGM version 2 uses the UNIX/C language command line interface so options are preceded with a minus sign, rather than in the normal VAX /option form. See the help library for more details of the options and the format to use.
Chris Seelig Graphics Group
The SGML Project
This is a two year project funded by the Computer Board and based at the University of Exeter's Computer Unit. The overall aim of the Project is to explore and encourage the use of the Standard Generalized Markup Language (SGML) within the Universities and Research Council establishments of the United Kingdom.
Anyone interested in text processing will need to know about SGML and what it can do for them - whether their background is in Computing, the Arts, Social Sciences or pure Science. As well as being an internationally recognized ISO standard, it is being laid as the foundation stone of document manipulation in a wide range of environments - from the offices of the European Community to HMSO and the American Department of Defense, from IBM to Boeing and Fujitsu. Many publishers are investing in SGML-based products to accelerate the production process, and provide them with new ways to access and present their authors' works. SGML can also be used to simplify document interchange, facilitate the multiple-authoring of papers, and form a basis for developing hypertext and hypermedia systems.
In more detail, the aims of the Project are:
- to investigate commercial products and review them for possible use in UK academia;
- to investigate existing use of SGML within and without academia;
- to assess possible requirements for SGML systems in academia, by making contacts at all interested establishments;
- to investigate the required utilities (eg editors, translators, formatters), and make recommendations concerning possible acquisition;
- to define (in consultation with users) a vocabulary of element and entity names and develop general Document Type Definitions (DTDs);
- to maintain a public library of DTDs, relevant reports and documentation, (where possible, also allowing prospective purchasers to try available products over the network);
- to be a centre for information on SGML use - liaising with other Projects as appropriate;
- to increase awareness of SGML (eg by posting to bulletin boards and newsletters, disseminating ISO Standards, offering seminars, training courses, training materials etc).
The Project is committed to making all its findings widely available in the form of regular on-line and paper reports. We shall be writing to the management of the computing services at every academic and Research Council establishment in order to build up a mailing list of contact names. However, we are also interested in liaison with staff from any department who believe they may have a use for SGML.