I presented this paper at the ISO/IEC/ITU Strategies Cooperation Group workshop in Seattle, Washington, U.S.A., on 1 November 1995. It has been converted to HTML, but no attempt has been made to maintain the currency of its URL references.
The "SPA" in SPAsystem stands for "Standards Process Automation." Its goal is to be "an open, platform-independent system that uses available hardware and software to automate and streamline the standards development and dissemination process."
The system can currently be accessed via either the Internet or direct dial into a bank of 14.4-kilobaud modems. Popular network services such as ftp, gopher, World Wide Web, and e-mail are available. Portions of the system are public-access, available to anyone; other portions are private areas set aside for the use of working groups.
Access methods to the system are of several types: Some people access the system via anonymous public services, some have expanded access through a group identity, and a smaller number of people receive individual usernames and login privileges.
Aside from its function as a resource to facilitate standards development, the SPAsystem makes available a wide range of useful information: the publications catalog, frequently requested data and forms, staff contact and liaison information, bylaws, status reports, position papers, newsletter archives, tutorials, and errata sheets are all available on-line through the SPAsystem. A functioning Oracle database interface to the web, and a Macintosh 4-D relational database interface in the planning stage, allow information to be dynamically generated upon request.
These services are provided and maintained by a mix of systems that include Sun hardware (SPARCcenter 2000E, SPARCstation IPX, SPARCstation 10), along with various Macintosh and PC-type systems. A Hewlett-Packard server will be added soon. The operating systems involved include SunOS 4.1.3, Solaris 2.4, MacOS, MS-DOS/Windows, and, soon, HP/UX.
One of the goals of the SPAsystem is to allow its users the flexibility to work with the hardware and software configurations they individually prefer. Those users have levels of familiarity with common network tools that vary widely. Some prefer command-line methods, some graphical. Some have never used network services before, while others have been instrumental in designing the infrastructure upon which those services depend.
A BBS system has been on-line since the late 1980s, though it has been upgraded from the PC-XT and 2400-baud modem that provided the original service. Other services became active informally prior to 1 August 1995, which was the SPAsystem's official rollout date of first-level service.
The first step for a group wishing to use the SPAsystem formally is to fill out the Request for Services form, which is available electronically. The form introduces the available services to the user and also ensures that essential information is recorded in a standard manner. The form also allows the SPAsystem administrators to evaluate the expectations of the working group against the capabilities of the system, and prompts the group liaison to begin thinking about connectivity issues for individual members of the working group.
Some of the group liaisons are not particularly informed regarding network tools, SGML, or other elements they will normally encounter while using the system. The SPAsystem staff believe it is very useful to talk through the Request for Services form with such people, taking as much time as necessary to work through each line of the form, explaining concepts and options. The positive results expected include, in no particular order, 1) the form is filled out correctly, 2) potential problems are solved as far upstream as possible, 3) a human contact is made, 4) the system is better understood, and therefore more use is made of it.
Direct-dial access is provided by a bank of eight 14.4-kilobaud Intel and Hayes modems and a GatorAccess terminal server. The system's direct-dial capability is currently underused.
IEEE Standards staff members in the field are provided with SLIP and mail software, to allow them to dial in remotely and upload/download their mail. The administrators use the lines to check in from home.
The standards developers, however, make little use of the direct-dial lines. Internet connections are fairly simple to arrange nowadays, and the costs from such connections are generally less than those made through long-distance phone providers. For example, assume that $25/month pays for an account that allows 6 hours/day of connect time, at a 28.8-kilobaud transfer rate, to a local telephone number. Simple math shows a cost of 14 cents/hour, connecting to anywhere in the world with an Internet connection.
So using the Internet to connect to the SPAsystem is generally less expensive than using a direct-dial telephone connection.
E-mail is the first SPAsystem service that most developers want. The system offers several levels of service, depending on their needs. If they have an existing e-mail address elsewhere, an "@ieee.org" alias is set up to redirect their SPAsystem mail to that existing personal/company e-mail address. If the user has no e-mail access anywhere, they are provided with an individual user account on the SPAsystem, which they then have to access directly, usually through direct-dial, to receive their mail. On very rare occasions, outgoing mail-to-fax gateways have been set up.
Mailing lists -- or "e-mail reflectors" -- are central to working-group discussion. Much of the "give-and-take" takes place in such forums, and the mailing lists are a critical portion of SPAsystem services. Problem notifications are transmitted quickly and firmly by the users.
The SPAsystem currently has 66 mailing lists. Approximately 1 mailing list is added each week. The largest lists contain between 300 and 500 subscribers, the smallest between 3 and 5; the average size seems to be about 75 subscribers.
The lists are administrated with majordomo software, which handles the load satisfactorily. An unsatisfactory element of the e-mail service, however, is that the majordomo programs reside outside the SPAsystem, on MIS computers that administrate all the mail for the IEEE. SPAsystem staff do not have unlimited access to those machines, and, as a result, problems are not always addressed with the timeliness that might otherwise be possible. The Hewlett-Packard server, upon its setup, will be set up with majordomo and configured to allow SPAsystem staff to administrate SPAsystem mailing lists.
A spa@ieee.org e-mail alias exists to reply automatically with a prepared file that includes basic information about the SPAsystem, including contact information for staff members, in an attempt to more efficiently route queries to the staff.
Archiving of the mailing-list discussions is not currently provided, due to system limitations. The Hewlett-Packard machine, again, is slated to address this situation. At present, plans call for the use of hypermail to allow a web interface.
Working group members routinely use ftp to upload and download drafts of their documents among themselves. Some of those areas are accessible to the public via anonymous ftp. Private ftp areas are available to the working groups upon request. A working group's private area is password-protected and accessible only to the members of that working group and the SPAsystem administrators.
Direct upload of files into working group areas is not permitted. An uploads directory exists, with access permissions set to allow global write, but no read permission to the directory. The point of this setup is to discourage use of the SPAsystem ftp area as an illicit transfer point: even if an unapproved file is uploaded to the system, no user may connect to the system and download it.
When working group members upload files, then, they send the SPAsystem administrators an e-mail notification of the transfer, along with instructions for the file's placement within the working group's directory structure.
At present, approximately 65 megabytes of working group files reside in the ftp area. Approximately 1500 file transfers take place each month; that number is slowly growing.
A second common method of working group file access will be through password-protected areas on the web. Some working groups are beginning to examine this method now. An alternate access-control scheme allows access based on IP address.
A fundamental goal of the SPAsystem is to streamline the development process -- which spans from drafts to central data format, or SGML, all the way to finished products -- in whatever formats people want. The integration of working group materials into web-friendly format should not violate that precept.
Two common solutions are unpalatable. The first would be to allow the developers to work with the tools they prefer, but then to require that the files be exported into text-only -- or ASCII -- format. This scheme ignores the enriched display capabilities of the web and uses the browser only as a bloated gopher interface. Some of the readability is lost. Many writers rely on visual cues such as fonts, rather than on structured layout, to make elements clear. In exchange, nothing in particular has been gained.
The second unpalatable method would be to require the document authors to code their files into HTML before transmission to the SPAsystem. This procedure is labor-intensive. And aside from the cost to the developer, there are the issues of invalid or nonstandard HTML being submitted. Compatibility issues arise. Developers of web browsers commonly introduce product-specific "tag enhancements" at the same time. Netscape and Microsoft are prime examples of this. Tags developed by Netscape for Netscape browsers, for example, cannot be expected to display correctly on browsers by any other company.
There exists a standard subset of HTML that common browsers may be expected to display correctly. This subset is called HTML 2.0. (HTML 3.0 compliance is often proclaimed, usually by marketing departments. HTML 3.0 does not exist. At the time of this writing, the early IETF draft for HTML 3.0 had expired, HTML 2.0 had just been approved, and the proposals for issues commonly considered part of HTML 3.0 -- tables, math, and assorted extensions -- had not shown much convergence.)
The procedure within the SPAsystem, for converting files into HTML, attempts to address these quality issues while also streamlining the entire process.
If a working group wishes to display HTML material on the web, they are provided with an electronic style sheet for their favorite composition program. Using the style sheet's elements to construct their document, they then submit that completed document.
Within the SPAsystem, the document -- written with the style sheet as a template -- is processed with in-house tools. The output is a structured SGML file with all text elements identified and validated against the SPAsystem DTDs, and graphic images processed into standard file formats, with placeholders inserted into the text.
The downtranslation from known SGML into standard HTML, with graphic images in .gif or .jpg format, is technically trivial.
The benefits of this approach include the following:
The gopher server within the SPAsystem is being phased out. The decision to do so is based on a simple matter of resource allocation. The gopher seems to extend neither functionality nor ability to reach users beyond what other, equally-accessible services provide. The popularity of the web is well documented, and text-oriented users have text-oriented web browsers such as lynx.
Users may also access files via the BBS interface. The SPAsystem is predominantly UNIX-based, and the administrators prefer not to grant shell-level access, for many reasons. Therefore, when users need to log in directly, whether dialing in through the phone bank or telnetting over the Internet, they are usually placed in the BBS interface.
To be blunt, the administrators dislike the BBS interface, and feel it is clumsy both to use and to administrate. Usage levels show that the amount of time spent in its maintenance is greatly disproportionate to its actual use, but due to the BBS's importance as a lowest-common-denominator type of access, there are no plans to discontinue the service.
The SPAsystem logged 115 anonymous accesses to the BBS as "guest" for all of September 1995, and 9 registered users who logged in a total of 74 times between them. In contrast, the system logged 130,000 hits to the web site.
The web site seems to be successful. The SPAsystem has had a web presence for approximately two years. For most of that time, HTML documents were served to the public via a gopher server on port 70. However, with the emerging trend toward corporate security firewalls, which block many services and ports, a large number of users found themselves unable to connect to the SPAsystem. It became necessary to upgrade the software, service, and site design.
Access to the new, improved SPAsystem web site was opened on 1 August 1995. The system is running WN server software on a Sun SPARC IPX, and the site is expanding steadily. Plans are proceeding to migrate the server to the new SPARCcenter 2000E.
The web page designs make only moderate use of graphics. Many of the standards developers connect to the Internet via relatively slow serial links, and downloading large graphics under such conditions can be frustrating. Although many other sites make heavy use of imagemap design, the SPAsystem staff have chosen not to do so: People with slow links tend to turn off the graphics downloading feature on their browsers. If page design depends on a graphic image for coherency or functionality, these people have effectively been excluded. "Click here" buttons, for example, need to have alternate text renderings.
Pages should conform to the HTML 2.0 specification. Netscape-specific features are not allowed. Microsoft-specific features are not allowed. The SPAsystem staff does not wish to take a position that would effectively force the use of a particular commercial product to access the system.
A well-know problem on the web -- and with ftp and gopher services, also -- is that of aging or outdated information. A page or file of information written in early 1994 may not be relevant or correct in late 1995. To address this problem requires ongoing maintenance. The web is still very new, and small, when one considers what might exist a decade from now. The maintenance of that mass of information will be significant -- and if the maintenance is not forthcoming, the relevancy of the data will fade.
Dynamic generation of information pages from primary data sources is one approach to the solution of that problem. Accordingly, the SPAsystem staff is developing database access via the web site. A limited interface is available now. The standard Common Gateway Interface (CGI) format is used, and the process is quite straightforward.
Providing dynamically generated information is more work to set up than serving plain, static files, but the potential long-term benefit is significant. Other methods of automating the maintenance of web information involve the use of scripts and programs that can be written to automate many diverse tasks.
HTML code is also validated automatically within the SPAsystem. (It should be pointed out that the laxity of the current generation of browsers in resolving poorly written HTML is such that a certain "relaxed attitude" toward minor errors in older documents is possible.) The validation program weblint is widely available for a variety of platforms, as it is written in Perl. External validation services are also available. For logging and analysis, the SPAsystem staff mainly use in-house Perl and shell scripts.
As mentioned previously, the new IEEE SPAsystem web site was activated on 1 August 1995. It received 75,000 hits that month. In September, 130,000 hits were logged. There is no indication that the growth will stop, especially as new features and information are added and the site becomes a part of developers' reference libraries. It's just a click away.
Walter Pienciak
Systems Administrator, IEEE Standards Activities
w.pienciak@ieee.org
908-562-3805