GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:fyi:fyi21

Network Working Group C. Weider Request for Comments: 1491 Merit Network, Inc. FYI: 21 R. Wright

                                          Lawrence Berkeley Laboratory
                                                             July 1993
                A Survey of Advanced Usages of X.500

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard.  Distribution of this memo is
 unlimited.

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.  This RFC is a product of the Integrated
 Directory Services Working Group of the Application and User Services
 Areas of the IETF.

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: 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 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.

Integrated Directory Services Working Group [Page 2] RFC 1491 X.500 Advanced Usages July 1993

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.

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  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 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)

Integrated Directory Services Working Group [Page 3] RFC 1491 X.500 Advanced Usages July 1993

 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
   information service like printed directory, help-desk, telephone
   support or PC software. Unfortunately these services have some of
   the following drawbacks:
  1. no automatic update of data (information accuracy)
  2. no global availability (place independency)
  3. no permanent availability (time independency)
  4. 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

Integrated Directory Services Working Group [Page 4] RFC 1491 X.500 Advanced Usages July 1993

 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

Integrated Directory Services Working Group [Page 5] RFC 1491 X.500 Advanced Usages July 1993

 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.

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 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 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
 Type:
   experimental prototype, not public
 List of platforms product runs on: UNIX
 Short Description:
   The Shared Whois Project merges network data held by various
   organizations.  The principal purpose of merging this data is to
   find and resolve conflicting network information between the
   databases.  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, we are working on loading
   the NSFNET network information into X.500 in anticipation of
   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 shell
   scripts which collectively merges the network data held by each of
   the participating organizations.  Currently this includes Merit,
   the RIPE-NCC and the InterNIC.  The principal purpose of merging
   this vast quantity of data is to find and resolve conflicting
   network information between the various databases.  It is our
   intent to merge this data bi-weekly and thus rapidly reach, and
   thereafter maintain, a stable set of commonly held network
   information.
   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
 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)

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 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.

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 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

Integrated Directory Services Working Group [Page 10] RFC 1491 X.500 Advanced Usages July 1993

 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 Description:
   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)

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 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.

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 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

Integrated Directory Services Working Group [Page 13] RFC 1491 X.500 Advanced Usages July 1993

 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 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.

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 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.

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 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.10 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:

Integrated Directory Services Working Group [Page 16] RFC 1491 X.500 Advanced Usages July 1993

         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.11 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

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 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. Security Considerations

 Security issues are not discussed in this memo.

4. Authors' Addresses

 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

Integrated Directory Services Working Group [Page 18]

/data/webs/external/dokuwiki/data/pages/rfc/fyi/fyi21.txt · Last modified: 1993/07/21 21:54 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki