C. Weider, Merit Network, Inc.
R. Wright, Lawrence Berkeley Laboratory
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
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. This RFC is a product of the Integrated Directory Services Working Group of the Application and User Services Areas of the IETF.
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: IDS@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 the following mailing lists: osi- ds@cs.ucl.ac.uk, disi@merit.edu (now ids@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 IDS. Although IDS has worked with the description authors to ensure readability, no guarantees can be made regarding the validity of descriptions. Caveat emptor.
Application .......... Page
2.2 Survey Responses
Application Name: Global Time-table Information Service based on X.500
Date Received: 7/1/1992
Date Last Validated: 7/1/1992
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 >
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.
Date Recieved: 7/1/1992
Date Last Validated: 7/1/1992
FTP address: < none >
Application Name: An X.500 User Agent for Electronic Data Interchange
Date Received: 7/10/1992
Date Last Validated: 7/10/1992
FTP address: < none >
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.
There are two projects in this area; Merit Network's Shared Whois
Information Project, and EARN's Network Directory.
2.2.4.1 Shared Whois Information Project
Application Name: Shared Whois Project
Date Received: 6/1/1993
Date Last Validated: 6/1/1993
Author(s): Sheri Repucci
Company or Institution: Merit Network, Inc.
e-mail address for more information: swip@merit.edu
Availability: June 1993
List of platforms product runs on: UNIX
While there is a common set of information all three of the
participants hold in their various databases, additional
information unique to the function of each organization is also
held. Furthermore, the resulting set of data created by the merger
holds only one entry per network without attempting to combine the
variations. Thus, each entry includes a listing of all databases
found to contain information for that network as well as all
databases found to be in conflict with the entry held in the
resultant set.
The longterm goal of this project is to move away from the current
model of storing similar and/or duplicate network information in
multiple databases and to move to a X.500 distributed database
model. To this end, Merit is working to load the NSFNET network
information into X.500 in anticipation of participating in a trial
with the InterNIC and others on the road to a globally distributed
database model.
2.2.4.2 EARN's Network Directory
Application Name: Ditnet/EARN Network Directory
Date Received: 7/7/1992
Date Last Verified: 7/7/1992
Type: FREE (data owned by EARN/Bitnet)
The first version of the directory subtree will be created using a
simple textual mapping to a flat directory tree using private
attributes.
Application Name: Soft Pages
Date Received: 9/25/1992
Date Last Validated: 9/25/1992
FTP address: < none >
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.
Application Name: X-Tel's advanced applications
Date received: 7/1/1992
Date last verified: 7/1/1992
Company or Institution: X-Tel Services Ltd.
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.
Application Name: Clearinghouse Interface
Date Received: 7/1/1992
Date Last Validated: 7/1/1992
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.
Application Name: X.500 Sendmail
Date Received: 9/25/1992
Date Last Verified: 9/25/1992
FTP address: terminator.cc.umich.edu
Application Name: Transparent ODA Conversion
Date Received: 7/16/1992
Date Last Verified: 7/16/1992
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.
Application Name: Phone Book
Date Received: 7/15/1992
Date Last Verified: 7/15/1992
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:
Application Name: X.400 table handling
Date Received: 7/15/1992
Date Last Verified: 7/15/1992
Security issues are not discussed in this memo.
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 EARN's Network Directory ................ 8
2.2.5 Soft Pages ................ 9
2.2.6 X-Tel ................ 10
2.2.7 Xerox Clearinghouse ................ 12
2.2.8 X.500 Sendmail ................ 13
2.2.9 Transparent ODA Conversion ................ 14
2.2.10 X.500 and the whois protocol ................ 16
2.2.11 X.400 table handling ................ 17
2.2.1 Global Time-table Information Service
Author(s):
Jens Hofmann
Cuno Lanz
Company or Institution:
Laboratory of Computer Engineering and Networks,
Swiss Federal Institute of Technology (ETH Zurich)
Switzerland
2.2.2 Pre-Message Security Protocol
Application Name:
Defense Message System Directory
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
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
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
2.2.4 Network Topology Information
Type:
experimental prototype, not public
Author(s):
Peter Sylvester
Company or Institution:
Inria Rocquencourt - France
e-mail address for more information:
peter.sylvester@inria.fr
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
Author(s):
Colin Robbins
Julian Onions
Graeme Lunt
e-mail address for more information:
x500@xtel.co.uk
Type:
Commercial Products / Ideas
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
Author(s):
Tim Howes
Company or Institution:
University of Michigan
e-mail address for more information:
x500@umich.edu
Type:
FREE
Directions to obtain product:
get x500/sendmail-5.65.x500.tar.Z
2.2.9 Transparent ODA Conversion
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
2.2.10 X.500 and the WHOIS protocol
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
Name
Telephone Number
Mail Stop
Office Number
Organizational Affiliation (either a NASA organization code
or a contractor name)
E-mail address
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
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
Chris Weider
2901 Hubbard, Pod G
Ann Arbor, MI 48105
Phone: (313) 747-2730
EMail: clw@merit.edu
Russ Wright
Lawrence Berkeley Laboratory
1 Cyclotron Road
Berkeley, CA 94720
Phone: (415) 486-6965
EMail: wright@lbl.gov