summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1491.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1491.txt')
-rw-r--r--doc/rfc/rfc1491.txt1011
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc1491.txt b/doc/rfc/rfc1491.txt
new file mode 100644
index 0000000..67cb294
--- /dev/null
+++ b/doc/rfc/rfc1491.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+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:
+
+ - no automatic update of data (information accuracy)
+ - no global availability (place independency)
+ - no permanent availability (time independency)
+ - no inter-provider service (service integration).
+
+ X.500 may serve as a vehicle to overcome these drawbacks as
+ follows: The public transport providers store the time-table
+ information in a standardized format on locally managed DSAs. There
+ is some kind of special purpose DUA which (1) queries the user for
+ the input parameters (date, time, source and destination station)
+ then (2) searches for the relevant paths by querying the involved
+ DSAs and (3) displays the resulting time-table to the user.
+
+ In a diploma thesis a student is developing a new data model which
+ supports easy selection of source and destination station as well
+ as fast exploring of the time-table information. He is implementing
+ a prototype application onto an existing DUA interface (based on
+ HyperCard and running on Apple Macintosh) which is connected to the
+ world-wide X.500 pilot service over DIXIE protocol. In order to
+ test the prototype application the time-table information of the
+ Swiss national public transport company and of most of the regional
+ providers around the city of Zurich is included under the branch:
+ c=CH;o=ETH Zurich.
+
+2.2.2 Pre-Message Security Protocol
+
+ Application Name:
+ Defense Message System Directory
+
+ Date Recieved: 7/1/1992
+
+
+
+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]
+ \ No newline at end of file