HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 09:24:13 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 25 Jun 1999 12:54:00 GMT ETag: "323f1c-94ab-37737be8" Accept-Ranges: bytes Content-Length: 38059 Connection: close Content-Type: text/plain Internet-Draft S. G. Judd Document: draft-judd-policy-ldap-schema-design-00.txt Microsoft Category: Informational June 1999 Expires:December 1999 Designing Directory Schemata for General Use Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document is intended to aid in the design of directory schemata for implementation on diverse directory services that support the LDAP [5] protocol as their primary access mechanism. It is not specific to any directory service implementation. Conventions used in this 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 [2]. S. G. Judd 1 Designing Directory Schemata for General Use June, 1999 Contents 1 Overview.........................................................2 2 Guiding Principals...............................................2 2.1 Start with a Good Information Design............................2 2.2 Keep it Simple..................................................3 2.3 Beware Hidden Assumptions.......................................3 2.4 Consider the Real World.........................................3 3 Information Design...............................................4 3.1 Directory Meta-model............................................4 3.1.1 Information Meta-model......................................4 3.1.2 Meta-schema.................................................5 4 Keep It Simple...................................................5 4.1 Designing the Implementation....................................5 4.1.1 Limitations of the LDAP Protocol............................5 4.1.2 Design Principles...........................................6 4.1.3 Avoiding Seductive Errors...................................7 5 Evaluating a Schema Design......................................13 5.1 Implementability...............................................13 5.2 Referential Integrity and Consistency..........................13 5.3 Scalability....................................................14 1 Overview Designing a "Good" directory schema is considered one of the hermetic arts by many, and perhaps rightly so. This document presents a set of practical guidelines to use in creating and evaluating a schema design to ensure that it is widely implementable, usable, and has a minimum of performance, manageability and scalability issues. 2 Guiding Principals 2.1 Start with a Good Information Design A directory service is an information service, and like other information services the key to a good implementation is a good information design. A schema is a rendition of an information model. Before attempting to design a schema, you must have a well- defined information model. You must be able to answer these questions: o What entities are represented in the model? o What are the attributes of those entities? o What are the relationships among the entities? o Who are the consumers of the model? S. G. Judd Informational Expires December, 1999 2 Designing Directory Schemata for General Use June, 1999 2.2 Keep it Simple The simpler the information model, the easier it is to render it as a directory schema. The model should be as simple as it can be without oversimplification. This is obviously highly subjective. The key is to avoid complexity for its own sake: given a known set of consumers for your model, do not add entities, attributes and relationships to the model that are not interesting or useful to the target consumers. When designing the schema that renders the information model keep the rendition as simple as possible, again avoiding complexity for it's own sake. 2.3 Beware Hidden Assumptions LDAP is a client access protocol, and nothing more. LDAP does not define the behavior of the underlying directory service. RFC 2251 [5] states that a server must not violate X.501 (93) or X.511 (93) in paragraph 3.3. This is much different from mandating conformance with either the referenced recommendations. Do not assume any behavior on the part of the directory service that is not directly in support of the LDAP protocol as explicitly specified in RFC 2251 and the related RFC's. Behavior defined in ISO/ITU recommendations, Internet Drafts, and Informational RFC's should all be considered suspect and excluded from your design unless you have decided that the dependency is acceptable and document it clearly. Note that introducing such a dependency will limit the usefulness of your schema to directory services that implement the specific features you have elected to require. 2.4 Consider the Real World The roadside of the information highway is littered with the rusting remains of products and standards whose design was correct in some academic sense but which failed to accommodate the needs of the world in which they lived. You must strive to avoid this fate by understanding the intended use for your schema and the barriers to entry that your schema must overcome for broad adoption. Above all else, your schema must be usable. Usability is largely in the eye of the user, which is why it is so important to know who that user will be, and what problems that user needs to solve. There are numerous aspects to usability. For a directory schema, the key aspects are o Fidelity - how well does the schema represent the information model, and how well does that model in turn represent the "real world" entities and relationships? o Implementability - how difficult is it to implement clients that use the schema? Is special semantic knowledge required on S. G. Judd Informational Expires December, 1999 3 Designing Directory Schemata for General Use June, 1999 the part of the client? Are the entities, their attributes, and the relationships among them well-documented, clear and easy to create and maintain? o Integrity - does the design recognize the existence of common distributed systems problems such as replication latency, system failure, network outages etc. that affect data integrity? A design that works "on paper" or in small-scale deployments may fail when deployed in a larger or more widely distributed environment due to data integrity problems. o Scalability - does the design scale well in terms of volume of data, number of clients and response time requirements? 3 Information Design A tenet of information modeling is that the model should be independent of any implementation. The model is a representation of entities, their attributes and the relationships among them in some context. A good model does not anticipate any particular implementation and implementation features should not "creep in" to the model during the information design process. A schema is a representation of an information model. Schemata must be implementable, as discussed above. This means that the information must be mapped onto the meta-models supported by the implementation platforms. A good mapping is one that balances the four usability attributes - fidelity, implementability, integrity, and scalability. 3.1 Directory Meta-model A directory service supports two meta-models: one for the schema and one for instance information, that is, instances of the classes and attributes defined in the schema. RFC's 2251 and 2256 [8] describe the information and schema meta-models in general terms. 3.1.1 Information Meta-model The LDAP information meta-model is extremely simple: an entry is composed of zero or more attributes as defined in the class schema object for the class of which the entry is an instance. The entry can be the parent of other entries, and the child of exactly one entry (the exception is the special entry "root" which has no parent). +--------------+1 1+-------+ 0..* +-----------+ | Class Schema |-ofClass-| Entry |/\-hasAttribute-| Attribute | +--------------+ +--| |\/ +-----------+ | +-------+ hasChild /\ | \/ +------+ 0..* S. G. Judd Informational Expires December, 1999 4 Designing Directory Schemata for General Use June, 1999 3.1.2 Meta-schema The basic LDAP meta-schema is likewise very simple. The schema defines attributes and classes. Attribute definitions are global. A class can reference attribute definitions by making them required (mustContain) or optional (mayContain). A class can be derived from another class. The subclass inherits the attributes of the superclass. All classes are derived from TOP, the special root class from which all classes are ultimately derived. In general terms, this is the model described by ITU X.501. Some servers that support the LDAP protocol may offer much richer schema models, but to gain the broadest reach a schema should not depend on anything more than that described here. +---------+ 0..* +-----------+ | Class |/\--mustContain--| Attribute | | Schema |\/ | Schema | | | 0..* | | 1 +-+ |/\--mayContain---| | | | |\/ +-----------+ | +---------+ subClassOf | 1 | | +------+ 4 Keep It Simple 4.1 Designing the Implementation A key point to remember about information models is that they are abstract. The model is not an implementation, any more than architect's plans are the finished building. "The map is not the territory" [6]. The model forms a basis for implementations. A directory schema is a representation of an information model. An implementation uses the schema and the semantics defined for the schema, that is, the meaning of the entities, attributes, and relationships expressed by the schema. Like the schema itself, the semantics must be as simple as they can be without oversimplification. 4.1.1 Limitations of the LDAP Protocol In mapping the information model to a schema suitable for exposure via the LDAP protocol you must keep the limitations of LDAP in mind. o Client Access Protocol - RFC 2251 et al. define a client access protocol, not a directory service or any other distributed information system. o No structures - entries exposed by LDAP are flat lists of attributes. There is no concept of structures or nesting of objects. S. G. Judd Informational Expires December, 1999 5 Designing Directory Schemata for General Use June, 1999 o No ordered sets - attributes in an entry may be multi-valued, but multi-valued attributes are unordered sets. RFC 2251 states that the client must not depend on the order of the attributes in a multi-valued set. This means that attempts to introduce structures with groups of multi-valued attributes will not work since there is no implied ordering of the attributes in each multi-value. o No rename safety - "Rename safety" is the ability of a directory service to maintain references to entries when the target of a reference is renamed. Rename safety is a feature of a directory service implementation, not the LDAP protocol. Some directory services will provide rename safety, others will not. A design should minimize dependence on distinguished names (DNs) to express relationships, since the DN of an object is subject to change. o No backlinking - "Backlinking" is the ability of a directory service to automatically maintain a "Backlink" on an entry that is referenced by another entry, typically by storing its DN. Backlinks can be a useful tool in determining who references an object, for example when you want to know who will be affected if you change it. Backlinks are a feature of a directory service implementation, not the LDAP protocol. Some directory services will provide backlinks, others will not. A design should not depend on DN references and backlinks to provide forward and backwards navigation. o No transactions - the LDAP protocol does not expose transacted updates in any way. The LDAP protocol provides a mechanism to create, modify, or delete a single entry. There is no concept of "committing" or "aborting" a set of updates. A change applied to an entry is immediately visible to other users of the directory. 4.1.2 Design Principles The best designs are often the simplest. Simplicity and clarity go hand and hand, as do complexity and ambiguity. A design that is simple and clear will be easier to implement than a design that is complex and ambiguous. Simple designs often gain much wider use than competing designs that are more complex even when the more complex design is "better" in some senses. A good example of this is the widespread implementation and deployment of TCP/IP instead of OSI. OSI is "better" in the sense that it is much richer, is designed to scale to vast numbers of nodes, etc. however this made no difference because TCP/IP was far simpler to implement and met the needs of networking users quite well. A good schema will work within the limitations of the LDAP protocol and take advantage of the features that are available: o Schema inheritance S. G. Judd Informational Expires December, 1999 6 Designing Directory Schemata for General Use June, 1999 o Schema and syntax checking o Containment (parent-child relationships). The semantics of the schema should put the lightest burden possible on the client. For example, a design that requires the client to provide (or at least mimic) transaction semantics will be difficult to implement and be a barrier to adoption. Likewise, a design that requires the client to perform complex processing of attributes to create and validate a sub-structure within the attribute is burdensome and will be a barrier to adoption. 4.1.3 Avoiding Seductive Errors There are many hazards on the road to a good schema. Learn to recognize and avoid some of the more seductive errors that can turn even the best-intentioned designer to the "Dark Side". 4.1.3.1 The Relational Trap A directory service is not a relational database system, at least when accessed using the LDAP protocol, and a design that works well in an RDBMS will probably not work well (or at all) when implemented as a directory schema. LDAP does not provide a "join" operation, and there is no concept of "views". Relationships among entries can be expressed in two ways: o Containment: an entry may be the child of exactly one entry and the parent of one or more. The parent-child relationship expressed via containment is opaque and has no attributes, that is, you cannot inspect the relationship to determine why a particular entry is a child of some other entry. o DN Reference: an entry can store the DN of another entry in an attribute. RFC 2252 [7] defines a syntax for this purpose. As discussed above LDAP does not guarantee the integrity of a DN reference. If the target is deleted, moved, or renamed the reference may not be updated, depending on the particular directory service in use. LDAP provides a mechanism to retrieve all of the children of a particular entry (or some subset based on a filter expression). There is no mechanism to automatically dereference a DN. To retrieve an entry referenced by another entry, you must retrieve the DN from the referencing entry, then issue a second search to retrieve the referenced entry. It is possible to define attributes for the entries of interest and treat them like "foreign keys" in an RDBMS. If the directory service in use supports user-defined indices you can index these attributes for performance. However, because there is no "join" operation the burden of implementing the "relationship" using these attributes falls on the client. As discussed above the greater the S. G. Judd Informational Expires December, 1999 7 Designing Directory Schemata for General Use June, 1999 burden you place upon the client the greater the obstacles to adoption of your schema. Designing a directory schema does have one thing in common with designing an RDBMS schema: a "brute force" mapping of the information model onto tables (or entries, in the case of LDAP) will probably not produce a result that offers the performance and scalability desired. You must give careful attention to denormalizing the information model to keep the number of entries and relationships manageable. 4.1.3.2 Depending on "Fixing" LDAP The limitations of LDAP can be extremely inconvenient. Since LDAP is developed in an open forum (the IETF), there is an opportunity to raise issues with the limitations and work to correct them. However, the standards process is lengthy and there is no guarantee that a particular change will happen at the desired time, or in fact ever. Do not make your design depend upon "fixing" some limitation of LDAP. 4.1.3.3 Extending or Overloading Syntax RFC 2252 [7] defines the syntax that an LDAP server should recognize and support. Some directory servers might support user-defined syntaxes; others will not. Extensible syntax is not defined by the LDAP RFCs, so your design should not depend on it. The absence of structured attributes and ordered sets are two of the more annoying restrictions in LDAP. There is often a temptation to "correct" this by overloading an existing syntax with special semantics. For example, an "ordered set" can be implemented by storng the attributes in a multi-value as tuples consisting of an ordering value, a delimiter, and the value. Down this path lies madness! o This approach is burdensome to the client o The directory server cannot check the validity of the ordering value and delimiter. This makes this approach very fragile. Consider an attribute with syntax "Directory String" that a schema designer as overloaded as a tuple of :. To the directory service, all of these values are valid: o 01:nightshade o xyz:bella donna o "Bring me the head of Alfredo Garcia", 1974, Sam Peckinpah From the application's perspective, only the first value is valid, but there is no obstacle to a client storing any of these S. G. Judd Informational Expires December, 1999 8 Designing Directory Schemata for General Use June, 1999 in the directory. The more involved the overloading of the syntax is, the greater the burden on the client and the more fragile the implementation will be. Avoid overloading syntax or requiring clients to understand and implement internal structure in attributes. 4.1.3.4 Byzantine Names Every entry in the directory has a name, the "distinguished name:, which is composed of the individual name ("relative distinguished name" or RDN) of the entry concatenated with the RDN of its ancestors. The RDN of an object is determined by the schema. RFC 2251 allows the RDN for an object to be a multi-valued property or to consist of a list of attributes. When you use of multi-valued attributes or sets of attributes to form the RDN of an object you are adding needless complexity. Moreover, not all servers will support multi-valued or multi-part RDNs. As with other aspects of schema design, with naming simpler is better. Defining additional or complex naming attributes complicates the clients. Consider how to present a multi-valued or multi-part name for an object or list of objects in a user interface way that is understandable to the user. Clearly a simple name stored in an existing attribute (Common name, "cn", is recommended) is easier to implement and easier to understand. Avoid byzantine naming schemes for objects. 4.1.3.5 Referential Integrity - the Monster that will Eat You The only relationship exposed by the LDAP protocol is the containment (parent-child) relationship. The relationship is created by adding a new entry as a child of an existing entry and deleted by removing the child entry. All other relationships among entries must be managed by the client. The opportunities for referential integrity problems are numerous and vary across server implementations. Among the more pernicious problems are relationships implemented as DN references. Consider the following example: Assume an entry "A" holds the DNs of related objects "B" and "C" in a multi-valued attribute. Further assume that "B" and "C" each hold a backlink to "A" in the form of "A's" DN. Now a third party renames "B" to "Q" unbeknownst to your client. If the server supports rename safety the DN reference in "A" will still be valid, but if the server does not support rename safety, the reference to "B" is now invalid. Moreover, there is no defined mechanism whereby the references in "A" can be corrected, since you do not know what the new name for "B" is, or who renamed it, or why. All you know is the reference is now invalid. S. G. Judd Informational Expires December, 1999 9 Designing Directory Schemata for General Use June, 1999 Consider another case: again assume "A" holds the DNs of "B" and "C" and "B" and "C" hold backlinks to "A". A third party deletes "A". The semantics of "A" are unknown to the third party, that is, there is no way for the third party to know that "B" and "C" have a relationship with "A" and need to have their backlinks updated. If the server supports automatic backlink management this will not be an issue, but if the server does not, it will be. Perhaps "B" and "C" are meaningless without "A" and need to be deleted - the third party has no way to discover this, and the entries will be "orphaned". Avoid implementing relationships that cannot be expressed by containment. When the use of DN references is unavoidable, keep them as simple as possible. 4.1.3.6 Consistency - Latency and Multi-master effects Designs that work on a single server may fail when deployed in a replicated environment. The LDAP RFCs do not define replication; different directory servers may behave differently. Replication takes time, and time means latency. Latency is defined as the time between a change being applied at a given source replica and the change appearing at some destination replica. There are two latency-induced states that you must understand and allow for in a schema design: o Version skew - version skew occurs when an update has occurred at a source replica and no part of the update has been propagated to a given destination replica. A client reading the destination replica sees an older version of the data than a client reading the source replica. The effect of version skew varies with the application. For example, if the two clients communicate with each other governed by a policy read from the directory, version skew might prevent their successful communication. o Partial Update - partial update occurs when updates are applied to multiple related objects at a given source replica and only some of the updates have been propagated to a given destination replica. A client reading the destination before all of the updates have been propagated see a mix of old and new data. In addition, because the LDAP protocol does not expose transactions, a client reading the source replica before all of the updates are applied will also see a mix of old and new data. If the entries in question are related and valid as a set, the partial update can result in invalid data. Directories that provide multi-master update add a third replication-related state that you must allow for in your design: o Update Collisions - update collisions occur in multi-master systems when the same object is updated at different replicas in the same replication cycle. The end result depends on the S. G. Judd Informational Expires December, 1999 10 Designing Directory Schemata for General Use June, 1999 replication granularity (attribute level or entry level). If the directory in use replicates attributes, a collision can result in some attributes from each update being propagated. If the directory replicates entire entries, one of the colliding updates will "win" and one will be discarded. Consistency issues are related to referential integrity issues - consistency issues can be minimized with a simple design. Simple relationships and a small number of related entries reduce the effects of latency on consistency. 4.1.3.7 Network Traffic Matters Clients will use the entries in your schema to accomplish some task. Retrieving the necessary entries from the directory will require some number of "round trips" on the network. Each round trip consumes bandwidth and takes a finite amount of time. Your design must take into account the number of round trips required to accomplish the task(s) at hand, and the time available for the client to accomplish the task. For example, if a client must perform an operation that requires directory access 120 times per minute, the client has 500 milliseconds to complete each operation. If the directory access requires 5 round trips, how long will this take? Assume a directory server that can handle 200 base DN searches per second: the 5 accesses will take 25 milliseconds, leaving 475 milliseconds for the client to finish the rest of the work. This ignores network delay and assumes you cam depend on always getting the "best case" response from the directory, a dangerously optimistic assumption. A good design will minimize the number of round trips required to obtain the entries that apply to a particular task. Consider two designs for a "master/detail" schema: o Design I: a master entry holds the DNs of a set of detail entries. o Design II: a master entry is the parent of a set of detail entries. o Assume a single master entry with 10 details. How many round trips are required to retrieve the master and all details? Design I Design II -------- --------- Bind: 1 Bind: 1 Read master: Search: Base: 1 Read master & details: Search: OneLevel: 1 Read each detail: Search: N/A Base : 10 S. G. Judd Informational Expires December, 1999 11 Designing Directory Schemata for General Use June, 1999 Base : 10 Unbind: 1 Unbind: 1 Total Round Trips: 13 Total Round Trips: 3 Design II is the clear winner, requiring only 3 round trips compared to Design I's 13 trips. Given the server above (200 base DN Searches per second) Design I spends 55 ms searching the DS and Design II spends 15 ms, plus some amount of additional time on the server to complete the OneLevel search. Design I encounters network delay for 13 round trips, Design II encounters network delay for 3 round trips. Design I is also susceptible to the referential integrity and latency issues previously discussed for DN references. Analyze the directory accesses required to complete the tasks your schema must support and minimize the number of network round trips involved. 4.1.3.8 Scalability: If a little works well, does a lot work better? A design that works adequately in a small-scale test environment or a proof-of-concept deployment might fail when deployed in a full- scale production environment. LDAP servers come in many shapes and sizes; a single directory might have many millions of objects, large number of replicas, a deep hierarchy of naming contexts, or any of these in combination. Search operations are the most common culprit in scalability problems. The LDAP RFC's do not mandate (or even discuss) the use of indices on attributes to improve query performance. Many, but not all, LDAP servers provide indices to improve query performance, but this is a server-specific feature. Deep searches are particularly problematic: a "deep" search is one that searches an entire subtree of the directory. If the directory is very large a search for all objects matching a given filter expression can be very time consuming. If the attributes in the filter expression are unique and the server in use supports indexing, adding indices can dramatically improve performance. Adding an index on a property that is not unique can actually hurt performance and thus scalability. Regardless of the availability of usefulness of indices, a deep query in a directory built from a hierarchy of naming contexts ("partitions") is also an expensive proposition. If the client has elected to chase referrals, completing the deep query requires visiting each subordinate naming context in the hierarchy and re- issuing the query in that naming context. If the client elects not to chase referrals, the performance will be much improved, but the result set might not contain all objects matching the search filter. S. G. Judd Informational Expires December, 1999 12 Designing Directory Schemata for General Use June, 1999 A good design will minimize the requirement for deep searches. It is best to avoid searches by value altogether - this eliminates a dependency on indexing, although most commercially available servers do provide this capability. A design based on small result sets that can be readily retrieved via a Base Search (e.g. direct read by DN) and a one-level search for children will be relatively insensitive to the size of the directory and the number of subordinate naming contexts. 5 Evaluating a Schema Design After completing a draft schema, or when presented with a schema from a third party, it is wise to evaluate it in the light of the guidelines presented in this document. Schemas do not "pass" or "fail", this is not the purpose of the evaluation. The purpose of the evaluation is to identify aspects of the schema that will affect the type and number of environments where it can be successfully deployed. If the limitations identified in the evaluation are acceptable, then the schema is adequate. If the limitations are not acceptable, then the schema is inadequate and needs revision. 5.1 Implementability Does the schema have dependencies that restrict the number of LDAP server implementations that can support it? For example: o Does the schema subclass any classes not defined in RFC 2256? o Does the schema depend on server behavior not mandated in RFCs 2251 through 2256? Does the schema place unreasonable burdens on the client that will hinder wide acceptance and implementation? For example: o Does the schema overload any syntax with complex semantics for which the client is responsible? o Does the schema depend on the client to provide "transaction like" behavior e.g. "commit/abort". Does the schema have any flaws, which depend on changes to the LDAP RFC's to "fix"? 5.2 Referential Integrity and Consistency Does the schema have any inter-object dependencies that will lead to referential integrity and consistency problems in a replicated system? For example: o Does the schema depend on multiple, related entries to express a single entity, such as a master entry with detail entries to express an "order"? o Does the schema express relationships via DN References? S. G. Judd Informational Expires December, 1999 13 Designing Directory Schemata for General Use June, 1999 5.3 Scalability Does the schema depend on operations whose performance is affected by the number of entries in the directory or the number of subordinate references that must be chased? For example: o Does the schema require deep searches to retrieve the entries necessary to do a task o Does the schema depend on attribute values to retrieve the entries necessary to do a task? If attribute values are used to filter a result set, are the values sufficiently unique? S. G. Judd Informational Expires December, 1999 14 Designing Directory Schemata for General Use June, 1999 References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [3] J. Postel, J. Reynolds, " Instructions to RFC Authors", RFC 2223, October 1997 [4] http://www.ietf.org/ietf/1id-guidelines.txt [5] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [6] Korzybsky, Alfred, "Science and Sanity", 1933, 1995 (4th Ed.) Institute of General Semantics, ISBN 0937298018. [7] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight X.500 Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [8] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997. Author's Addresses S. G. Judd Microsoft One Microsoft Way Phone: 425-836-8080 Redmond, Wa. USA Email: stevenju@microsoft.com Copyright Notice "Copyright (C) The Internet Society 1999. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of S. G. Judd Informational Expires December, 1999 15 Designing Directory Schemata for General Use June, 1999 developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. S. G. Judd Informational Expires December, 1999 16