rfc1430.txt

<VC++网络游戏建摸与实现>源代码

Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                    [Page 5]

RFC 1430                     X.500 Strategy                February 1993


   The lower parts of the hierarchy will, in general, be delegated to
   organizations who will have control over Name Assignment in that part
   of the tree. There is no reason to mandate how to assign this
   hierarchy, although it is appropriate to give guidelines. Proposed
   solutions to assignment of namespace are given in [BHK92].

   In North America, there is an alternative approach being developed by
   the North American Directory Forum (NADF), which leverages existing
   registration mechanisms [For91]. It is not yet clear what form a
   final North American Directory Service will take. It is expected that
   similar initiatives will be taken in other places, such as Europe.
   For the Internet, the Internet Society (ISOC) has been suggested as a
   possible Naming Authority.

   A discussion of the main issues involved with representing the Real
   World in the Directory Service is part of the work undertaken by the
   IETF OSI DS Working Group.

   The core of the Internet Directory will therefore come to exist of a
   country based structure with different national naming schemes below
   the countries.  It is clearly desirable that the Internet Directory
   Service follows any evolving national and international hierarchies.
   However, this should not be allowed to cause undue delay. The
   strategy proposed is to proceed with name assignment as needed, and
   to establish interim registration authorities where necessary, taking
   practical steps to be aligned with emerging national authorities
   wherever possible.

   It is suggested that the Internet Directory Service does two things:

   First, each national part of the Internet DIT namespace should be
   delegated to an appropriate organization, which will usually be in
   the country of question.  Second, the delegated organization should
   assign names for that country as part of the Internet Directory
   Service. This should be done in a manner which is appropriately
   aligned with any emerging local or national service, but does not
   unduly delay the deployment of the Internet Directory Service.  For
   most countries, this will fit in as a natural evolution of the early
   directory piloting, where operators of pilots have acted as interim
   name registration authorities.

5.  DIRECTORY INFRASTRUCTURE

   To provide access to the Internet Directory Service, an
   infrastructure has to be built. Although the technical components of
   an X.500 infrastructure are clear: DSAs (that hold the actual data)
   and DUAs (that allow users and applications to access the data), a
   lot more is needed for deployment of an Internet Directory Service.



Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                    [Page 6]

RFC 1430                     X.500 Strategy                February 1993


   The Integrated Directory Services (IDS) Working Group of the IETF is
   playing a key role in solving most of the issues that are related to
   the building of an appropriate infrastructure.

   Many of the issues cited in this section have come forward out of
   interim pilots that have been established on the Internet:

   PSI White Pages Pilot
      This is a pilot service which is operating X.500 on the Internet.
      In many ways it is operating as an Internet wide pilot.

   FOX
      Fielding Operational X.500, a project to explore the development
      and interoperability of X.500 implementations.

   Paradise (Piloting A ReseArch DIrectory Service in Europe)
      This project has been providing the necessary glue to hold the
      various national activities together [Par91].

5.1   Short Term Requirements

   -  Central Operations. There is a need for a number of operations
      to be managed as a service for the whole Internet. These services
      are:

      o A root DSA; containing the top-level of the DIT, has to be
        provided.  Currently, this root DSA is managed by the Paradise
        project.

      o Name assignment; Inserting names into the Directory, this has
        been discussed in section 4. This could be done in conjunction
        with the appropriate Registration Authority or by the
        Registration Authority.  In most cases it is likely to be the
        former, and mechanisms will need to be set up to allow
        organizations to get their names installed into the directory,
        either direct or through the registration authority.

      o Knowledge management; i.e., the information on "which DSA holds
        what part of the DIT, and how can that DSA be accessed". DSAs
        will be established by Organizations. There will be a need to
        centrally coordinate the management of the knowledge information
        associated with these DSAs. This is likely to be coupled to the
        name assignment.

      o Knowledge and Data replication; For the Directory to perform
        well, knowledge and data high up in the DIT must be
        significantly replicated. A service must be provided to make
        replicated information available to DSAs that need it.



Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                    [Page 7]

