From: Kurt Zeilenga Date: Thu, 27 Dec 2001 01:02:40 +0000 (+0000) Subject: Trim RFCs X-Git-Tag: LDBM_PRE_GIANT_RWLOCK~464 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=acf57308c12530ff44fcc9840cfe4a6ab5597fb8;p=openldap Trim RFCs --- diff --git a/doc/rfc/INDEX b/doc/rfc/INDEX index 445c10e626..358de929ba 100644 --- a/doc/rfc/INDEX +++ b/doc/rfc/INDEX @@ -2,14 +2,11 @@ This is an index of RFC contained in this directory: rfc1274.txt COSINE and Internet X.500 Schema (PS) rfc1279.txt X.500 and Domains (E) -rfc1308.txt Executive Intro to Directory Services - X.500 (FYI) -rfc1309.txt Technical Overview of Directory Services - X.500 (FYI) rfc1430.txt Plan for Deploying an Internet X.500 Directory Service (I) rfc1617.txt Naming and Structuring Guidelines for X.500 Directory Pilots (I) rfc1798.txt Connection-less LDAP (PS) rfc1823.txt LDAP C API (I) rfc2079.txt X.500 Attribute Type and an Object Class to Hold URIs (PS) -rfc2119.txt Key words (BCP) rfc2164.txt X.500/LDAP MIXER address mapping (PS) rfc2218.txt Common Schema for the Internet White Pages Service (PS) rfc2222.txt Simple Authentication and Security Layer (PS) diff --git a/doc/rfc/rfc1308.txt b/doc/rfc/rfc1308.txt deleted file mode 100644 index 88ac866a47..0000000000 --- a/doc/rfc/rfc1308.txt +++ /dev/null @@ -1,227 +0,0 @@ - - - - - - -Network Working Group C. Weider -Request for Comments: 1308 ANS -FYI: 13 J. Reynolds - ISI - March 1992 - - - Executive Introduction to Directory Services - Using the X.500 Protocol - -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 an Executive Introduction to Directory Services - using the X.500 protocol. It briefly discusses the deficiencies in - currently deployed Internet Directory Services, and then illustrates - the solutions provided by X.500. - - This FYI RFC is a product of the Directory Information Services - (pilot) Infrastructure Working Group (DISI). A combined effort of - the User Services and the OSI Integration Areas of the Internet - Engineering Task Force (IETF). - -1. INTRODUCTION - - The Internet is growing at a phenomenal rate, with no deceleration in - sight. Every month thousands of new users are added. New networks - are added literally almost every day. In fact, it is entirely - conceivable that in the future every human with access to a computer - will be able to interact with every other over the Internet and her - sister networks. However, the ability to interact with everyone is - only useful if one can locate the people with whom they need to work. - Thus, as the Internet grows, one of the limitations imposed on the - effective use of the network will be determined by the quality and - coverage of Directory Services available. - - Directory Services in this paper refers not only to the types of - services provided by the telephone companies' White Pages, but to - resource location, Yellow Pages services, mail address lookup, etc. - We will take a brief look at the services available today, and at the - problems they have, and then we will show how the X.500 standard - solves those problems. - - - - -DISI Working Group [Page 1] - -RFC 1308 Executive Intro to X.500 March 1992 - - -2. CURRENT SERVICES AND THEIR LIMITATIONS - - In the interests of brevity, we will only look at the WHOIS service, - and at the DNS. Each will illustrate a particular philosophy, if you - will, of Directory Services. - - The WHOIS service is maintained by the Defense Data Network Network - Information Center, or DDN NIC. It is currently maintained at GSI - for the IP portion of the Internet. It contains information about IP - networks, IP network managers, a scattering of well-known personages - in the Internet, and a large amount of information related - specifically to the MILNET systems. As the NIC is responsible for - assigning new networks out of the pool of IP addresses, it is very - easily able to collect this information when a new network is - registered. However, the WHOIS database is big enough and - comprehensive enough to exhibit many of the flaws of a large - centralized database. First, centralized location of the WHOIS - database causes slow response during times of peak querying activity, - storage limitations, and also causes the entire service to be - unavailable if the link to GSI is broken. Second, centralized - administration of the database, where any changes to the database - have to be mailed off to GSI for human transcription into the - database, increases the turnaround time before the changes are - propagated, and also introduces another source of potential error in - the accuracy of the information. These particular problems affect to - different degrees any system which attempts to provide Directory - Services through a centralized database. - - The Domain Name Service, or DNS, contains information about the - mapping of host and domain names, such as, "home.ans.net", to IP - addresses. This is done so that humans can use easily remembered - names for machines rather than strings of numbers. It is maintained - in a distributed fashion, with each DNS server providing nameservice - for a limited number of domains. Also, secondary nameservers can be - identified for each domain, so that one unreachable network will not - necessarily cut off nameservice. However, even though the DNS is - superlative at providing these services, there are some problems when - we attempt to provide other Directory Services in the DNS. First, the - DNS has very limited search capabilities. Second, the DNS supports - only a small number of data types. Adding new data types, such as - photographs, would involve very extensive implementation changes. - -3. THE X.500 SOLUTION - - X.500 is a CCITT protocol which is designed to build a distributed, - global directory. It offers the following features: - - * Decentralized Maintenance: - - - -DISI Working Group [Page 2] - -RFC 1308 Executive Intro to X.500 March 1992 - - - Each site running X.500 is responsible ONLY for its local part of - the Directory, so updates and maintenance can be done instantly. - - * Powerful Searching Capabilities: - X.500 provides powerful searching facilities that allow users to - construct arbitrarily complex queries. - - * Single Global Namespace: - Much like the DNS, X.500 provides a single homogeneous namespace - to users. The X.500 namespace is more flexible and expandable - than the DNS. - - * Structured Information Framework: - X.500 defines the information framework used in the Directory, - allowing local extensions. - - * Standards-Based Directory Services: - As X.500 can be used to build a standards-based directory, - applications which require directory information (e-mail, - automated resources locators, special-purpose directory tools) - can access a planet's worth of information in a uniform manner, - no matter where they are based or currently running. - - With these features alone, X.500 is being used today to provide the - backbone of a global White Pages service. There is almost 3 years of - operational experience with X.500, and it is being used widely in - Europe and Australia in addition to North America. In addition, the - various X.500 implementations add some other features, such as - photographs in G3-FAX format, and color photos in JPEG format. - However, as X.500 is standards based, there are very few - incompatibilities between the various versions of X.500, and as the - namespace is consistent, the information in the Directory can be - accessed by any implementation. Also, work is being done in providing - Yellow Pages services and other information resource location tasks - in the Directory. - - However, there are some limitations to the X.500 technology as it is - currently implemented. One price that is paid for the flexibility in - searching is a decline in the speed of the searching. This is because - a) searches over a part of the distributed namespace may have to - traverse the network, and some implementations cache all the - responses before giving them to the user, and b) some early - implementations performed search slowly anyway. A second problem with - the implementations is that for security reasons only a limited - amount of information is returned to the user; for example, if a - search turns up 1000 hits, only 20 or so are returned to the user. - Although this number is tunable, it does mean that someone with a big - search will have to do a lot of work. The performance of the - - - -DISI Working Group [Page 3] - -RFC 1308 Executive Intro to X.500 March 1992 - - - Directory, while increasing rapidly in the last two years, is still - not able to provide real-time directory services for such things as - routing protocols. However, work is being done to speed up service. - - The X.500 Directory is taking us closer to the day when we will - indeed have the entire world on our desktops, and X.500 will help - insure that we can find whom and what we need. - -4: FOR FURTHER INFORMATION - - For a more detailed technical introduction to X.500 and an extensive - bibliography, see "Technical Overview of Directory Services Using the - X.500 Protocol", by Weider, Reynolds, and Heker. This is available - from the NIC as FYI 14, RFC 1309. For a catalogue of X.500 - implementations, see "A Catalog of Available X.500 Implementations", - ed. Lang and Wright. This is available from the NIC as FYI 11, RFC - 1292. - -5: SECURITY CONSIDERATIONS - - Security issues are not discussed in this paper. - -6: AUTHORS' ADDRESSES - - Chris Weider - Advanced Network and Services, Inc. - 2901 Hubbard, G-1 - Ann Arbor, MI 48105-2437 - - Phone (313) 663-2482 - E-mail: weider@ans.net - - Joyce K. Reynolds - Information Sciences Institute - University of Southern California - 4676 Admirality Way - Marina del Rey, CA 90292 - - Phone: (310) 822-1511 - E-Mail: jkrey@isi.edu - - - - - - - - - - - -DISI Working Group [Page 4] - \ No newline at end of file diff --git a/doc/rfc/rfc1309.txt b/doc/rfc/rfc1309.txt deleted file mode 100644 index 123eb26ef7..0000000000 --- a/doc/rfc/rfc1309.txt +++ /dev/null @@ -1,899 +0,0 @@ - - - - - - -Network Working Group C. Weider -Request for Comments: 1309 ANS -FYI: 14 J. Reynolds - ISI - S. Heker - JvNC - March 1992 - - - Technical Overview of Directory Services - Using the X.500 Protocol - -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 an overview of the X.500 standard for people not - familiar with the technology. It compares and contrasts Directory - Services based on X.500 with several of the other Directory services - currently in use in the Internet. This paper also describes the - status of the standard and provides references for further - information on X.500 implementations and technical information. - - A primary purpose of this paper is to illustrate the vast - functionality of the X.500 protocol and to show how it can be used to - provide a global directory for human use, and can support other - applications which would benefit from directory services, such as - main programs. - - This FYI RFC is a product of the Directory Information Services - (pilot) Infrastructure Working Group (DISI). A combined effort of - the User Services and the OSI Integration Areas of the Internet - Engineering Task Force (IETF). - -1. INTRODUCTION - - As the pace of industry, science, and technological development - quickened over the past century, it became increasingly probable that - someone in a geographically distant location would be trying to solve - the same problems you were trying to solve, or that someone in a - geographically distant location would have some vital information - which impinged on your research or business. The stupendous growth - in the telecommunications industry, from telegraphs to telephones to - computer networks, has alleviated the problem of being able to - - - -DISI Working Group [Page 1] - -RFC 1309 Technical Overview of X.500 March 1992 - - - communicate with another person, PROVIDED THAT YOU KNOW HOW TO REACH - THEM. - - Thus, along with the expansion of the telecommunications - infrastructure came the development of Directory Services. In this - paper, we will discuss various models of directory services, the - limitations of current models, and some solutions provided by the - X.500 standard to these limitations. - -2 MODELS OF DIRECTORY SERVICES - -2.1 The telephone company's directory services. - - A model many people think of when they hear the words "Directory - Services" is the directory service provided by the local telephone - company. A local telephone company keeps an on-line list of the names - of people with phone service, along with their phone numbers and - their address. This information is available by calling up Directory - Assistance, giving the name and address of the party whose number you - are seeking, and waiting for the operator to search his database. It - is additionally available by looking in a phone book published yearly - on paper. - - The phone companies are able to offer this invaluable service because - they administer the pool of phone numbers. However, this service has - some limitations. For instance, you can find someone's number only if - you know their name and the city or location in which they live. If - two or more people have listings for the same name in the same - locality, there is no additional information which with to select the - correct number. In addition, the printed phone book can have - information which is as much as a year out of date, and the phone - company's internal directory can be as much as two weeks out of date. - A third problem is that one actually has to call Directory assistance - in a given area code to get information for that area; one cannot - call a single number consistently. - - For businesses which advertise in the Yellow Pages, there is some - additional information stored for each business; unfortunately, that - information is unavailable through Directory Assistance and must be - gleaned from the phone book. - -2.2 Some currently available directory services on the Internet. - - As the Internet is comprised of a vast conglomeration of different - people, computers, and computer networks, with none of the hierarchy - imposed by the phone system on the area codes and exchange prefixes, - any directory service must be able to deal with the fact that the - Internet is not structured; for example, the hosts foo.com and - - - -DISI Working Group [Page 2] - -RFC 1309 Technical Overview of X.500 March 1992 - - - v2.foo.com may be on opposite sides of the world, the .edu domain - maps onto an enormous number of organizations, etc. Let's look at a - few of the services currently available on the Internet for directory - type services. - -2.2.1 The finger protocol. - - The finger protocol, which has been implemented for UNIX systems and - a small number of other machines, allows one to "finger" a specific - person or username to a host running the protocol. This is invoked by - typing, for example, "finger clw@mazatzal.merit.edu". A certain set - of information is returned, as this example from a UNIX system finger - operation shows, although the output format is not specified by the - protocol: - - Login name: clw In real life: Chris Weider - Directory: /usr/clw Shell: /bin/csh - On since Jul 25 09:43:42 4 hours 52 minutes Idle Time - Plan: - Home: 971-5581 - - where the first three lines of information are taken from the UNIX - operating systems information and the line(s) of information - following the "Plan:" line are taken from a file named .plan which - each user modifies. Limitations of the fingerd program include: a) - One must already know which host to finger to find a specific person, - b) since primarily UNIX machines run fingerd, people who reside on - other types of operating systems are not locateable by this method, - c) fingerd is often disabled on UNIX systems for security purposes, - d) if one wishes to be found on more than one system, one must make - sure that all the .plan files are consistent, and e) there is no way - to search the .plan files on a given host to (for example) find - everyone on mazatzal.merit.edu who works on X.500. Thus, fingerd has - a limited usefulness as a piece of the Internet Directory. - -2.2.2 whois - - The whois utility, which is available on a wide of variety of - systems, works by querying a centralized database maintained at the - DDN NIC, which was for many years located at SRI International in - Menlo Park, California, and is now located at GSI. This database - contains a large amount of information which primarily deals with - people and equipment which is used to build the Internet. SRI (and - now GSI) has been able to collect the information in the WHOIS - database as part of its role as the Network Information Center for - the TCP/IP portion of the Internet. - - The whois utility is ubiquitous, and has a very simple interface. A - - - -DISI Working Group [Page 3] - -RFC 1309 Technical Overview of X.500 March 1992 - - - typical whois query look like: - - whois Reynolds - - and returns information like: - - Reynolds, John F. (JFR22) 532JFR@DOM1.NWAC.SEA06.NAVY.MIL - (702) 426-2604 (DSN) 830-2604 - Reynolds, John J. (JJR40) amsel-lg-pl-a@MONMOUTH-EMH3.ARMY.MIL - (908) 532-3817 (DSN) 992-3817 - Reynolds, John W. (JWR46) EAAV-AP@SEOUL-EMH1.ARMY.MIL - (DSN) 723-3358 - Reynolds, Joseph T. (JTR10) JREYNOLDS@PAXRV-NES.NAVY.MIL - 011-63-47-885-3194 (DSN) 885-3194 - Reynolds, Joyce K. (JKR1) JKREY@ISI.EDU (213) 822-1511 - Reynolds, Keith (KR35) keithr@SCO.CO (408) 425-7222 - Reynolds, Kenneth (KR94) (502) 454-2950 - Reynolds, Kevin A. (KR39) REYNOLDS@DUGWAY-EMH1.ARMY.MIL - (801) 831-5441 (DSN) 789-5441 - Reynolds, Lee B. (LBR9) reynolds@TECHNET.NM.ORG (505) 345-6555 - - a further lookup on Joyce Reynolds with this command line: - - whois JKR1 - - returns: - - Reynolds, Joyce K. (JKR1) JKREY@ISI.EDU - University of Southern California - Information Sciences Institute - 4676 Admiralty Way - Marina del Rey, CA 90292 - (310) 822-1511 - - Record last updated on 07-Jan-91. - - The whois database also contains information about Domain Name System - (DNS) and has some information about hosts, major regional networks, - and large parts of the MILNET system. - - The WHOIS database is large enough and comprehensive enough to - exhibit many of the flaws of a large centralized database: a) As the - database is maintained on one machine, a processor bottleneck forces - slow response during times of peak querying activity, even if many of - these queries are unrelated, b) as the database is maintained on one - machine, a storage bottleneck forces the database administrators to - severely limit the amount of information which can be kept on each - entry in the database, c) all changes to the database have to be - - - -DISI Working Group [Page 4] - -RFC 1309 Technical Overview of X.500 March 1992 - - - mailed to a "hostmaster" and then physically reentered into the - database, increasing both the turnaround time and the likelihood for - a mistake in transcription. - -2.2.3 The Domain Name System - - The Domain Name System is used in the Internet to keep track of host - to IP address mapping. The basic mechanism is that each domain, such - as merit.edu or k-12.edu, is registered with the NIC, and at time of - registration, a primary and (perhaps) some secondary nameservers are - identified for that domain. Each of these nameservers must provide - host name to IP address mapping for each host in the domain. Thus, - the nameservice is supplied in a distributed fashion. It is also - possible to split a domain into subdomains, with a different - nameserver for each subdomain. - - Although in many cases one uses the DNS without being aware of it, - because humans prefer to remember names and not IP addresses, it is - possible to interactively query the DNS with the nslookup utility. A - sample session using the nslookup utility: - - home.merit.edu(1): nslookup - Default Server: merit.edu - Address: 35.42.1.42 - - > scanf.merit.edu - Server: merit.edu - Address: 35.42.1.42 - - Name: scanf.merit.edu - Address: 35.42.1.92 - - > 35.42.1.92 - Server: merit.edu - Address: 35.42.1.42 - - Name: [35.42.1.92] - Address: 35.42.1.92 - - Thus, we can explicitly determine the address associated with a given - host. Reverse name mapping is also possible with the DNS, as in this - example: - - - - - - - - - -DISI Working Group [Page 5] - -RFC 1309 Technical Overview of X.500 March 1992 - - - home.merit.edu(2): traceroute ans.net - traceroute to ans.net (147.225.1.2), 30 hops max, 40 byte packets - 1 t3peer (35.1.1.33) 11 ms 5 ms 5 ms - 2 enss (35.1.1.1) 6 ms 6 ms 6 ms - ................. - 9 192.77.154.1 (192.77.154.1) 51 ms 43 ms 49 ms - 10 nis.ans.net (147.225.1.2) 53 ms 53 ms 46 ms - - At each hop of the traceroute, the program attempts to do a reverse - lookup through the DNS and displays the results when successful. - - Although the DNS has served superlatively for the purpose it was - developed, i.e. to allow maintenance of the namespace in a - distributed fashion, and to provide very rapid lookups in the - namespace, there are, of course, some limitations. Although there has - been some discussion of including other types of information in the - DNS, to find a given person at this time, assuming you know where she - works, you have to use a combination of the DNS and finger to even - make a stab at finding her. Also, the DNS has very limited search - capabilities right now. The lack of search capabilities alone shows - that we cannot provide a rich Directory Service through the DNS. - -3: THE X.500 MODEL OF DIRECTORY SERVICE - - X.500 is a CCITT protocol which is designed to build a distributed, - global directory. It offers the following features: - - * Decentralized Maintenance: - Each site running X.500 is responsible ONLY for its local part - of the Directory, so updates and maintenance can be done instantly. - - * Powerful Searching Capabilities: - X.500 provides powerful searching facilities that allow users to - construct arbitrarily complex queries. - - * Single Global Namespace: - Much like the DNS, X.500 provides a single homogeneous namespace - to users. The X.500 namespace is more flexible and expandable - than the DNS. - - * Structured Information Framework: - X.500 defines the information framework used in the directory, - allowing local extensions. - - - - - - - - -DISI Working Group [Page 6] - -RFC 1309 Technical Overview of X.500 March 1992 - - - * Standards-Based Directory: - As X.500 can be used to build a standards-based directory, - applications which require directory information (e-mail, - automated resource locators, special-purpose directory tools) - can access a planet's worth of information in a uniform manner, - no matter where they are based or currently running. - -3.1 Acronym City, or How X.500 Works - - The '88 version of the X.500 standard talks about 3 models required - to build the X.500 Directory Service: the Directory Model, the - Information Model, and the Security Model. In this section, we will - provide a brief overview of the Directory and Information Models - sufficient to explain the vast functionality of X.500. - -3.1.1 The Information Model - - To illustrate the Information Model, we will first show how - information is held in the Directory, then we will show what types of - information can be held in the Directory, and then we will see how - the information is arranged so that we can retrieve the desired - pieces from the Directory. - -3.1.1.1 Entries - - The primary construct holding information in the Directory is the - "entry". Each Directory entry contains information about one object; - for example, a person, a computer network, or an organization. Each - entry is built from a collection of "attributes", each of which holds - a single piece of information about the object. Some attributes which - might be used to build an entry for a person would be "surname", - "telephonenumber", "postaladdress", etc. Each attribute has an - associated "attribute syntax", which describes the type of data that - attribute contains, for example, photo data, a time code, or a string - of letters and numbers. As an example, let's look at part of an entry - for a person. - - Entry for John Smith contains: - - attribute ---> surName= Smith <--- attribute value - |---> telephoneNumber= 999-9999 <--- attribute value - |---> title= Janitor <--- attribute value - ... - - The attribute syntax for the surName attribute would be - CaseIgnoreString, which would tell X.500 that surName could contain - any string, and case would not matter; the attribute syntax for the - telephoneNumber attribute would be TelephoneNumber, which would - - - -DISI Working Group [Page 7] - -RFC 1309 Technical Overview of X.500 March 1992 - - - specify that telephoneNumber could contain a string composed of - digits, dashes, parenthesis, and a plus sign. The attribute syntax - for the title attribute would also be CaseIgnoreString. A good - analogy in database terms for what we've seen so far might be to - think of a Directory entry as a database record, an attribute as a - field in that record, and an attribute syntax as a field type - (decimal number, string) for a field in a record. - -3.1.1.2 Object Classes - - At this point in our description of the information model, we have no - way of knowing what type of object a given entry represents. X.500 - uses the concept of an "object class" to specify that information, - and an attribute named "objectClass" which each entry contains to - specify to which object class(es) the entry belongs. - - Each object class in X.500 has a definition which lists the set of - mandatory attributes, which must be present, and a set of optional - attributes, which may be present, in an entry of that class. An given - object class A may be a subclass of another class B, in which case - object class A inherits all the mandatory and optional attributes of - B in addition to its own. - - The object classes in X.500 are arranged in a hierarchical manner - according to class inheritance; the following diagram shows a part of - the object class hierarchy. - - - - - - - - - - - - - - - - - - - - - - - - - -DISI Working Group [Page 8] - -RFC 1309 Technical Overview of X.500 March 1992 - - - _____________ - | | "top" has one mandatory - | top | attribute "objectClass", - |_____________| and nooptional attributes. - | | | - | | | every other object class is a - ________________| | | subclass of "top"... - | | ... - ______|________ _____|_______ - | | | |"organization" inherits one - | country | | organization |mandatory attribute from - |_______________| |_______________|"top", "objectClass"; adds one - more mandatory attribute "O" - "country" inherits one (for organization), and has - mandatory attribute from "top", many optional attributes. Any - "objectClass", adds one more subclass of "organization" - mandatory attribute "c" (for would inherit all of the - country), and has two optional mandatory and optional - attributes, "description" and attributes from "organization" - "searchGuide". Any subclass of including the attribute which - "country" would inherit all of the "organization" inherited - mandatory and optional attributes from "top". - of the "country" class, including - the attribute which "country" - inherited from "top". - - Figure 1. - - One major benefit of the object class concept is that it is in many - cases very easy to create a new object class which is only a slight - modification or extension of a previous class. For example, if I have - already defined an object class for "person" which contains a - person's name, phone number, address, and fax number, I can easily - define an "Internet person" object class by defining "Internet - person" as a subclass of "person", with the additional optional - attribute of "e-mail address". Thus in my definition of the "Internet - Person" object class, all my "person" type attributes are inherited - from "person". There are other benefits which are beyond the scope of - this paper. - -3.1.1.3 X.500's namespace. - - X.500 hierarchically organizes the namespace in the Directory - Information Base (DIB); recall that this hierarchical organization is - called the Directory Information Tree (DIT). Each entry in the DIB - occupies a certain location in the DIT. An entry which has no - children is called a leaf entry, an entry which has children is - called a non-leaf node. Each entry in the DIT contains one or more - - - -DISI Working Group [Page 9] - -RFC 1309 Technical Overview of X.500 March 1992 - - - attributes which together comprise the Relative Distinguished Name - (RDN) of that entry, there is a "root" entry (which has no - attributes, a special case) which forms the base node of the DIT. The - Distinguished Name of a specific entry is the sequence of RDNs of the - entries on the path from the root entry to the entry in question. A - diagram here will help to clarify this: - -Level of DIT Root RDN Distinguished Name - -root * nothing { } - / | \ -country (other / | \ -things at this / | \ c=us {c=us} -level) c=gb c=us c=ca - / | \ - / | \ - / | \ -organization o=SRI o=Merit o=DEC o=Merit {c=us, o=Merit} -(other things / | \ -at this level) / | \ - / | \ -Third level cn=Chris Weider cn=Chris Weider {c=us, o=Merit, - cn=Chris Weider} - - Figure 2: Building a DN from RDNs (adapted from a - diagram in the X.500 (88) Blue Book) - - Each entry in this tree contains more attributes than have been shown - here, but in each case only one attribute for each entry has been - used for that entry's RDN. As noted above, any entry in the tree - could use more than one attribute to build its RDN. X.500 also allows - the use of alias names, so that the entry {c=us, o=Merit, cn=Chris - Weider} could be also found through an alias entry such as {c=us, - o=SRI, ou=FOX Project, cn=Drone 1} which would point to the first - entry. - -3.1.2 The Directory Model - - Now that we've seen what kinds of information can be kept in the - Directory, we should look at how the Directory stores this - information and how a Directory users accesses the information. There - are two components of this model: a Directory User Agent (DUA), which - accesses the Directory on behalf of a user, and the Directory System - Agent, which can be viewed as holding a particular subset of the DIB, - and can also provide an access point to the Directory for a DUA. - - Now, the entire DIB is distributed through the world-wide collection - of DSAs which form the Directory, and the DSAs employ two techniques - - - -DISI Working Group [Page 10] - -RFC 1309 Technical Overview of X.500 March 1992 - - - to allow this distribution to be transparent to the user, called - "chaining" and "referral". The details of these two techniques would - take up another page, so it suffices to say that to each user, it - appears that the entire global directory is on her desktop. (Of - course, if the information requested is on the other side of the - world, it may seem that the desktop directory is a bit slow for that - request...) - -3.2 The functionality of X.500 - - To describe the functionality of X.500, we will need to separate - three stages in the evolution of X.500: 1) the 1988 standard, 2) - X.500 as implemented in QUIPU, and 3) the (proposed) 1992 standard. - We will list some of the features described in the 1988 standard, - show how they were implemented in QUIPU, and discuss where the 1992 - standard will take us. The QUIPU implementation was chosen because - a) it is widely used in the U.S. and European Directory Services - Pilot projects, and b) it works well. For a survey of other X.500 - implementations and a catalogue of DUAs, see [Lang]. - -3.2.1 Functionality in X.500 (88) - - There are a number of advantages that the X.500 Directory accrues - simply by virtue of the fact that it is distributed, not limited to a - single machine. Among these are: - - * An enormously large potential namespace. - Since the Directory is not limited to a single machine, many - hundreds of machines can be used to store Directory entries. - - * The ability to allow local administration of local data. - An organization or group can run a local DSA to master their - information, facilitating much more accurate data throughout - the Directory. - - The functionality built into the X.500(88) standard includes: - - * Advanced searching capabilities. - The Directory supports arbitrarily complex searches at an - attribute level. As the object classes a specific entry - belongs to is maintained in the objectClass attribute, this - also allows Directory searches for specific types of objects. - Thus, one could search the c=US subtree for anyone with a last - name beginning with S, who also has either a fax number in the - (313) area code or an e-mail address ending in umich.edu. - This feature of X.500 also helps to provide the basic - functionality for a Yellow Pages service. - - - - -DISI Working Group [Page 11] - -RFC 1309 Technical Overview of X.500 March 1992 - - - * A uniform namespace with local extensibility. - The Directory provides a uniform namespace, but local - specialized directories can also be implemented. Locally - defined extensions can include new object classes, new - attributes, and new attribute types. - - * Security issues. - The X.500 (88) standards define two types of security for - Directory data: Simple Authentication (which uses passwords), - and Strong Authentication (which uses cryptographic keys). - Simple authentication has been widely implemented, strong - authentication has been less widely implemented. Each of - these authentication techniques are invoked when a user or - process attempts a Directory operation through a DUA. - - In addition to the global benefits of the X.500 standard, there are - many local benefits. One can use their local DSA for company or - campus wide directory services; for example, the University of - Michigan is providing all the campus directory services through - X.500. The DUAs are available for a wide range of platforms, - including X-Windows systems and Macintoshes. - -3.2.2 Functionality added by QUIPU. - - Functionality beyond the X.500 (88) standard implemented by QUIPU - includes: - - * Access control lists. - An access control list is a way to provide security for each - attribute of an entry. For example, each attribute in a given - entry can be permitted for detect, compare, read, and modify - permissions based on the reader's membership in various groups. - For example, one can specify that some information in a given - entry is public, some can be read only by members of the - organization, and some can only be modified by the owner of - the entry. - - * Replication. - Replication provides a method whereby frequently accessed - information in a DSA other than the local one can be kept by - the local DSA on a "slave" basis, with updates of the "slave" - data provided automatically by QUIPU from the "master" data - residing on the foreign DSA. This provides alternate access - points to that data, and can make searches and retrievals - more rapid as there is much less overhead in the form or - network transport. - - - - - -DISI Working Group [Page 12] - -RFC 1309 Technical Overview of X.500 March 1992 - - -3.3 Current limitations of the X.500 standard and implementations. - - As flexible and forward looking as X.500 is, it certainly was not - designed to solve everyone's needs for all time to come. X.500 is not - a general purpose database, nor is it a Data Base Management System - (DBMS). X.500 defines no standards for output formats, and it - certainly doesn't have a report generation capability. The technical - mechanisms are not yet in place for the Directory to contain - information about itself, thus new attributes and new attribute types - are rather slowly distributed (by hand). - - Searches can be slow, for two reasons: a) searches across a widely - distributed portion of the namespace (c=US, for example) has a delay - which is partially caused by network transmission times, and can be - compounded by implementations that cache the partial search returns - until everyone has reported back, and b) some implementations are - slow at searching anyway, and this is very sensitive to such things - as processor speed and available swap space. Another implementation - "problem" is a tradeoff with security for the Directory: most - implementations have an administrative limit on the amount of - information which can be returned for a specific search. For - example, if a search returns 1000 hits, 20 of those might be - displayed, with the rest lost. Thus a person performing a large - search might have to perform a number of small searches. This was - implemented because an organization might want to make it hard to - "troll" for the organization's entire database. - - Also, there is at the moment no clear consensus on the ideal shape of - the DIT, or on the idea structure of the object tree. This can make - it hard to add to the current corpus of X.500 work, and the number of - RFCs on various aspects of the X.500 deployment is growing monthly. - - Despite this, however, X.500 is very good at what it was designed to - do; i.e., to provide primary directory services and "resource - location" for a wide band oftypes of information. - -3.4 Things to be added in X.500 (92). - - The 1988 version of the X.500 standard proved to be quite sufficient - to start building a Directory Service. However, many of the new - functions implemented in QUIPU were necessary if the Directory were - to function in a reasonable manner. X.500 (92) will include - formalized and standardized versions of those advances, including - - * A formalized replication procedure. - - * Enhanced searching capacities. - - - - -DISI Working Group [Page 13] - -RFC 1309 Technical Overview of X.500 March 1992 - - - * Formalization of access control mechanisms, including access - control lists. - - Each of these will provide a richer Directory, but you don't have to - wait for them! You can become part of the Directory today! - -4: WHAT X.500 CAN DO FOR YOU TODAY - -4.1 Current applications of X.500 - - X.500 is filling Directory Services needs in a large number of - countries. As a directory to locate people, it is provided in the - U.S. as the White Pages Pilot Project, run by PSI, and in Europe - under the PARADISE Project as a series of nation-wide pilots. It is - also being used by the FOX Project in the United States to provide - WHOIS services for people and networks, and to provide directories of - objects as disparate as NIC Profiles and a pilot K-12 Educators - directory. It is also being investigated for its ability to provide - resource location facilities and to provide source location for WAIS - servers. In fact, in almost every area where one could imagine - needing a directory service (particularly for distributed directory - services), X.500 is either providing those services or being expanded - to provide those services. - - In particular, X.500 was envisioned by its creators as providing - directory services for electronic mail, specifically for X.400. It is - being used in this fashion today at the University of Michigan: - everyone at the University has a unified mail address, e.g. - Chris.Weider@umich.edu. An X.500 server then reroutes that mail to - the appropriate user's real mail address in a transparent fashion. - Similarly, Sprint is using X.500 to administrate the address space - for its internal X.400 mail systems. - - Those of us working on X.500 feel that X.500's strengths lie in - providing directory services for people and objects, and for - providing primary resource location for a large number of online - services. We think that X.500 is a major component (though not the - only one) of a global Yellow Pages service. We would also like to - encourage each of you to join your national pilot projects; the more - coverage we can get, the easier you will be able to find the people - you need to contact. - - - - - - - - - - -DISI Working Group [Page 14] - -RFC 1309 Technical Overview of X.500 March 1992 - - -5. For Further Information - - For further information, the authors recommend the following - documents: - - Weider, C., and J. Reynolds, "Executive Introduction to Directory - Services Using the X.500 Protocol", FYI 13, RFC 1308, ANS, ISI, - March 1992. - - Lang, R., and R. Wright, Editors, "A Catalog of Available X.500 - Implementations", FYI 11, RFC 1292, SRI International, Lawrence - Berkeley Laboratory, January 1992. - - Barker, P., and S. Hardcastle-Kille, "The COSINE and Internet - X.500 Schema", RFC 1274, University College London, November 1991. - - Hardcastle-Kille, S., "Replication Requirements to provide an - Internet Directory using X.500", RFC 1275, University College - London, November, 1991. - - Hardcastle-Kille, S., "Replication and Distributed Operations - extensions to provide an Internet Directory using X.500", RFC - 1276, University College London, November 1991. - - Hardcastle-Kille, S., "Encoding Network Addresses to support - operation over non-OSI lower layers", RFC 1277, University College - London, November 1991. - - Hardcastle-Kille, S., " A string encoding of Presentation - Address", RFC 1278, University College London, November 1991. - - Hardcastle-Kille, S., "X.500 and Domains", RFC 1279, University - College London, November 1991. - -6. Security Considerations - - Security issues are discussed in section 3. - - - - - - - - - - - - - - -DISI Working Group [Page 15] - -RFC 1309 Technical Overview of X.500 March 1992 - - -7. Authors' Addresses - - Chris Weider - Advanced Network and Services, Inc. - 2901 Hubbard G-1 - Ann Arbor, MI 48105-2437 - - Phone (313) 663-2482 - E-mail: weider@ans.net - - - Joyce K. Reynolds - Information Sciences Institute - University of Southern California - 4676 Admirality Way - Marina del Rey, CA 90292 - - Phone: (310) 822-1511 - EMail: jkrey@isi.edu - - - Sergio Heker - JvNCnet - Princeton University - 6 von Neumann Hall - Princeton, NJ 08544 - - Phone: (609) 258-2400 - Email: heker@nisc.jvnc.net - - - - - - - - - - - - - - - - - - - - - - -DISI Working Group [Page 16] - \ No newline at end of file diff --git a/doc/rfc/rfc2119.txt b/doc/rfc/rfc2119.txt deleted file mode 100644 index e31fae47fd..0000000000 --- a/doc/rfc/rfc2119.txt +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - -Network Working Group S. Bradner -Request for Comments: 2119 Harvard University -BCP: 14 March 1997 -Category: Best Current Practice - - - Key words for use in RFCs to Indicate Requirement Levels - -Status of this Memo - - This document specifies an Internet Best Current Practices for the - Internet Community, and requests discussion and suggestions for - improvements. Distribution of this memo is unlimited. - -Abstract - - In many standards track documents several words are used to signify - the requirements in the specification. These words are often - capitalized. This document defines these words as they should be - interpreted in IETF documents. Authors who follow these guidelines - should incorporate this phrase near the beginning of their document: - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL - NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in - RFC 2119. - - Note that the force of these words is modified by the requirement - level of the document in which they are used. - -1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the - definition is an absolute requirement of the specification. - -2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the - definition is an absolute prohibition of the specification. - -3. SHOULD This word, or the adjective "RECOMMENDED", mean that there - may exist valid reasons in particular circumstances to ignore a - particular item, but the full implications must be understood and - carefully weighed before choosing a different course. - -4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that - there may exist valid reasons in particular circumstances when the - particular behavior is acceptable or even useful, but the full - implications should be understood and the case carefully weighed - before implementing any behavior described with this label. - - - - - -Bradner Best Current Practice [Page 1] - -RFC 2119 RFC Key Words March 1997 - - -5. MAY This word, or the adjective "OPTIONAL", mean that an item is - truly optional. One vendor may choose to include the item because a - particular marketplace requires it or because the vendor feels that - it enhances the product while another vendor may omit the same item. - An implementation which does not include a particular option MUST be - prepared to interoperate with another implementation which does - include the option, though perhaps with reduced functionality. In the - same vein an implementation which does include a particular option - MUST be prepared to interoperate with another implementation which - does not include the option (except, of course, for the feature the - option provides.) - -6. Guidance in the use of these Imperatives - - Imperatives of the type defined in this memo must be used with care - and sparingly. In particular, they MUST only be used where it is - actually required for interoperation or to limit behavior which has - potential for causing harm (e.g., limiting retransmisssions) For - example, they must not be used to try to impose a particular method - on implementors where the method is not required for - interoperability. - -7. Security Considerations - - These terms are frequently used to specify behavior with security - implications. The effects on security of not implementing a MUST or - SHOULD, or doing something the specification says MUST NOT or SHOULD - NOT be done may be very subtle. Document authors should take the time - to elaborate the security implications of not following - recommendations or requirements as most implementors will not have - had the benefit of the experience and discussion that produced the - specification. - -8. Acknowledgments - - The definitions of these terms are an amalgam of definitions taken - from a number of RFCs. In addition, suggestions have been - incorporated from a number of people including Robert Ullmann, Thomas - Narten, Neal McBurnett, and Robert Elz. - - - - - - - - - - - - -Bradner Best Current Practice [Page 2] - -RFC 2119 RFC Key Words March 1997 - - -9. Author's Address - - Scott Bradner - Harvard University - 1350 Mass. Ave. - Cambridge, MA 02138 - - phone - +1 617 495 3864 - - email - sob@harvard.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bradner Best Current Practice [Page 3] -