home *** CD-ROM | disk | FTP | other *** search
/ Internet Access: To the Information Highway / InternetAccessToTheInformationHighway1994.disc1of1.iso / internet / rfc4 / rfc1491.txt < prev    next >
Text File  |  1994-05-29  |  36KB  |  1,012 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          C. Weider
  8. Request for Comments: 1491                           Merit Network, Inc.
  9. FYI: 21                                                        R. Wright
  10.                                             Lawrence Berkeley Laboratory
  11.                                                                July 1993
  12.  
  13.  
  14.                   A Survey of Advanced Usages of X.500
  15.  
  16. Status of this Memo
  17.  
  18.    This memo provides information for the Internet community.  It does
  19.    not specify an Internet standard.  Distribution of this memo is
  20.    unlimited.
  21.  
  22. Abstract
  23.  
  24.    This document is the result of a survey asking people to detail their
  25.    advanced usages of X.500. It is intended to show how various
  26.    organizations are using X.500 in ways which extend the view of X.500
  27.    as a "White Pages" service.  This RFC is a product of the Integrated
  28.    Directory Services Working Group of the Application and User Services
  29.    Areas of the IETF.
  30.  
  31. 1. Introduction
  32.  
  33.    As the use of X.500 spreads in the Internet, organizations are
  34.    finding uses for it which go beyond the "white pages" paradigm which
  35.    has been used to introduce it to new users. Consequently, to document
  36.    those new uses and to encourage the wider use of X.500, we sent out a
  37.    survey to obtain "advanced usages" of X.500.
  38.  
  39. 1.1 The survey
  40.  
  41.    The survey we sent out is included here for two purposes:
  42.  
  43.    1) completeness, and
  44.    2) we'd like to encourage anyone who retrieves this document to send
  45.       us their advanced usage for inclusion in the next revision.
  46.  
  47.    If you wish to fill this out, please send it to the working group
  48.    list: IDS@merit.edu.
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Integrated Directory Services Working Group                     [Page 1]
  59.  
  60. RFC 1491                 X.500 Advanced Usages                 July 1993
  61.  
  62.  
  63.    _____________________________________________________________________
  64.  
  65.    Application Name:
  66.  
  67.    Author(s):
  68.  
  69.    Company or Institution:
  70.  
  71.    e-mail address for more information:
  72.  
  73.    If this is a product for public distribution, please give us the
  74.      Type: FREE, COMMERCIAL PRODUCT, or PROTOTYPE/RESEARCH
  75.      FREE               - Anyone may obtain this product at zero cost.
  76.      COMMERCIAL PRODUCT - One may purchase this product.
  77.      PROTOTYPE/RESEARCH - This product is not yet available, only a
  78.                           prototype.
  79.  
  80.    If FREE, please give us:
  81.      * FTP and/or FTAM address (if available via FTP and/or FTAM):
  82.  
  83.    If COMMERCIAL, please give us:
  84.      * Directions to obtain product:
  85.  
  86.    Availability: (When will product be available?)
  87.  
  88.    List of platforms product runs on:
  89.    [The platform list can be general - e.g. UNIX]
  90.  
  91.    Short Description (< 100 words):
  92.  
  93.    Full Description (< 1 page):
  94.  
  95.                    Fig. 1: Advanced Usages Survey Template
  96.  
  97.    ______________________________________________________________________
  98.  
  99.  
  100.    This survey went out to the following mailing lists: osi-
  101.    ds@cs.ucl.ac.uk, disi@merit.edu (now ids@merit.edu), and
  102.    dssig@ics.uci.edu.
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Integrated Directory Services Working Group                     [Page 2]
  115.  
  116. RFC 1491                 X.500 Advanced Usages                 July 1993
  117.  
  118.  
  119. 1.2 Disclaimer
  120.  
  121.    Descriptions of the advanced usages were written by the implementors,
  122.    and not by the members of IDS. Although IDS has worked with the
  123.    description authors to ensure readability, no guarantees can be made
  124.    regarding the validity of descriptions. Caveat emptor.
  125.  
  126. 2. The Survey Responses
  127.  
  128. 2.1 Index to Responses
  129.  
  130.    Application                                                   Page
  131.  
  132.    2.2.1  Global Time-table Information Service ................    3
  133.    2.2.2  Pre-Message Security Protocol         ................    4
  134.    2.2.3  Electronic Data Interchange           ................    5
  135.    2.2.4  Network Topology Information          ................    7
  136.    2.2.4.1  Shared Whois Information Project    ................    7
  137.    2.2.4.2  EARN's Network Directory            ................    8
  138.    2.2.5  Soft Pages                            ................    9
  139.    2.2.6  X-Tel                                 ................   10
  140.    2.2.7  Xerox Clearinghouse                   ................   12
  141.    2.2.8  X.500 Sendmail                        ................   13
  142.    2.2.9  Transparent ODA Conversion            ................   14
  143.    2.2.10 X.500 and the whois protocol          ................   16
  144.    2.2.11 X.400 table handling                  ................   17
  145.  
  146. 2.2 Survey Responses
  147.  
  148. 2.2.1 Global Time-table Information Service
  149.  
  150.    Application Name: Global Time-table Information Service based on X.500
  151.  
  152.    Date Received: 7/1/1992
  153.  
  154.    Date Last Validated: 7/1/1992
  155.  
  156.    Author(s):
  157.      Jens Hofmann
  158.      Cuno Lanz
  159.  
  160.    Company or Institution:
  161.      Laboratory of Computer Engineering and Networks,
  162.      Swiss Federal Institute of Technology (ETH Zurich)
  163.      Switzerland
  164.  
  165.    e-mail address for more information:
  166.      c=CH; a=ARCOM; p=SWITCH; o=ETHZ; ou=TIK; s=Lanz (lanz@tik.ethz.ch)
  167.  
  168.  
  169.  
  170. Integrated Directory Services Working Group                     [Page 3]
  171.  
  172. RFC 1491                 X.500 Advanced Usages                 July 1993
  173.  
  174.  
  175.    Type:
  176.      experimental prototype; not public
  177.  
  178.    FTP address: <none>
  179.  
  180.    Short Description:
  181.      This application aims at integrating the time-table information
  182.      services offered by public transport providers of different scope
  183.      (local, regional, national or international) into a homogeneous and
  184.      unified user interface.  X.500 is used to store the information in
  185.      an autonomous and extensible way.
  186.  
  187.    Full Description:
  188.      Most of the public tranport providers offer some kind of time-table
  189.      information service like printed directory, help-desk, telephone
  190.      support or PC software. Unfortunately these services have some of
  191.      the following drawbacks:
  192.  
  193.          - no automatic update of data (information accuracy)
  194.          - no global availability (place independency)
  195.          - no permanent availability (time independency)
  196.          - no inter-provider service (service integration).
  197.  
  198.      X.500 may serve as a vehicle to overcome these drawbacks as
  199.      follows: The public transport providers store the time-table
  200.      information in a standardized format on locally managed DSAs. There
  201.      is some kind of special purpose DUA which (1) queries the user for
  202.      the input parameters (date, time, source and destination station)
  203.      then (2) searches for the relevant paths by querying the involved
  204.      DSAs and (3) displays the resulting time-table to the user.
  205.  
  206.      In a diploma thesis a student is developing a new data model which
  207.      supports easy selection of source and destination station as well
  208.      as fast exploring of the time-table information. He is implementing
  209.      a prototype application onto an existing DUA interface (based on
  210.      HyperCard and running on Apple Macintosh) which is connected to the
  211.      world-wide X.500 pilot service over DIXIE protocol.  In order to
  212.      test the prototype application the time-table information of the
  213.      Swiss national public transport company and of most of the regional
  214.      providers around the city of Zurich is included under the branch:
  215.      c=CH;o=ETH Zurich.
  216.  
  217. 2.2.2 Pre-Message Security Protocol
  218.  
  219.    Application Name:
  220.      Defense Message System Directory
  221.  
  222.    Date Recieved: 7/1/1992
  223.  
  224.  
  225.  
  226. Integrated Directory Services Working Group                     [Page 4]
  227.  
  228. RFC 1491                 X.500 Advanced Usages                 July 1993
  229.  
  230.  
  231.    Date Last Validated: 7/1/1992
  232.  
  233.    Author:
  234.      Bob Cooney
  235.  
  236.    Company or Institution:
  237.      The Naval Computer and Telecommunications Station, Washington
  238.      and
  239.      The Defense Information System Agency
  240.  
  241.    E-mail address for more information:
  242.      cooney@wnyose.nctsw.navy.mil
  243.  
  244.    Type:
  245.      experimental prototype, not public
  246.  
  247.    FTP address: <none>
  248.  
  249.    Short Description:
  250.      The U.S. Navy will build a directory based on X.500 to support the
  251.      distribution of Pre-Message Security Protocol security keys.
  252.  
  253.    Long Description:
  254.      The U.S. Navy has been asked to build a directory service to support
  255.      the distribution of Pre-Message Security Protocol security keys.
  256.      The Pre-Message Security Protocol will provide SMTP/X.400 security
  257.      services for unclassified but sensitive mail on the Defense Data
  258.      Network.
  259.  
  260.      The directory will be based on QUIPU. Proof of concept is expected
  261.      by October 1992, with initial operational capacity by October 1993.
  262.  
  263. 2.2.3 Electronic Data Interchange
  264.  
  265.    Application Name: An X.500 User Agent for Electronic Data Interchange
  266.  
  267.    Date Received: 7/10/1992
  268.  
  269.    Date Last Validated: 7/10/1992
  270.  
  271.    Author:
  272.      Neil Weldon
  273.  
  274.    Company or Institution:
  275.      Networks Group,
  276.      Computer Science Dept.,
  277.      Trinity College Dublin,
  278.      Ireland
  279.  
  280.  
  281.  
  282. Integrated Directory Services Working Group                     [Page 5]
  283.  
  284. RFC 1491                 X.500 Advanced Usages                 July 1993
  285.  
  286.  
  287.    e-mail address for more information:
  288.      omahony@cs.tcd.ie
  289.      nmweldon@vax1.tcd.ie
  290.  
  291.    Type:
  292.      Research product and not for public distribution
  293.  
  294.    FTP address: <none>
  295.  
  296.    Short Description:
  297.      The Directory is used to assist in solving the 'first order'
  298.      problem associated with Electronic Data Interchange (EDI). EDI is
  299.      the transfer of trade documents between application processes in a
  300.      processable form.  The 'first order' problem describes the
  301.      agreements that two organizations must come to regarding
  302.      capabilities and preferences, before using EDI.
  303.  
  304.      To solve this problem we defined object types to allow the storage
  305.      of product catalogues within the Directory, as well as information
  306.      about the EDI readiness of trading partners: addresses, preferences
  307.      and EDI capabilities.
  308.  
  309.    Full Description:
  310.      Electronic Data Interchange (EDI) is the means by which
  311.      organizations exchange trade related documents between application
  312.      processes in an format which may be processed electronically.
  313.  
  314.      Before using EDI an organization must establish a series of goals
  315.      and objectives, to establish what type of documents they wish to be
  316.      able to transmit (invoices, purchase orders etc.) and what their
  317.      communication requirements are. Each of these time consuming and
  318.      tedious steps is usually done in conjunction with trading partners
  319.      where these agreements regarding EDI capabilities and preferences
  320.      must be made.
  321.  
  322.      To solve this 'first order' problem (the need to come to agreements
  323.      with other organizations before trading using EDI takes place) we
  324.      defined object types to allow the storage of product catalogues
  325.      within the Directory. The Directory may also convey information
  326.      regarding the EDI readiness of trading partners: addresses,
  327.      preferences and EDI capabilities.
  328.  
  329.      Using an experimental User Agent based on Pod which was developed
  330.      at Brunel in the UK, trade documents may be built up by selecting
  331.      products from the stored catalogues. These documents are then
  332.      encoded as an EDI Interchange after the Directory has been queried
  333.      about addresses, etc.
  334.  
  335.  
  336.  
  337.  
  338. Integrated Directory Services Working Group                     [Page 6]
  339.  
  340. RFC 1491                 X.500 Advanced Usages                 July 1993
  341.  
  342.  
  343.      The current object types are very basic and may only convey the
  344.      minimal amount of information necessary. We are now in the process
  345.      of extending this further to a full product class hierarchy which
  346.      is being based on information that may be sent within an EDI trade
  347.      document using the EDI standard document syntax EDIFACT.
  348.  
  349.      By using the Directory as a repository for product information to
  350.      aid in EDI the catalogues become available worldwide. They may be
  351.      replicated at various nodes, and the updating and propagation of
  352.      changes to slave copies becomes trivial.
  353.  
  354. 2.2.4 Network Topology Information
  355.  
  356.    There are two projects in this area; Merit Network's Shared Whois
  357.    Information Project, and EARN's Network Directory.
  358.  
  359. 2.2.4.1 Shared Whois Information Project
  360.  
  361.    Application Name: Shared Whois Project
  362.  
  363.    Date Received: 6/1/1993
  364.  
  365.    Date Last Validated: 6/1/1993
  366.  
  367.    Author(s): Sheri Repucci
  368.  
  369.    Company or Institution: Merit Network, Inc.
  370.  
  371.    e-mail address for more information: swip@merit.edu
  372.  
  373.    Availability: June 1993
  374.  
  375.    Type:
  376.      experimental prototype, not public
  377.  
  378.    List of platforms product runs on: UNIX
  379.  
  380.    Short Description:
  381.      The Shared Whois Project merges network data held by various
  382.      organizations.  The principal purpose of merging this data is to
  383.      find and resolve conflicting network information between the
  384.      databases.  The longterm goal of this project is to move away from
  385.      the current model of storing similar and/or duplicate network
  386.      information in multiple databases and to move to a X.500
  387.      distributed database model.  To this end, we are working on loading
  388.      the NSFNET network information into X.500 in anticipation of
  389.      participating in a distributed database trial.
  390.  
  391.  
  392.  
  393.  
  394. Integrated Directory Services Working Group                     [Page 7]
  395.  
  396. RFC 1491                 X.500 Advanced Usages                 July 1993
  397.  
  398.  
  399.    Full Description:
  400.      The Shared Whois Project is a collection of programs and shell
  401.      scripts which collectively merges the network data held by each of
  402.      the participating organizations.  Currently this includes Merit,
  403.      the RIPE-NCC and the InterNIC.  The principal purpose of merging
  404.      this vast quantity of data is to find and resolve conflicting
  405.      network information between the various databases.  It is our
  406.      intent to merge this data bi-weekly and thus rapidly reach, and
  407.      thereafter maintain, a stable set of commonly held network
  408.      information.
  409.  
  410.      While there is a common set of information all three of the
  411.      participants hold in their various databases, additional
  412.      information unique to the function of each organization is also
  413.      held.  Furthermore, the resulting set of data created by the merger
  414.      holds only one entry per network without attempting to combine the
  415.      variations.  Thus, each entry includes a listing of all databases
  416.      found to contain information for that network as well as all
  417.      databases found to be in conflict with the entry held in the
  418.      resultant set.
  419.  
  420.      The longterm goal of this project is to move away from the current
  421.      model of storing similar and/or duplicate network information in
  422.      multiple databases and to move to a X.500 distributed database
  423.      model.  To this end, Merit is working to load the NSFNET network
  424.      information into X.500 in anticipation of participating in a trial
  425.      with the InterNIC and others on the road to a globally distributed
  426.      database model.
  427.  
  428. 2.2.4.2 EARN's Network Directory
  429.  
  430.    Application Name: Ditnet/EARN Network Directory
  431.  
  432.    Date Received: 7/7/1992
  433.  
  434.    Date Last Verified: 7/7/1992
  435.  
  436.    Author(s):
  437.      Peter Sylvester
  438.  
  439.    Company or Institution:
  440.      Inria Rocquencourt - France
  441.  
  442.    e-mail address for more information:
  443.      peter.sylvester@inria.fr
  444.  
  445.    Type: FREE (data owned by EARN/Bitnet)
  446.  
  447.  
  448.  
  449.  
  450. Integrated Directory Services Working Group                     [Page 8]
  451.  
  452. RFC 1491                 X.500 Advanced Usages                 July 1993
  453.  
  454.  
  455.    Short Description:
  456.      The EARN/Bitnet Network database consists of descriptions of all
  457.      participating members, network nodes, adminstrators, and topology
  458.      information. This database commonly known as BITEARN NODES is being
  459.      made available through x.500.
  460.  
  461.    Full Description:
  462.      A full description of the contents of the EARN/Bitnet database
  463.      can be found in some EARN internal document which is available
  464.      as a file BITEARN NODES from any NETSERV in EARN/Bitnet. The
  465.      contents of this file is mapped into an X.500 subtree containing
  466.      descriptions of network nodes, adminstrational personnel, and
  467.      topology information.
  468.  
  469.      The first version of the directory subtree will be created using a
  470.      simple textual mapping to a flat directory tree using private
  471.      attributes.
  472.  
  473. 2.2.5 Soft Pages
  474.  
  475.    Application Name: Soft Pages
  476.  
  477.    Date Received: 9/25/1992
  478.  
  479.    Date Last Validated: 9/25/1992
  480.  
  481.    Author(s):
  482.      Thomas Johannsen
  483.      Glenn Mansfield
  484.  
  485.    Company or Institution:
  486.      AIC Systems Laboratory,
  487.      Tohoku University Sendai
  488.  
  489.    e-mail address for more information:
  490.      spp-support@aic.co.jp
  491.  
  492.    Type:
  493.      Intended for public distribution, not yet public
  494.  
  495.    FTP address: <none>
  496.  
  497.    Short Description:
  498.      A file name look-up services for anonymous FTP servers, provides ls
  499.      -lR information and FTP server address. Additionally, the nearest
  500.      FTP site (from user's site) which holds the requested file is
  501.      chosen.
  502.  
  503.  
  504.  
  505.  
  506. Integrated Directory Services Working Group                     [Page 9]
  507.  
  508. RFC 1491                 X.500 Advanced Usages                 July 1993
  509.  
  510.  
  511.    Full Description:
  512.      With the growing of number and size of electronic archives for
  513.      documents, programs and the like, the problem of finding and
  514.      retrieving a specific file becomes more and more complex.
  515.      Furthermore, bandwidth in the Internet is still limited. Users
  516.      should be encouraged and supported to do local FTP sessions as often
  517.      as possible instead of getting everything from the other end of the
  518.      world (i.e., the net).
  519.  
  520.      The Soft Pages Project combines an Archie-like file look-up service
  521.      with network configuration knowledge.  A dedicated User Agent gives
  522.      a suggestion how to retrieve a document in a network traffic
  523.      optimized manner.
  524.  
  525.      Basically, Directory information introduced by Soft Pages falls
  526.      into two parts: A file information part and a network configuration
  527.      part.
  528.  
  529.      The file information part describes objects and attributes for file
  530.      servers and their contents. For each file server, names and
  531.      attributes of its files are stored and updated periodically. This
  532.      provides global access to Archie-like information for all
  533.      registered file servers and, furthermore, opens the way to store
  534.      document description together with the file name.  Thus, document
  535.      search is not restricted to file name matches but might be run for
  536.      keywords as well.
  537.  
  538.      The network configuration part provides information on networks
  539.      (subnetworks), nodes and lines in the Internet. Furthermore, IP
  540.      numbers can be mapped to network and node objects. In order to
  541.      evaluate file server sites, Internet (site to site) connections are
  542.      given a cost index and then alternatives are compared by their cost
  543.      index. Cost index is a calculated parameter representing properties
  544.      of a connection like speed, average traffic, charges etc. where
  545.      values for the latter are hold as attributes to line objects.
  546.  
  547.      If a document is stored at two or more sites, the site with the
  548.      lowest cost index (which naturally will be the "nearest" in network
  549.      terms) will be chosen for retrieval.  A Soft Pages User Agent
  550.      basically interacts with the Directory for finding a pointer to the
  551.      "best" copy of a file wanted by a user.
  552.  
  553. 2.2.6 X-Tel
  554.  
  555.    Application Name: X-Tel's advanced applications
  556.  
  557.    Date received: 7/1/1992
  558.  
  559.  
  560.  
  561.  
  562. Integrated Directory Services Working Group                    [Page 10]
  563.  
  564. RFC 1491                 X.500 Advanced Usages                 July 1993
  565.  
  566.  
  567.    Date last verified: 7/1/1992
  568.  
  569.    Author(s):
  570.      Colin Robbins
  571.      Julian Onions
  572.      Graeme Lunt
  573.  
  574.    Company or Institution: X-Tel Services Ltd.
  575.  
  576.    e-mail address for more information:
  577.      x500@xtel.co.uk
  578.  
  579.    Type:
  580.      Commercial Products / Ideas
  581.  
  582.    Short Description:
  583.      1) Product Information.  Products that have DUA facilites built in
  584.      have a "latest info" button or other request method.  When
  585.      "pressed" a well known node below the X-Tel part of the tree is
  586.      read.  The attributes contain descriptions of the latest version of
  587.      the software, new features etc.  If you decide you would like the
  588.      new version, a second read obtains the information required for a
  589.      template order form.
  590.  
  591.      2) BUG Status.  As above, but obtains details of known bugs in the
  592.      version of software you are running.  (If only we could find a way
  593.      of putting fixes in, and automatically updating the software
  594.      itself!)
  595.  
  596.      3) X-Terms.  We have a conferencing product, allowing X users to
  597.      "talk" and share windows.  The problem is identifying which X
  598.      Terminal device a particular user is currently on.  One solution we
  599.      are using is modify a users directory entry during login to say
  600.      which X display they have logged into.  The conference can the
  601.      query the directory, and open windows on the appropriate device.
  602.      The directory is also used to store details of current conferences,
  603.      so new delegates can join the conference easily.
  604.  
  605.      4) Organisation browsing.  There are a rich set of attributes about
  606.      people and their roles stored in the directory.  We have a special
  607.      purpose DUA that exploits this information, and presents
  608.      information on who manages who, who is secretary for who etc.  This
  609.      is very useful when combined with the search ACL mechanism defined
  610.      in OSI-DS 21 as different views can be given to different
  611.      catergories of users.
  612.  
  613.      5) MHS use of directory.  The directory is use to store MHS routing
  614.      information (as per the MHS DS working group documents)
  615.  
  616.  
  617.  
  618. Integrated Directory Services Working Group                    [Page 11]
  619.  
  620. RFC 1491                 X.500 Advanced Usages                 July 1993
  621.  
  622.  
  623.      6) Mail Lists.  Details of mailing lists are stored in the
  624.      directory.  With careful use of access control, users can be given
  625.      access so that they can subscribe and unsubscribe themselves
  626.      to/from a list.
  627.  
  628.      7) Details of restuarants in the Nottingham area are stored in the
  629.      directory!
  630.  
  631.      8) We plan to use the directory as a rendevuz for a multi-user
  632.      adventure game.  Each "room" will be a different entry, and modify
  633.      operations will be used to pick up and put down objects!
  634.  
  635.      The next two are "advanced" features of our DUA, they may not be
  636.      considered relevant to this document!
  637.  
  638.      9) Templates.  The directory is used to store template entries.
  639.      Our DUA then uses this template when adding new users.  Very
  640.      useful, as a number of default attributes can be set.
  641.  
  642.      10) Editors.  Special purpose editors for a number of complex
  643.      attribute syntaxes are built in to our DUAs.  This includes QUIPU
  644.      ACLs, and X.400 OR Addresses.
  645.  
  646. 2.2.7 Xerox Clearinghouse
  647.  
  648.    Application Name: Clearinghouse Interface
  649.  
  650.    Date Received: 7/1/1992
  651.  
  652.    Date Last Validated: 7/1/1992
  653.  
  654.    Author(s):
  655.      Margaret Avino
  656.  
  657.    Company or Institution:
  658.      Xerox Corporation
  659.  
  660.    e-mail address for more information
  661.      mavin.cin_ops@xerox.com
  662.  
  663.    Type:
  664.      Early Design/Implementation stages
  665.  
  666.    Short Description:
  667.      X.500 DSA interface to XNS (Xerox Network Services) Clearinghouse
  668.      directory to provide access to Xerox Corporation's Clearinghouse via
  669.      X.500 DUAs.
  670.  
  671.  
  672.  
  673.  
  674. Integrated Directory Services Working Group                    [Page 12]
  675.  
  676. RFC 1491                 X.500 Advanced Usages                 July 1993
  677.  
  678.  
  679.    Full Description:
  680.      Xerox uses the XNS network protocol suite to provide Mail, Filing,
  681.      Directory, Authentication, etc. network services for the installed
  682.      based of 45,000+ Xerox workstations.  The Directory is based on the
  683.      XNS Clearinghouse protocol which is similar to X.500 in that it
  684.      contains objects which have properties (attributes) and is a fully
  685.      distributed, replicatable directory.  The searching capabilities of
  686.      the Clearinghouse protocol are not as robust as the X.500 search
  687.      operation and the physical structure of the original database is
  688.      not amenable to complex searches as it could be if it were stored
  689.      in a relational database.
  690.  
  691.      The first piece of this project is to transfer the data into an
  692.      Oracle relational database and create a new Clearinghouse server
  693.      which accesses the oracle database and is a full fledged member of
  694.      the Clearinghouse, sending and receiving updates to other servers
  695.      using the XNS Clearinghouse protocol.  This will allow powerful SQL
  696.      queries to be performed on the data which will provide some very
  697.      desired functionality such as: list all of the Distribution Lists
  698.      of which this name is a member.
  699.  
  700.      To build on the new database, we are probing the implementation of
  701.      an X.500 DSA interface to the Oracle Clearinghouse Directory.  This
  702.      would allow X.500 DUAs to access the data and utilize the powerful
  703.      search operations.  It will require the definition of one or more
  704.      new object classes and several new attributes and some thought
  705.      about the appropriate schema.
  706.  
  707. 2.2.8 X.500 Sendmail
  708.  
  709.    Application Name: X.500 Sendmail
  710.  
  711.    Date Received: 9/25/1992
  712.  
  713.    Date Last Verified: 9/25/1992
  714.  
  715.    Author(s):
  716.      Tim Howes
  717.  
  718.    Company or Institution:
  719.      University of Michigan
  720.  
  721.    e-mail address for more information:
  722.      x500@umich.edu
  723.  
  724.    Type:
  725.      FREE
  726.  
  727.  
  728.  
  729.  
  730. Integrated Directory Services Working Group                    [Page 13]
  731.  
  732. RFC 1491                 X.500 Advanced Usages                 July 1993
  733.  
  734.  
  735.    FTP address: terminator.cc.umich.edu
  736.  
  737.    Directions to obtain product:
  738.      get x500/sendmail-5.65.x500.tar.Z
  739.  
  740.    Short Description:
  741.      Modifications to sendmail-5.65 to do X.500 lookups.
  742.  
  743.    Full Description:
  744.      We have modified sendmail-5.65 so that it does X.500 lookups,
  745.      returning the value of a user's rfc822Mailbox attribute. It
  746.      handles multiple matches by sending a message containing the
  747.      choices back to the sender.  If the user has no email address in
  748.      X.500, the sender is sent a message containing postal and phone
  749.      information on the user. Both exact and approximate matching is
  750.      supported.
  751.  
  752. 2.2.9 Transparent ODA Conversion
  753.  
  754.    Application Name: Transparent ODA Conversion
  755.  
  756.    Date Received: 7/16/1992
  757.  
  758.    Date Last Verified: 7/16/1992
  759.  
  760.    Author(s):
  761.      MacFarland Hale (MITRE Open Systems Group)
  762.  
  763.    Company or Institution:
  764.      The MITRE Corporation
  765.  
  766.    e-mail address for more information:
  767.      machale@mitre.org
  768.  
  769.    Type:
  770.      Not Yet Available
  771.  
  772.    Short Description:
  773.      Plan to use X.500 in conjunction with X.400 and Open Document
  774.      Architecture (ODA) to provide transparent translation of compound
  775.      documents between a sender and one or more recipients.
  776.  
  777.    Full Description:
  778.      In the future, MITRE would like to combine X.500, X.400 and Open
  779.      Document Architecture (ODA) to automate the conversion of compound
  780.      documents in such a way that the users need not know about ODA or
  781.      even that the conversion is taking place.  This will require new
  782.      and/or updated X.400 products.
  783.  
  784.  
  785.  
  786. Integrated Directory Services Working Group                    [Page 14]
  787.  
  788. RFC 1491                 X.500 Advanced Usages                 July 1993
  789.  
  790.  
  791.      A preferred compound document format (e.g., Microsoft Word,
  792.      FrameMaker, etc.)  for each user is stored in the X.500 directory.
  793.      Each X.400 Message Transfer Agent (MTA) host also houses converters
  794.      between each such format and the Open Document Interchange Format
  795.      (ODIF).
  796.  
  797.      A user (sender) creates a document with his or her preferred
  798.      compound document editor.  Ideally, the editor software will have a
  799.      link (e.g., button or pull-down menu) to the X.400 User Agent (UA).
  800.      The user invokes the X.400 UA (either using this link, or outside
  801.      of the editor software) to send the document as an X.400 message to
  802.      one or more recipients.  Next, the document may need to be
  803.      converted to ODIF, and this may be done in one of two ways.
  804.  
  805.      Preferably, the X.400 MTA will be responsible for the ODIF
  806.      conversion.  The UA must somehow be told what format the original
  807.      document is in.  This may be done via the UA invocation from inside
  808.      the editor, via a UA configuration file, by examining the filename
  809.      extension, etc.  It then tags the document to indicate the
  810.      document's original format using one of the body parts:
  811.      "Bilaterally Defined" (body part 14), "Nationally Defined" (body
  812.      part 7) or "Externally Defined" (body part 15).  The UA then sends
  813.      the message, and the MTA interprets the tag to determine the
  814.      document's format.
  815.  
  816.      For messages internal to MITRE, the MTA will look up the
  817.      recipient's preferred document format.  If it is different than the
  818.      sender's format, the MTA calls the appropriate ODIF converter and
  819.      sends the message.  If the recipient's preferred format is the same
  820.      as that of the document being sent, then no conversion is
  821.      performed.  For messages going outside MITRE, the document is
  822.      always converted to ODIF.  The user may prevent this by specifying
  823.      that the enclosed document is not to be converted, in which case
  824.      the UA simply sends the document in binary form with no special
  825.      tag.
  826.  
  827.      Alternatively, the UA may do the conversion.  As above, the UA must
  828.      be told the document's original format.  The UA may then call the
  829.      appropriate local ODIF converter, and then send the message.  There
  830.      are some disadvantages to this approach:
  831.  
  832.        1) ODIF converters must be purchased for and maintained on many
  833.           more hosts;
  834.  
  835.        2) the document is always converted to ODIF (unless the UA
  836.           accesses the directory, but...);
  837.  
  838.        3) conversion overhead could be traumatic on a small PC.
  839.  
  840.  
  841.  
  842. Integrated Directory Services Working Group                    [Page 15]
  843.  
  844. RFC 1491                 X.500 Advanced Usages                 July 1993
  845.  
  846.  
  847.      At each recipient host, the X.400 MTA catches the incoming message,
  848.      recognizing the contents as ODIF.  It then looks up the recipients'
  849.      preferred compound document formats, calls the appropriate
  850.      converters to translate the contents, and then delivers the
  851.      messages to the recipients.  If the incoming message contains one
  852.      of the format tags described above, then no conversion is performed
  853.      (since the document is not in ODIF).
  854.  
  855.      Please note that MITRE is a not-for-profit organization.  We will
  856.      not produce commercial products to support this scenario, but we
  857.      are anxious to encourage and work with companies interested in
  858.      doing so.
  859.  
  860. 2.2.10 X.500 and the WHOIS protocol
  861.  
  862.    Application Name: Phone Book
  863.  
  864.    Date Received: 7/15/1992
  865.  
  866.    Date Last Verified: 7/15/1992
  867.  
  868.    Author(s):
  869.      Steven Schoch
  870.  
  871.    Company or Institution:
  872.      NASA Ames Research Center
  873.  
  874.    e-mail address for more information:
  875.      schoch@sheba.arc.nasa.gov
  876.  
  877.    Type:
  878.      FREE, see Steve
  879.  
  880.    Short Description:
  881.      On-line edition of our phone book, using X.500 for storage and
  882.      retrieval.
  883.  
  884.    Full Description:
  885.      Phone Book is a user application which communicates using the
  886.      Internet WHOIS protocol.  It is listed in the Internet Resources
  887.      Guide as such.  The latest incarnation, however, does not make use
  888.      of a flat file -- it gets information from a DUA that performs
  889.      conversions between information received via DAP and the format that
  890.      users expect to get back from our Phone Book queries.  The change to
  891.      X.500 has allowed us to supply additional data such as E-mail
  892.      address which do not normally appear in the phone book.  The fields
  893.      supplied in response to a query include:
  894.  
  895.  
  896.  
  897.  
  898. Integrated Directory Services Working Group                    [Page 16]
  899.  
  900. RFC 1491                 X.500 Advanced Usages                 July 1993
  901.  
  902.  
  903.            Name
  904.            Telephone Number
  905.            Mail Stop
  906.            Office Number
  907.            Organizational Affiliation (either a NASA organization code
  908.                    or a contractor name)
  909.            E-mail address
  910.  
  911.    Queries may be made on any of the fields specified, with the office
  912.    being divided into building and room components.  A sample lookup
  913.    might be:
  914.  
  915.    trident:297-->phbook yee
  916.    Name                        Phone    M/S     Office    Organization
  917.    --------------------------- -------- ------- --------- ------------
  918.    Arnold M. Yee                 4-4315 258-6   N258/134  COMPSCICOR
  919.    Cindy Yee                            226-3   N226/105  CALSPAN
  920.                                         cyee@ames.arc.nasa.gov
  921.    David H. Yee                  4-4106 213-8   N213/256  EEF
  922.                                         david_yee@qmgate.arc.nasa.gov
  923.    Dr. Helen M C. Yee            4-4769 202A-1  N202A/216 RF
  924.    Harry Yee                     4-6557 213-2   N213/101F EES
  925.    Peter Edmond Yee              4-3812 233-18  N233/240  EDC
  926.                                         yee@atlas.arc.nasa.gov
  927.    Robert Yee                    4-4122 T041-3  TA20/155  SFA
  928.                                         robert_yee@qmgate.arc.nasa.gov
  929.  
  930. 2.2.11 X.400 table handling
  931.  
  932.    Application Name: X.400 table handling
  933.  
  934.    Date Received: 7/15/1992
  935.  
  936.    Date Last Verified: 7/15/1992
  937.  
  938.    Author(s):
  939.      Julian Onions
  940.      Colin Robbins
  941.  
  942.    Company or Institution:
  943.      X-Tel Service Limited,
  944.      Nottingham, England
  945.  
  946.    e-mail address for more information:
  947.      jpo@xtel.co.uk
  948.  
  949.    Type:
  950.      FREE, not yet available to the general public
  951.  
  952.  
  953.  
  954. Integrated Directory Services Working Group                    [Page 17]
  955.  
  956. RFC 1491                 X.500 Advanced Usages                 July 1993
  957.  
  958.  
  959.    Short Description:
  960.      Implementation of the work of the IETF MHS-DS group. The goal is to
  961.      put X.400 tables into X.500 in order to facilitate gateway and
  962.      routing functions.
  963.  
  964.    Full Description:
  965.      See the Internet drafts for MHS-DS. NASA Ames Research Center is
  966.      participating in the testing and development of the next release of
  967.      the PP message handling software. The latest update (alpha test)
  968.      contains usage of X.500 by X.400 for RFC 822<->X.400 gatewaying, as
  969.      well as hooks for X.400 intelligent routing. Use of X.500 to
  970.      eliminate static tables will greatly improve the ability to
  971.      maintain the information necessary for mail gatewaying and routing,
  972.      while making it easier to keep this data current and well
  973.      distributed.
  974.  
  975. 3.  Security Considerations
  976.  
  977.    Security issues are not discussed in this memo.
  978.  
  979. 4.   Authors' Addresses
  980.  
  981.    Chris Weider
  982.    2901 Hubbard, Pod G
  983.    Ann Arbor, MI 48105
  984.  
  985.    Phone: (313) 747-2730
  986.    EMail: clw@merit.edu
  987.  
  988.  
  989.    Russ Wright
  990.    Lawrence Berkeley Laboratory
  991.    1 Cyclotron Road
  992.    Berkeley, CA 94720
  993.  
  994.    Phone: (415) 486-6965
  995.    EMail: wright@lbl.gov
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Integrated Directory Services Working Group                    [Page 18]
  1011.  
  1012.