RFC 1430                     X.500 Strategy                February 1993


      It is suggested that for the time being, Paradise should be used
      as the initial basis for handling the top-level of the DIT and for
      provision of the central services. However, the services mentioned
      above need to be provided at a national level for every
      participating country in the Internet Directory Service. Whenever
      an organization starts a new country branch of the DIT in the
      Internet Directory Service the central operations will have to
      help out to make sure that these services will be properly
      installed on a national level.

   - An effective service will need to have sufficient implementations,
     in order to give full coverage over different hardware and software
     platforms, and to demonstrate openness. The recent Directory
     Information Services (pilot) Infrastructure Working Group's (DISI)
     Survey of Directory Implementations suggests that there will not be
     a problem here.  This provides a list of available X.500
     implementations and their capabilities [LW91].

   - An executive summary, necessary to convince the management of
     computer centers to invest manpower into setting up a X.500
     Directory Service.  This is provided by DISI [WR92].

   - Due to the possible different and rather independent structured
     namespaces that can be envisaged in the DIT for different purposes,
     DUAs will have to be "tuned intelligently" for the applications that
     they are used for.

   - To allow users easy access to the Internet Directory Service even
     from low powered workstations, a lightweight protocol has to be
     developed over TCP/IP. Already two private protocols that do this
     have been developed: The Michigan DIXIE protocol [HSB91] and the PSI
     Directory Assistance Service [Ros91]. The IETF OSI Directory
     Services Working Group (OSI-DS WG) is currently working on a
     standard lightweight protocol called LDAP.

   - Although the Internet Directory Service does not have to make any
     mandatory requirements about the use of lower layers, it is noted
     that the use of STD 35, RFC 1006 to allow use of OSI applications on
     top of TCP/IP is essential for deployment in the Internet. Other
     stacks like the ones using CLNS, CONS and X.25(80) will probably
     also be deployed in parts of the Internet. DSAs with different
     stacks will be linked through use of either application level relays
     (chaining) or Transport Service bridges.

   - There are multiple issues that are not dealt with (properly) in the
     X.500 standard and thus prevent the building of an Internet
     Directory service.  Intermediate solutions for these issues have to
     be established in an "open" way. The results will have to be



Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                    [Page 8]

RFC 1430                     X.500 Strategy                February 1993


     deployed as well as to be fed back into the relevant standard
     committees. The IETF OSI-DS WG deals with these issues. Section 7
     describes several of these issues.

   - Site support. The IETF IDS WG is looking at providing the necessary
     documentation to help with the provision of support for Directory
     users at participating sites.

5.2   Medium Term Requirements

   - Enhanced performance is necessary to allow for a real global usage;

   - The schema has to be extended to allow for various kinds of data,
     e.g.,:

      o  NIC data;
      o  Resource location;

   - Support for Internet Message Handling services (RFC-822, MIME and
     X.400).  This work is already undertaken by the IETF MHS-DS WG.

5.3   Long Term Requirements

   - To make sure that X.500 evolves into an operational service, it is
     essential to track its evolution, and to feed back into the
     evolution process.

   - Interface existing RDBMS into the Directory Service.

   - To increase the performance of the directory, and thereby making it
     useful for an even wider range of applications (e.g., policy based
     routing), a lightweight protocol for access and system usage is
     needed.

6.  DATAMANAGEMENT

   The whole of the Directory Infrastructure won't stand much chance
   without proper datamanagement of the data contained within the DIT.
   Procedures need to be established to assure a certain Level of
   Quality of the data contained in the DIT.

   Due to the very nature of X.500, the management of the data is
   distributed over various sources. This has the obvious advantage that
   the data will be maintained by the owner of the data. It does
   however, make it quite impossible to describe one single procedure
   for datamanagement.





Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                    [Page 9]

RFC 1430                     X.500 Strategy                February 1993


   For the Internet Directory Service, guidelines will have to be
   developed (by the IETF IDS WG), to help organizations that start with
   deployment of X.500 on how to manage data in their part of the DIT.
   The guidelines should describe a minimum level of quality that has to
   be supplied to make the service operational. The IETF OSI-DS WG will
   initiate a pilot on Quality of Service parameters in the Directory,
   that will be of use.

   Pilot datamanagement projects will have to be done (e.g., existing
   databases should be connected to the Internet Directory Service).
   Tools that are developed to achieve this should be made available to
   the Internet community for possible future use.

6.1   Legal Issues

   Most countries connected to the Internet have some sort of law that
   dictates how data on people can and cannot be made available. These
   laws deal with privacy and registration issues, and will differ from
   country to country.  It is suggested that each of the national
   organizations within the Internet that manages the Internet Directory
   Services master for that country, undertake some research as to the
   applicability of laws within that country on data made public through
   use of X.500.

   In the mean time, a general "User Bill of Rights" should be
   established to indicate what the proper use of the Internet Directory
   Service is. This "Bill of Rights" could be drafted by the IETF IDS
   WG.  As a basis, the NADF "User Bill of Rights" [For92] can be used.

7.  TECHNICAL ISSUES

   The IETF has established the OSI-DS WG. The major component of the
   initial work of this group is to establish a technical framework for
   deploying a Directory Service on the Internet, making use of the
   X.500 protocols and services [CCI88b].  This section describes the
   work already done by this working group, which has been implicitly
   focused on the technical infrastructure needed to deploy the Internet
   Directory service.

   The OSI Directory Standards do not yet contain sufficient specifics
   to enable the Internet Directory Service to be built. Full openness
   and interoperability are a key goal, so we may need Internet specific
   agreements, at least until the ISO standards are more complete. This
   section notes areas where the standards do not have sufficient
   coverage, and indicates the RFCs which have been written to overcome
   these problems.

   The work is being limited to (reasonably well) understood issues.



Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                   [Page 10]