rfc1491.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


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:
     [e-mail]

   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:
     [e-mail]

   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:
     [e-mail]

   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
                                        [e-mail]
   David H. Yee                  4-4106 213-8   N213/256  EEF
                                        [e-mail]
   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
                                        [e-mail]
   Robert Yee                    4-4122 T041-3  TA20/155  SFA
                                        [e-mail]

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:
     [e-mail]

   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: [phone]
   EMail: [e-mail]


   Russ Wright
   Lawrence Berkeley Laboratory
   1 Cyclotron Road
   Berkeley, CA 94720

   Phone: [phone]
   EMail: [e-mail]














Integrated Directory Services Working Group                    [Page 18]