Internet DRAFT - draft-ietf-disi-x500-survey
draft-ietf-disi-x500-survey
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 01:57:36 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 09 Dec 1992 04:39:00 GMT
ETag: "3dddb1-7734-2b257864"
Accept-Ranges: bytes
Content-Length: 30516
Connection: close
Content-Type: text/plain
IETF DISI Working Group Chris Weider
INTERNET--DRAFT Merit Network, Inc
Russ Wright
Lawrence Berkeley Laboratory
Elizabeth Feinler
NASA
October 1992
A Survey of Advanced Usages of X.500
Status of this Memo
The authors are interested in documenting current advanced usages of X.500,
particularly ones which go beyond the standard 'white pages' paradigm.
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other than
as a "working draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any
other Internet Draft.
This Internet Draft expires April 7, 1993.
Abstract
This document is the result of a survey asking people to detail their
advanced usages of X.500. It is intended to show how various organizations
are using X.500 in ways which extend the view of X.500 as a 'White Pages'
service.
1. Introduction
As the use of X.500 spreads in the Internet, organizations are finding
uses for it which go beyond the 'white pages' paradigm which has been used
to introduce it to new users. Consequently, to document those new uses and
to encourage the wider use of X.500, we sent out a survey to obtain 'advanced
usages' of X.500.
1.1 The survey
The survey we sent out is included here for two purposes: 1) completeness, and
2) we'd like to encourage anyone who retrieves this document to send us their
advanced usage for inclusion in the next revision.
If you wish to fill this out, please send it to the working group list
disi@merit.edu.
_______________________________________________________________________________
Application Name:
Author(s):
Company or Institution:
e-mail address for more information:
If this is a product for public distribution, please give us the
Type: FREE, COMMERCIAL PRODUCT, or PROTOTYPE/RESEARCH
FREE - Anyone may obtain this product at zero cost.
COMMERCIAL PRODUCT - One may purchase this product.
PROTOTYPE/RESEARCH - This product is not yet available, only a prototype.
If FREE, please give us:
* FTP and/or FTAM address (if available via FTP and/or FTAM):
If COMMERCIAL, please give us:
* Directions to obtain product:
Availability: (When will product be available?)
List of platforms product runs on:
[The platform list can be general - e.g. UNIX]
Short Description (< 100 words):
Full Description (< 1 page):
Fig. 1: Advanced Usages Survey Template
_______________________________________________________________________________
This survey went out to all the mailing lists we could think of:
osi-ds@cs.ucl.ac.uk, disi@merit.edu, and dssig@ics.uci.edu.
1.2 Disclaimer
Descriptions of the advanced usages were written by the implementors, and not
by the members of DISI. Although DISI has worked with the description
authors to ensure readability, no guarantees can be made regarding the
validity of descriptions. Caveat emptor.
2 The Survey Responses
2.1 Index to Responses
Application Page
2.2.1 Global Time-table Information Service .......................... 3
2.2.2 Pre-Message Security Protocol .......................... 4
2.2.3 Electronic Data Interchange .......................... 5
2.2.4 Network Topology Information .......................... 7
2.2.4.1 Shared Whois Information Project .......................... 7
2.2.4.2 Network Information Project .......................... 7
2.2.4.3 EARN's Network Directory .......................... 7
2.2.5 Soft Pages .......................... 8
2.2.6 X-Tel .......................... 10
2.2.7 Xerox Clearinghouse .......................... 12
2.2.8 X.500 Sendmail .......................... 13
2.2.9 LDAP .......................... 14
2.2.10 Gopher/X.500 Interface .......................... 15
2.2.11 Transparent ODA Conversion .......................... 16
2.2.12 X.500 and the whois protocol .......................... 18
2.2.13 X.400 table handling .......................... 19
2.2 Survey Responses
2.2.1 Global Time-table Information Service
Application Name: Global Time-table Information Service based on X.500
Date Received: 7/1/1992
Date Last Validated: 7/1/1992
Author(s):
Jens Hofmann
Cuno Lanz
Company or Institution:
Laboratory of Computer Engineering and Networks,
Swiss Federal Institute of Technology (ETH Zurich)
Switzerland
e-mail address for more information:
c=CH; a=ARCOM; p=SWITCH; o=ETHZ; ou=TIK; s=Lanz (lanz@tik.ethz.ch)
Type:
experimental prototype; not public
FTP address: <none>
Short Description:
This application aims at integrating the time-table information services
offered by public transport providers of different scope (local, regional,
national or international) into a homogeneous and unified user interface.
X.500 is used to store the information in an autonomous and extensible way.
Full Description:
Most of the public tranport providers offer some kind of time-table infor-
mation service like printed directory, help-desk, telephone support or PC
software. Unfortunately these services have some of the following drawbacks:
- no automatic update of data (information accuracy)
- no global availability (place independency)
- no permanent availability (time independency)
- no inter-provider service (service integration).
X.500 may serve as a vehicle to overcome these drawbacks as follows: The
public transport providers store the time-table information in a standardized
format on locally managed DSAs. There is some kind of special purpose DUA
which (1) queries the user for the input parameters (date, time, source and
destination station) then (2) searches for the relevant paths by querying
the involved DSAs and (3) displays the resulting time-table to the user.
In a diploma thesis a student is developing a new data model which supports
easy selection of source and destination station as well as fast exploring of
the time-table information. He is implementing a prototype application onto
an existing DUA interface (based on HyperCard and running on Apple Macintosh)
which is connected to the world-wide X.500 pilot service over DIXIE protocol.
In order to test the prototype application the time-table information of the
Swiss national public transport company and of most of the regional providers
around the city of Zurich is included under the branch: c=CH;o=ETH Zurich.
2.2.2 Pre-Message Security Protocol
Application Name:
Defense Message System Directory
Date Recieved: 7/1/1992
Date Last Validated: 7/1/1992
Author:
Bob Cooney
Company or Institution:
The Naval Computer and Telecommunications Station, Washington
and
The Defense Information System Agency
E-mail address for more information:
cooney@wnyose.nctsw.navy.mil
Type:
experimental prototype, not public
FTP address: <none>
Short Description:
The U.S. Navy will build a directory based on X.500 to support the
distribution of Pre-Message Security Protocol security keys.
Long Description:
The U.S. Navy has been asked to build a directory service to support
the distribution of Pre-Message Security Protocol security keys.
The Pre-Message Security Protocol will provide SMTP/X.400 security
services for unclassified but sensitive mail on the Defense Data Network.
The directory will be based on QUIPU. Proof of concept is expected by
October 1992, with initial operational capacity by October 1993.
2.2.3 Electronic Data Interchange
Application Name: An X.500 User Agent for Electronic Data Interchange
Date Received: 7/10/1992
Date Last Validated: 7/10/1992
Author:
Neil Weldon
Company or Institution:
Networks Group,
Computer Science Dept.,
Trinity College Dublin,
Ireland
e-mail address for more information:
omahony@cs.tcd.ie
nmweldon@vax1.tcd.ie
Type:
Research product and not for public distribution
FTP address: <none>
Short Description:
The Directory is used to assist in solving the 'first order' problem
associated with Electronic Data Interchange (EDI). EDI is the transfer
of trade documents between application processes in a processable form.
The 'first order' problem describes the agreements that two organizations
must come to regarding capabilities and preferences, before using EDI.
To solve this problem we defined object types to allow the storage of
product catalogues within the Directory, as well as information about
the EDI readiness of trading partners: addresses, preferences and EDI
capabilities.
Full Description:
Electronic Data Interchange (EDI) is the means by which organizations
exchange trade related documents between application processes in an
format which may be processed electronically.
Before using EDI an organization must establish a series of goals and
objectives, to establish what type of documents they wish to be able to
transmit (invoices, purchase orders etc.) and what their communication
requirements are. Each of these time consuming and tedious steps is
usually done in conjunction with trading partners where these agreements
regarding EDI capabilities and preferences must be made.
To solve this 'first order' problem (the need to come to agreements with
other organizations before trading using EDI takes place) we defined object
types to allow the storage of product catalogues within the Directory. The
Directory may also convey information regarding the EDI readiness of trading
partners: addresses, preferences and EDI capabilities.
Using an experimental User Agent based on Pod which was developed at Brunel
in the UK, trade documents may be built up by selecting products from the
stored catalogues. These documents are then encoded as an EDI Interchange
after the Directory has been queried about addresses etc.
The current object types are very basic and may only convey the minimal
amount of information necessary. We are now in the process of extending
this further to a full product class hierarchy which is being based on
information that may be sent within an EDI trade document using the EDI
standard document syntax EDIFACT.
By using the Directory as a repository for product information to aid in
EDI the catalogues become available worldwide. They may be replicated at
various nodes, and the updating and propagation of changes to slave copies
becomes trivial.
2.2.4 Network Topology Information
There are three projects in this area; Merit Network's Shared Whois Information
Project, Thomas Johannsen and Mark Knopper's Network Information project, and
EARN's Network Directory.
2.2.4.1 Shared Whois Information Project
Information on this is not yet available.
2.2.4.2 Network Information Project
Information on this is not yet available.
2.2.4.3 EARN's Network Directory
Application Name: Ditnet/EARN Network Directory
Date Received: 7/7/1992
Date Last Verified: 7/7/1992
Author(s):
Peter Sylvester
Company or Institution:
Inria Rocquencourt - France
e-mail address for more information:
peter.sylvester@inria.fr
Type: FREE (data owned by EARN/Bitnet)
Short Description:
The EARN/Bitnet Network database consists of descriptions of all
participating members, network nodes, adminstrators, and topology
information. This database commonly known as BITEARN NODES is being
made available through x.500.
Full Description:
A full description of the contents of the EARN/Bitnet database
can be found in some EARN internal document which is available
as a file BITEARN NODES from any NETSERV in EARN/Bitnet. The contents
of this file is mapped into an X.500 subtree containing descriptions
of network nodes, adminstrational personnel, and topology information.
The first version of the directory subtree will be created using
a simple textual mapping to a flat directory tree using private attributes.
2.2.5 Soft Pages
Application Name: Soft Pages
Date Received: 9/25/1992
Date Last Validated: 9/25/1992
Author(s):
Thomas Johannsen
Glenn Mansfield
Company or Institution:
AIC Systems Laboratory,
Tohoku University Sendai
e-mail address for more information:
spp-support@aic.co.jp
Type:
Intended for public distribution, not yet public
FTP address: <none>
Short Description:
A file name look-up services for anonymous ftp servers, provides ls -lR
information and ftp server address. Additionally, the nearest ftp site
(from user's site) which holds the requested file is chosen.
Full Description:
With the growing of number and size of electronic archives for
documents, programs and the like, the problem of finding and
retrieving a specific file becomes more and more complex. Furthermore,
bandwidth in the Internet is still limited. Users should be encouraged
and supported to do local ftp sessions as often as possible instead of
getting everything from the other end of the world (i.e. the net).
The Soft Pages Project combines an Archie-like file look-up service
with network configuration knowledge. A dedicated User Agent gives a
suggestion how to retrieve a document in a network traffic optimized
manner.
Basically, Directory information introduced by Soft Pages falls into
two parts: A file information part and a network configuration part.
The file information part describes objects and attributes for file
servers and their contents. For each file server, names and attributes
of its files are stored and updated periodically. This provides global
access to Archie-like information for all registered file servers and,
furthermore, opens the way to store document description together with
the file name. Thus, document search is not restricted to file name
matches but might be run for keywords as well.
The network configuration part provides information on networks
(subnetworks), nodes and lines in the Internet. Furthermore, IP
numbers can be mapped to network and node objects. In order to
evaluate file server sites, Internet (site to site) connections are
given a cost index and then alternatives are compared by their cost
index. Cost index is a calculated parameter representing properties of
a connection like speed, average traffic, charges etc. where values
for the latter are hold as attributes to line objects.
If a document is stored at two or more sites, the site with the lowest
cost index (which naturally will be the "nearest" in network terms)
will be chosen for retrieval. A Soft Pages User Agent basically
interacts with the Directory for finding a pointer to the "best" copy
of a file wanted by a user.
2.2.6 X-Tel
Application Name: X-Tel's advanced applications
Date received: 7/1/1992
Date last verified: 7/1/1992
Author(s):
Colin Robbins
Julian Onions
Graeme Lunt
Company or Institution: X-Tel Services Ltd.
e-mail address for more information:
x500@xtel.co.uk
Type:
Commercial Products / Ideas
Short Descriptions:
1) Product Information. Products that have DUA facilites built in
have a "latest info" button or other request method. When "pressed" a
well known node below the X-Tel part of the tree is read. The
attributes contain descriptions of the latest version of the software,
new features etc.
If you decide you would like the new version, a second read obtains
the information required for a template order form.
2) BUG Status. As above, but obtains details of known bugs in the
version of software you are running.
(If only we could find a way of putting fixes in, and automatically
updating the software itself!)
3) X-Terms. We have a conferencing product, allowing X users to
"talk" and share windows. The problem is identifying which X
Terminal device a particular user is currently on. One solution we
are using is modify a users directory entry during login to say which
X display they have logged into. The conference can the query the
directory, and open windows on the appropriate device.
The directory is also used to store details of current conferences, so
new delegates can join the conference easily.
4) Organisation browsing. There are a rich set of attributes about
people and their roles stored in the directory. We have a special
purpose DUA that exploits this information, and presents information
on who manages who, who is secretary for who etc.
This is very useful when combined with the search ACL mechanism
defined in OSI-DS 21 as different views can be given to different
catergories of users.
5) MHS use of directory. The directory is use to store MHS routing
information (as per the MHS DS working group documents)
6) Mail Lists. Details of mailing lists are stored in the
directory. With careful use of access control, users can be given
access so that they can subscribe and unsubscribe themselves to/from a list.
7) Details of restuarants in the Nottingham area are stored in the
directory!
8) We plan to use the directory as a rendevuz for a multi-user
adventure game. Each "room" will be a different entry, and modify
operations will be used to pick up and put down objects!
The next two are "advanced" features of our DUA, they may not be
considered relevant to this document!
9) Templates. The directory is used to store template entries. Our
DUA then uses this template when adding new users. Very useful, as a
number of default attributes can be set.
10) Editors. Special purpose editors for a number of complex
attribute syntaxes are built in to our DUAs. This includes QUIPU
ACLs, and X.400 OR Addresses.
2.2.7 Xerox Clearinghouse
Application Name: Clearinghouse Interface
Date Received: 7/1/1992
Date Last Validated: 7/1/1992
Author(s):
Margaret Avino
Company or Institution:
Xerox Corporation
e-mail address for more information
mavin.cin_ops@xerox.com
Type:
Early Design/Implementation stages
Short Description:
X.500 DSA interface to XNS (Xerox Network Services) Clearinghouse
directory to provide access to Xerox Corporation's Clearinghouse via X.500
DUAs.
Full Description:
Xerox uses the XNS network protocol suite to provide Mail, Filing, Directory,
Authentication, etc. network services for the installed based of 45,000+ Xerox
workstations. The Directory is based on the XNS Clearinghouse protocol which
is similar to X.500 in that it contains objects which have properties
(attributes) and is a fully distributed, replicatable directory. The searching
capabilities of the Clearinghouse protocol are not as robust as the X.500
search operation and the physical structure of the original database is not
amenable to complex searches as it could be if it were stored in a relational
database.
The first piece of this project is to transfer the data into an Oracle
relational database and create a new Clearinghouse server which accesses the
oracle database and is a full fledged member of the Clearinghouse, sending and
receiving updates to other servers using the XNS Clearinghouse protocol. This
will allow powerful SQL queries to be performed on the data which will provide
some very desired functionality such as: list all of the Distribution Lists of
which this name is a member.
To build on the new database, we are probing the implementation of an X.500 DSA
interface to the Oracle Clearinghouse Directory. This would allow X.500 DUAs
to access the data and utilize the powerful search operations. It will require
the definition of one or more new object classes and several new attributes and
some thought about the appropriate schema.
2.2.8 X.500 Sendmail
Application Name: X.500 Sendmail
Date Received: 9/25/1992
Date Last Verified: 9/25/1992
Author(s):
Tim Howes
Company or Institution:
University of Michigan
e-mail address for more information:
x500@umich.edu
Type:
FREE
FTP address: terminator.cc.umich.edu
Directions to obtain product:
get x500/sendmail-5.65.x500.tar.Z
Short Description:
Modifications to sendmail-5.65 to do X.500 lookups.
Full Description:
We have modified sendmail-5.65 so that it does X.500 lookups, returning
the value of a user's rfc822Mailbox attribute. It handles multiple
matches by sending a message containing the choices back to the sender.
If the user has no email address in X.500, the sender is sent a message
containing postal and phone information on the user. Both exact and
approximate matching is supported.
2.2.9 LDAP
Application Name: LDAP
Date Received: 9/29/1992
Date Last Verified: 9/29/1992
Author(s):
Tim Howes
Company or Institution:
University of Michigan
e-mail address for more information:
ldap-support@terminator.cc.umich.edu
Type:
FREE
FTP address: terminator.cc.umich.edu
Directions to obtain product:
get x500/ldap-2.0.tar.Z
Short Description:
LDAP is the Lightweight Directory Access Protocol. It provides lightweight
TCP/IP-based access to X.500 services. This implementation includes a server,
client API library, and sundry client programs.
2.2.10 Gopher/X.500 Interface
Application Name: go500, go500gw
Date Received: 9/29/1992
Date Last Verified: 9/29/1992
Author(s):
Tim Howes
Company or Institution:
University of Michigan
e-mail address for more information:
x500@umich.edu
Type:
FREE
FTP address: terminator.cc.umich.edu
Directions to obtain product:
get x500/ldap-2.0.tar.Z
Short Description:
go500gw is a general gopher to X.500 gateway server. go500 is a gopher
index server to X.500 gateway server. Both programs allow gopher users
to access X.500.
Full Description:
go500gw allows users to browse through the X.500 directory information
tree as if it were in gopher space. It also allows searching at each point
at each point in the tree. go500gw makes some reasonably intelligent
assumptions about what a user is searching for based on their position
in the tree and what they type, so users do not have to know much of
anything about X.500. go500 appears in gopher space as a single gopher
index search server, and searches a specific subtree of the X.500 namespace.
Both programs use the LDAP protocol to access X.500 and are distributed with
the LDAP distribution.
2.2.11 Transparent ODA Conversion
Application Name: Transparent ODA Conversion
Date Received: 7/16/1992
Date Last Verified: 7/16/1992
Author(s):
MacFarland Hale (MITRE Open Systems Group)
Company or Institution:
The MITRE Corporation
e-mail address for more information:
machale@mitre.org
Type:
Not Yet Available
Short Description:
Plan to use X.500 in conjunction with X.400 and Open Document Architecture
(ODA) to provide transparent translation of compound documents between a sender
and one or more recipients.
Full Description:
In the future, MITRE would like to combine X.500, X.400 and Open Document
Architecture (ODA) to automate the conversion of compound documents in such a
way that the users need not know about ODA or even that the conversion is
taking place. This will require new and/or updated X.400 products.
A preferred compound document format (e.g., Microsoft Word, FrameMaker, etc.)
for each user is stored in the X.500 directory. Each X.400 Message Transfer
Agent (MTA) host also houses converters between each such format and the Open
Document Interchange Format (ODIF).
A user (sender) creates a document with his or her preferred compound document
editor. Ideally, the editor software will have a link (e.g., button or
pull-down menu) to the X.400 User Agent (UA). The user invokes the X.400 UA
(either using this link, or outside of the editor software) to send the
document as an X.400 message to one or more recipients. Next, the document may
need to be converted to ODIF, and this may be done in one of two ways.
Preferably, the X.400 MTA will be responsible for the ODIF conversion. The UA
must somehow be told what format the original document is in. This may be done
via the UA invocation from inside the editor, via a UA configuration file, by
examining the filename extension, etc. It then tags the document to indicate
the document's original format using one of the body parts: "Bilaterally
Defined" (body part 14), "Nationally Defined" (body part 7) or "Externally
Defined" (body part 15). The UA then sends the message, and the MTA interprets
the tag to determine the document's format.
For messages internal to MITRE, the MTA will look up the recipient's preferred
document format. If it is different than the sender's format, the MTA calls
the appropriate ODIF converter and sends the message. If the recipient's
preferred format is the same as that of the document being sent, then no
conversion is performed. For messages going outside MITRE, the document is
always converted to ODIF. The user may prevent this by specifying that the
enclosed document is not to be converted, in which case the UA simply sends the
document in binary form with no special tag.
Alternatively, the UA may do the conversion. As above, the UA must be told the
document's original format. The UA may then call the appropriate local ODIF
converter, and then send the message. There are some disadvantages to this
approach: 1) ODIF converters must be purchased for and maintained on many more
hosts; 2) the document is always converted to ODIF (unless the UA accesses the
directory, but...); 3) conversion overhead could be traumatic on a small PC.
At each recipient host, the X.400 MTA catches the incoming message, recognizing
the contents as ODIF. It then looks up the recipients' preferred compound
document formats, calls the appropriate converters to translate the contents,
and then delivers the messages to the recipients. If the incoming message
contains one of the format tags described above, then no conversion is
performed (since the document is not in ODIF).
Please note that MITRE is a not-for-profit organization. We will not produce
commercial products to support this scenario, but we are anxious to encourage
and work with companies interested in doing so.
2.2.12 X.500 and the whois protocol
Application Name: Phone Book
Date Received: 7/15/1992
Date Last Verified: 7/15/1992
Author(s):
Steven Schoch
Company or Institution:
NASA Ames Research Center
e-mail address for more information:
schoch@sheba.arc.nasa.gov
Type:
FREE, see Steve
Short Description:
On-line edition of our phone book, using X.500 for storage and retrieval.
Full Description:
Phone Book is a user application which communicates using the
Internet whois protocol. It is listed in the Internet Resources Guide
as such. The latest incarnation, however, does not make use of a flat
file -- it gets information from a DUA that performs conversions between
information received via DAP and the format that users expect to get back
from our Phone Book queries. The change to X.500 has allowed us to supply
additional data such as E-mail address which do not normally appear in the
phone book. The fields supplied in response to a query include:
Name
Telephone Number
Mail Stop
Office Number
Organizational Affiliation (either a NASA organization code or a
contractor name)
E-mail address
Queries may be made on any of the fields specified, with the office being
divided into building and room components. A sample lookup might be:
trident:297-->phbook yee
Name Phone M/S Office Organization
--------------------------- -------- ------- --------- -----------------------
Arnold M. Yee 4-4315 258-6 N258/134 COMPSCICOR
Cindy Yee 226-3 N226/105 CALSPAN
cyee@ames.arc.nasa.gov
David H. Yee 4-4106 213-8 N213/256 EEF
david_yee@qmgate.arc.nasa.gov
Dr. Helen M C. Yee 4-4769 202A-1 N202A/216 RF
Harry Yee 4-6557 213-2 N213/101F EES
Peter Edmond Yee 4-3812 233-18 N233/240 EDC
yee@atlas.arc.nasa.gov
Robert Yee 4-4122 T041-3 TA20/155 SFA
robert_yee@qmgate.arc.nasa.gov
2.2.13 X.400 table handling
Application Name: X.400 table handling
Date Received: 7/15/1992
Date Last Verified: 7/15/1992
Author(s):
Julian Onions
Colin Robbins
Company or Institution:
X-Tel Service Limited,
Nottingham, England
e-mail address for more information:
jpo@xtel.co.uk
Type:
FREE, not yet available to the general public
Short Description:
Implementation of the work of the IETF MHS-DS group. The goal is to put X.400
tables into X.500 in order to facilitate gateway and routing functions.
Full Description:
See the Internet drafts for MHS-DS. NASA Ames Research Center is
participating in the testing and development of the next release of the PP
message handling software. The latest update (alpha test) contains usage
of X.500 by X.400 for RFC 822<->X.400 gatewaying, as well as hooks for X.400
intelligent routing. Use of X.500 to eliminate static tables will greatly
improve the ability to maintain the information necessary for mail gatewaying
and routing, while making it easier to keep this data current and well
distributed.
3 Author's addresses
Chris Weider, clw@merit.edu
2901 Hubbard, Pod G
Ann Arbor, MI 48105
(313) 747-2730
Russ Wright
Lawrence Berkeley Laboratory
1 Cyclotron Road
Berkeley, CA 94720
(415) 486-6965
wright@lbl.gov
4 Expiration Date
This Internet Draft expires April 7, 1993.
