As per Relevance of the word document, we have this rfc below:
Network Working Group C.
Request for Comments: 1491 Merit Network, Inc
FYI: 21 R.
Lawrence Berkeley
July 1993
A Survey of Advanced Usages of X.500
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
This document is the result of a survey asking people to detail
advanced usages of X.500. It is intended to show how
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
Directory Services Working Group of the Application and User
Areas of the IETF
1.
As the use of X.500 spreads in the Internet, organizations
finding uses for it which go beyond the "white pages" paradigm
has been used to introduce it to new users. Consequently, to
those new uses and to encourage the wider use of X.500, we sent out
survey to obtain "advanced usages" of X.500.
1.1 The
The survey we sent out is included here for two purposes
1) completeness,
2) we'd like to encourage anyone who retrieves this document to
us their advanced usage for inclusion in the next revision
If you wish to fill this out, please send it to the working
list: IDS@merit.edu
Integrated Directory Services Working Group [Page 1]
RFC 1491 X.500 Advanced Usages July 1993
_____________________________________________________________________
Application Name
Author(s):
Company or Institution
e-mail address for more information
If this is a product for public distribution, please give us
Type: FREE, COMMERCIAL PRODUCT, or PROTOTYPE/
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
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
______________________________________________________________________
This survey went out to the following mailing lists: osi
ds@cs.ucl.ac.uk, disi@merit.edu (now ids@merit.edu),
dssig@ics.uci.edu
Integrated Directory Services Working Group [Page 2]
RFC 1491 X.500 Advanced Usages July 1993
1.2
Descriptions of the advanced usages were written by the implementors
and not by the members of IDS. Although IDS has worked with
description authors to ensure readability, no guarantees can be
regarding the validity of descriptions. Caveat emptor
2. The Survey
2.1 Index to
Application
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 Survey
2.2.1 Global Time-table Information
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
Cuno
Company or Institution
Laboratory of Computer Engineering and Networks
Swiss Federal Institute of Technology (ETH Zurich
e-mail address for more information
c=CH; a=ARCOM; p=SWITCH; o=ETHZ; ou=TIK; s=Lanz (lanz@tik.ethz.ch
Integrated Directory Services Working Group [Page 3]
RFC 1491 X.500 Advanced Usages July 1993
Type
experimental prototype; not
FTP address:
Short Description
This application aims at integrating the time-table
services offered by public transport providers of different
(local, regional, national or international) into a homogeneous
unified user interface. X.500 is used to store the information
an autonomous and extensible way
Full Description
Most of the public tranport providers offer some kind of time-
information service like printed directory, help-desk,
support or PC software. Unfortunately these services have some
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
follows: The public transport providers store the time-
information in a standardized format on locally managed DSAs.
is some kind of special purpose DUA which (1) queries the user
the input parameters (date, time, source and destination station
then (2) searches for the relevant paths by querying the
DSAs and (3) displays the resulting time-table to the user
In a diploma thesis a student is developing a new data model
supports easy selection of source and destination station as
as fast exploring of the time-table information. He is
a prototype application onto an existing DUA interface (based
HyperCard and running on Apple Macintosh) which is connected to
world-wide X.500 pilot service over DIXIE protocol. In order
test the prototype application the time-table information of
Swiss national public transport company and of most of the
providers around the city of Zurich is included under the branch
c=CH;o=ETH Zurich
2.2.2 Pre-Message Security
Application Name
Defense Message System
Date Recieved: 7/1/1992
Integrated Directory Services Working Group [Page 4]
RFC 1491 X.500 Advanced Usages July 1993
Date Last Validated: 7/1/1992
Author
Bob
Company or Institution
The Naval Computer and Telecommunications Station,
The Defense Information System
E-mail address for more information
cooney@wnyose.nctsw.navy.
Type
experimental prototype, not
FTP address:
Short Description
The U.S. Navy will build a directory based on X.500 to support
distribution of Pre-Message Security Protocol security keys
Long Description
The U.S. Navy has been asked to build a directory service to
the distribution of Pre-Message Security Protocol security keys
The Pre-Message Security Protocol will provide SMTP/X.400
services for unclassified but sensitive mail on the Defense
Network
The directory will be based on QUIPU. Proof of concept is
by October 1992, with initial operational capacity by October 1993.
2.2.3 Electronic Data
Application Name: An X.500 User Agent for Electronic Data
Date Received: 7/10/1992
Date Last Validated: 7/10/1992
Author
Neil
Company or Institution
Networks Group
Computer Science Dept.,
Trinity College Dublin
Integrated Directory Services Working Group [Page 5]
RFC 1491 X.500 Advanced Usages July 1993
e-mail address for more information
omahony@cs.tcd.
nmweldon@vax1.tcd.
Type
Research product and not for public
FTP address:
Short Description
The Directory is used to assist in solving the 'first order
problem associated with Electronic Data Interchange (EDI). EDI
the transfer of trade documents between application processes in
processable form. The 'first order' problem describes
agreements that two organizations must come to
capabilities and preferences, before using EDI
To solve this problem we defined object types to allow the
of product catalogues within the Directory, as well as
about the EDI readiness of trading partners: addresses,
and EDI capabilities
Full Description
Electronic Data Interchange (EDI) is the means by
organizations exchange trade related documents between
processes in an format which may be processed electronically
Before using EDI an organization must establish a series of
and objectives, to establish what type of documents they wish to
able to transmit (invoices, purchase orders etc.) and what
communication requirements are. Each of these time consuming
tedious steps is usually done in conjunction with trading
where these agreements regarding EDI capabilities and
must be made
To solve this 'first order' problem (the need to come to
with other organizations before trading using EDI takes place)
defined object types to allow the storage of product
within the Directory. The Directory may also convey
regarding the EDI readiness of trading partners: addresses
preferences and EDI capabilities
Using an experimental User Agent based on Pod which was
at Brunel in the UK, trade documents may be built up by
products from the stored catalogues. These documents are
encoded as an EDI Interchange after the Directory has been
about addresses, etc
Integrated Directory Services Working Group [Page 6]
RFC 1491 X.500 Advanced Usages July 1993
The current object types are very basic and may only convey
minimal amount of information necessary. We are now in the
of extending this further to a full product class hierarchy
is being based on information that may be sent within an EDI
document using the EDI standard document syntax EDIFACT
By using the Directory as a repository for product information
aid in EDI the catalogues become available worldwide. They may
replicated at various nodes, and the updating and propagation
changes to slave copies becomes trivial
2.2.4 Network Topology
There are two projects in this area; Merit Network's Shared
Information Project, and EARN's Network Directory
2.2.4.1 Shared Whois Information
Application Name: Shared Whois
Date Received: 6/1/1993
Date Last Validated: 6/1/1993
Author(s): Sheri
Company or Institution: Merit Network, Inc
e-mail address for more information: swip@merit.
Availability: June 1993
Type
experimental prototype, not
List of platforms product runs on:
Short Description
The Shared Whois Project merges network data held by
organizations. The principal purpose of merging this data is
find and resolve conflicting network information between
databases. The longterm goal of this project is to move away
the current model of storing similar and/or duplicate
information in multiple databases and to move to a X.500
distributed database model. To this end, we are working on
the NSFNET network information into X.500 in anticipation
participating in a distributed database trial
Integrated Directory Services Working Group [Page 7]
RFC 1491 X.500 Advanced Usages July 1993
Full Description
The Shared Whois Project is a collection of programs and
scripts which collectively merges the network data held by each
the participating organizations. Currently this includes Merit
the RIPE-NCC and the InterNIC. The principal purpose of
this vast quantity of data is to find and resolve
network information between the various databases. It is
intent to merge this data bi-weekly and thus rapidly reach,
thereafter maintain, a stable set of commonly held
information
While there is a common set of information all three of
participants hold in their various databases,
information unique to the function of each organization is
held. Furthermore, the resulting set of data created by the
holds only one entry per network without attempting to combine
variations. Thus, each entry includes a listing of all
found to contain information for that network as well as
databases found to be in conflict with the entry held in
resultant set
The longterm goal of this project is to move away from the
model of storing similar and/or duplicate network information
multiple databases and to move to a X.500 distributed
model. To this end, Merit is working to load the NSFNET
information into X.500 in anticipation of participating in a
with the InterNIC and others on the road to a globally
database model
2.2.4.2 EARN's Network
Application Name: Ditnet/EARN Network
Date Received: 7/7/1992
Date Last Verified: 7/7/1992
Author(s):
Peter
Company or Institution
Inria Rocquencourt -
e-mail address for more information
peter.sylvester@inria.
Type: FREE (data owned by EARN/Bitnet
Integrated Directory Services Working Group [Page 8]
RFC 1491 X.500 Advanced Usages July 1993
Short Description
The EARN/Bitnet Network database consists of descriptions of
participating members, network nodes, adminstrators, and
information. This database commonly known as BITEARN NODES is
made available through x.500.
Full Description
A full description of the contents of the EARN/Bitnet
can be found in some EARN internal document which is
as a file BITEARN NODES from any NETSERV in EARN/Bitnet.
contents of this file is mapped into an X.500 subtree
descriptions of network nodes, adminstrational personnel,
topology information
The first version of the directory subtree will be created using
simple textual mapping to a flat directory tree using
attributes
2.2.5 Soft
Application Name: Soft
Date Received: 9/25/1992
Date Last Validated: 9/25/1992
Author(s):
Thomas
Glenn
Company or Institution
AIC Systems Laboratory
Tohoku University
e-mail address for more information
spp-support@aic.co.
Type
Intended for public distribution, not yet
FTP address:
Short Description
A file name look-up services for anonymous FTP servers, provides
-lR information and FTP server address. Additionally, the
FTP site (from user's site) which holds the requested file
chosen
Integrated Directory Services Working Group [Page 9]
RFC 1491 X.500 Advanced Usages July 1993
Full Description
With the growing of number and size of electronic archives
documents, programs and the like, the problem of finding
retrieving a specific file becomes more and more complex
Furthermore, bandwidth in the Internet is still limited.
should be encouraged and supported to do local FTP sessions as
as possible instead of getting everything from the other end of
world (i.e., the net).
The Soft Pages Project combines an Archie-like file look-up
with network configuration knowledge. A dedicated User Agent
a suggestion how to retrieve a document in a network
optimized manner
Basically, Directory information introduced by Soft Pages
into two parts: A file information part and a network
part
The file information part describes objects and attributes for
servers and their contents. For each file server, names
attributes of its files are stored and updated periodically.
provides global access to Archie-like information for
registered file servers and, furthermore, opens the way to
document description together with the file name. Thus,
search is not restricted to file name matches but might be run
keywords as well
The network configuration part provides information on
(subnetworks), nodes and lines in the Internet. Furthermore,
numbers can be mapped to network and node objects. In order
evaluate file server sites, Internet (site to site) connections
given a cost index and then alternatives are compared by their
index. Cost index is a calculated parameter representing
of a connection like speed, average traffic, charges etc.
values for the latter are hold as attributes to line objects
If a document is stored at two or more sites, the site with
lowest cost index (which naturally will be the "nearest" in
terms) will be chosen for retrieval. A Soft Pages User
basically interacts with the Directory for finding a pointer to
"best" copy of a file wanted by a user
2.2.6 X-
Application Name: X-Tel's advanced
Date received: 7/1/1992
Integrated Directory Services Working Group [Page 10]
RFC 1491 X.500 Advanced Usages July 1993
Date last verified: 7/1/1992
Author(s):
Colin
Julian
Graeme
Company or Institution: X-Tel Services Ltd
e-mail address for more information
x500@xtel.co.
Type
Commercial Products /
Short Description
1) Product Information. Products that have DUA facilites built
have a "latest info" button or other request method.
"pressed" a well known node below the X-Tel part of the tree
read. The attributes contain descriptions of the latest version
the software, new features etc. If you decide you would like
new version, a second read obtains the information required for
template order form
2) BUG Status. As above, but obtains details of known bugs in
version of software you are running. (If only we could find a
of putting fixes in, and automatically updating the
itself!)
3) X-Terms. We have a conferencing product, allowing X users
"talk" and share windows. The problem is identifying which
Terminal device a particular user is currently on. One solution
are using is modify a users directory entry during login to
which X display they have logged into. The conference can
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
people and their roles stored in the directory. We have a
purpose DUA that exploits this information, and
information on who manages who, who is secretary for who etc.
is very useful when combined with the search ACL mechanism
in OSI-DS 21 as different views can be given to
catergories of users
5) MHS use of directory. The directory is use to store MHS
information (as per the MHS DS working group documents
Integrated Directory Services Working Group [Page 11]
RFC 1491 X.500 Advanced Usages July 1993
6) Mail Lists. Details of mailing lists are stored in
directory. With careful use of access control, users can be
access so that they can subscribe and unsubscribe
to/from a list
7) Details of restuarants in the Nottingham area are stored in
directory
8) We plan to use the directory as a rendevuz for a multi-
adventure game. Each "room" will be a different entry, and
operations will be used to pick up and put down objects
The next two are "advanced" features of our DUA, they may not
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.
useful, as a number of default attributes can be set
10) Editors. Special purpose editors for a number of
attribute syntaxes are built in to our DUAs. This includes
ACLs, and X.400 OR Addresses
2.2.7 Xerox
Application Name: Clearinghouse
Date Received: 7/1/1992
Date Last Validated: 7/1/1992
Author(s):
Margaret
Company or Institution
Xerox
e-mail address for more
mavin.cin_ops@xerox.
Type
Early Design/Implementation
Short Description
X.500 DSA interface to XNS (Xerox Network Services)
directory to provide access to Xerox Corporation's Clearinghouse
X.500 DUAs
Integrated Directory Services Working Group [Page 12]
RFC 1491 X.500 Advanced Usages July 1993
Full Description
Xerox uses the XNS network protocol suite to provide Mail, Filing
Directory, Authentication, etc. network services for the
based of 45,000+ Xerox workstations. The Directory is based on
XNS Clearinghouse protocol which is similar to X.500 in that
contains objects which have properties (attributes) and is a
distributed, replicatable directory. The searching capabilities
the Clearinghouse protocol are not as robust as the X.500
operation and the physical structure of the original database
not amenable to complex searches as it could be if it were
in a relational database
The first piece of this project is to transfer the data into
Oracle relational database and create a new Clearinghouse
which accesses the oracle database and is a full fledged member
the Clearinghouse, sending and receiving updates to other
using the XNS Clearinghouse protocol. This will allow powerful
queries to be performed on the data which will provide some
desired functionality such as: list all of the Distribution
of which this name is a member
To build on the new database, we are probing the implementation
an X.500 DSA interface to the Oracle Clearinghouse Directory.
would allow X.500 DUAs to access the data and utilize the
search operations. It will require the definition of one or
new object classes and several new attributes and some
about the appropriate schema
2.2.8 X.500
Application Name: X.500
Date Received: 9/25/1992
Date Last Verified: 9/25/1992
Author(s):
Tim
Company or Institution
University of
e-mail address for more information
x500@umich.
Type
Integrated Directory Services Working Group [Page 13]
RFC 1491 X.500 Advanced Usages July 1993
FTP address: terminator.cc.umich.
Directions to obtain product
get x500/sendmail-5.65.x500.tar.
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.
handles multiple matches by sending a message containing
choices back to the sender. If the user has no email address
X.500, the sender is sent a message containing postal and
information on the user. Both exact and approximate matching
supported
2.2.9 Transparent ODA
Application Name: Transparent ODA
Date Received: 7/16/1992
Date Last Verified: 7/16/1992
Author(s):
MacFarland Hale (MITRE Open Systems Group
Company or Institution
The MITRE
e-mail address for more information
machale@mitre.
Type
Not Yet
Short Description
Plan to use X.500 in conjunction with X.400 and Open
Architecture (ODA) to provide transparent translation of
documents between a sender and one or more recipients
Full Description
In the future, MITRE would like to combine X.500, X.400 and
Document Architecture (ODA) to automate the conversion of
documents in such a way that the users need not know about ODA
even that the conversion is taking place. This will require
and/or updated X.400 products
Integrated Directory Services Working Group [Page 14]
RFC 1491 X.500 Advanced Usages July 1993
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
between each such format and the Open Document Interchange
(ODIF).
A user (sender) creates a document with his or her
compound document editor. Ideally, the editor software will have
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
of the editor software) to send the document as an X.400 message
one or more recipients. Next, the document may need to
converted to ODIF, and this may be done in one of two ways
Preferably, the X.400 MTA will be responsible for the
conversion. The UA must somehow be told what format the
document is in. This may be done via the UA invocation from
the editor, via a UA configuration file, by examining the
extension, etc. It then tags the document to indicate
document's original format using one of the body parts
"Bilaterally Defined" (body part 14), "Nationally Defined" (
part 7) or "Externally Defined" (body part 15). The UA then
the message, and the MTA interprets the tag to determine
document's format
For messages internal to MITRE, the MTA will look up
recipient's preferred document format. If it is different than
sender's format, the MTA calls the appropriate ODIF converter
sends the message. If the recipient's preferred format is the
as that of the document being sent, then no conversion
performed. For messages going outside MITRE, the document
always converted to ODIF. The user may prevent this by
that the enclosed document is not to be converted, in which
the UA simply sends the document in binary form with no
tag
Alternatively, the UA may do the conversion. As above, the UA
be told the document's original format. The UA may then call
appropriate local ODIF converter, and then send the message.
are some disadvantages to this approach
1) ODIF converters must be purchased for and maintained on
more hosts
2) the document is always converted to ODIF (unless the
accesses the directory, but...);
3) conversion overhead could be traumatic on a small PC
Integrated Directory Services Working Group [Page 15]
RFC 1491 X.500 Advanced Usages July 1993
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
converters to translate the contents, and then delivers
messages to the recipients. If the incoming message contains
of the format tags described above, then no conversion is
(since the document is not in ODIF).
Please note that MITRE is a not-for-profit organization. We
not produce commercial products to support this scenario, but
are anxious to encourage and work with companies interested
doing so
2.2.10 X.500 and the WHOIS
Application Name: Phone
Date Received: 7/15/1992
Date Last Verified: 7/15/1992
Author(s):
Steven
Company or Institution
NASA Ames Research
e-mail address for more information
schoch@sheba.arc.nasa.
Type
FREE, see
Short Description
On-line edition of our phone book, using X.500 for storage
retrieval
Full Description
Phone Book is a user application which communicates using
Internet WHOIS protocol. It is listed in the Internet
Guide as such. The latest incarnation, however, does not make
of a flat file -- it gets information from a DUA that
conversions between information received via DAP and the format
users expect to get back from our Phone Book queries. The change
X.500 has allowed us to supply additional data such as E-
address which do not normally appear in the phone book. The
supplied in response to a query include
Integrated Directory Services Working Group [Page 16]
RFC 1491 X.500 Advanced Usages July 1993
Telephone
Mail
Office
Organizational Affiliation (either a NASA organization
or a contractor name
E-mail
Queries may be made on any of the fields specified, with the
being divided into building and room components. A sample
might be
trident:297-->phbook
Name Phone M/S Office
--------------------------- -------- ------- --------- ------------
Arnold M. Yee 4-4315 258-6 N258/134
Cindy Yee 226-3 N226/105
cyee@ames.arc.nasa.
David H. Yee 4-4106 213-8 N213/256
david_yee@qmgate.arc.nasa.
Dr. Helen M C. Yee 4-4769 202A-1 N202A/216
Harry Yee 4-6557 213-2 N213/101F
Peter Edmond Yee 4-3812 233-18 N233/240
yee@atlas.arc.nasa.
Robert Yee 4-4122 T041-3 TA20/155
robert_yee@qmgate.arc.nasa.
2.2.11 X.400 table
Application Name: X.400 table
Date Received: 7/15/1992
Date Last Verified: 7/15/1992
Author(s):
Julian
Colin
Company or Institution
X-Tel Service Limited
Nottingham,
e-mail address for more information
jpo@xtel.co.
Type
FREE, not yet available to the general
Integrated Directory Services Working Group [Page 17]
RFC 1491 X.500 Advanced Usages July 1993
Short Description
Implementation of the work of the IETF MHS-DS group. The goal is
put X.400 tables into X.500 in order to facilitate gateway
routing functions
Full Description
See the Internet drafts for MHS-DS. NASA Ames Research Center
participating in the testing and development of the next release
the PP message handling software. The latest update (alpha test
contains usage of X.500 by X.400 for RFC 822<->X.400 gatewaying,
well as hooks for X.400 intelligent routing. Use of X.500
eliminate static tables will greatly improve the ability
maintain the information necessary for mail gatewaying and routing
while making it easier to keep this data current and
distributed
3. Security
Security issues are not discussed in this memo
4. Authors'
Chris
2901 Hubbard, Pod
Ann Arbor, MI 48105
Phone: (313) 747-2730
EMail: clw@merit.
Russ
Lawrence Berkeley
1 Cyclotron
Berkeley, CA 94720
Phone: (415) 486-6965
EMail: wright@lbl.
Integrated Directory Services Working Group [Page 18]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
