Network Working Group AL Newton Internet-Draft VeriSign, Inc. Expires: January 15, 2002 July 17, 2001 eXtensible Directory Access Protocol draft-newton-xdap-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. This Internet-Draft will expire on January 15, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document describes an application layer client-server protocol for a framework of representing the query and result operations of directory services. Specified in XML, the protocol defines generic directory query and result operations and a mechanism for extending these operations for specific directory service needs. Newton Expires January 15, 2002 [Page 1] Internet-Draft eXtensible Directory Access Protocol July 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Use of XML . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 General Concepts . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Description . . . . . . . . . . . . . . . . . . . . 5 2.1 Protocol Identification . . . . . . . . . . . . . . . . . . 5 2.2 Request Format . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1 Request . . . . . . . . . . . . . . . . . . . 6 2.2.2 and Request . . . . . . . 6 2.2.3 Request . . . . . . . . . . . . . . . . . 7 2.2.4 Request . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Response Format . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1 Response . . . . . . . . . . . . . . . . . . 7 2.3.2 Response . . . . . . . . . . . . . . . . . . 8 2.3.3 Response . . . . . . . . . . . . . . . . . 8 3. Extension Framework . . . . . . . . . . . . . . . . . . . . 10 3.1 Derived Elements . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Namespace Identifier Requirements . . . . . . . . . . . . . 10 3.3 Names of Entities . . . . . . . . . . . . . . . . . . . . . 11 4. URI Requirements . . . . . . . . . . . . . . . . . . . . . . 12 5. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . . 13 6. Internationalization Considerations . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . 21 References . . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . 23 A. Expressing a Base in XDAP . . . . . . . . . . . . . . . . . 24 B. Schema Discovery . . . . . . . . . . . . . . . . . . . . . . 26 C. An Example Directory Namespace . . . . . . . . . . . . . . . 27 C.1 Part Number Schema . . . . . . . . . . . . . . . . . . . . . 27 C.2 Example Login . . . . . . . . . . . . . . . . . . . . . . . 28 C.3 Example Service Inquiry . . . . . . . . . . . . . . . . . . 29 C.4 Example Search . . . . . . . . . . . . . . . . . . . . . . . 30 C.5 Another Example Search . . . . . . . . . . . . . . . . . . . 32 C.6 Example Entity Lookup . . . . . . . . . . . . . . . . . . . 33 D. Document Terminology . . . . . . . . . . . . . . . . . . . . 35 Full Copyright Statement . . . . . . . . . . . . . . . . . . 36 Newton Expires January 15, 2002 [Page 2] Internet-Draft eXtensible Directory Access Protocol July 2001 1. Introduction 1.1 Use of XML This document describes the specification for the eXtensible Directory Access Protocol (XDAP), an XML text protocol with the purpose of describing the query types and result types of various directory services. XDAP is specified using the Extensible Markup Language (XML) 1.0 as described in [1], XML Schema notation as described in [3] and [4], and XML Namespaces as described in [2]. It is important to note that XML is case sensitive. XML specifications and examples provided in this document MUST be interpreted in the exact character case presented to develop a conforming implementation. 1.2 General Concepts The use of an electronic directory and its associate parts and components to accomplish a certain task or set of tasks is generally considered a directory application. The knowledge of the structure of names of entities, the sub-components of these entities, and the understanding of the query syntax to find these entities are all applied to execute the tasks. This document calls this knowledge of the directory and how to use it a directory namespace. This directory namespace is identified by the URI, more specifically a URN, used within the XML instances to identify the XML schema formally describing the directory. A directory service, or a process running on a computer serving directory information, may handle queries and serve results for multiple directory namespaces. Each directory namespace for which a particular directory service serves is a directory instance. XDAP, and the XML schema formally describing XDAP, does not specify any directory, directory namespace, or knowledge of a particular directory application. XDAP is a specification for a framework with which these directory namespaces can be defined, used, and in some cases interoperate. The framework merely specifies the elements for session management and the elements which must be used to derive query elements and result elements. This framework allows a directory namespace to define its own structure for naming, entities, queries, etc. through the use XML namespaces and XML schemas (hence, a directory is identified by the same URI that identifies its XML namespace). In order to be useful, a directory namespace must extend from this framework. The framework does define certain structures that can be common to Newton Expires January 15, 2002 [Page 3] Internet-Draft eXtensible Directory Access Protocol July 2001 all directory namespaces, such as entity references, search continuations, authentication types, and more. A directory namespace may declare its own definitions for all of these, or it may mix its derived definitions with the base definitions. XDAP defines two types of referrals, an entity reference and a search continuation. An entity reference indicates specific knowledge about an individual entity, and a search continuation allows for distributed searches. Both types may span differing directory namespaces and instances. In addition, XDAP specifies requirements for representing entity references as URI's. No assumptions or specifications are made about roots, bases, or meshes of entities. Finally, the XDAP framework attempts to be transport neutral. There is no default transport specification Newton Expires January 15, 2002 [Page 4] Internet-Draft eXtensible Directory Access Protocol July 2001 2. Protocol Description XDAP is an application layer protocol that can be layered over multiple transport protocols. Each protocol data unit MUST be one and only one complete and valid XML instance. The XML document MAY contain one request element and MAY contain one response element. The request element describes elements for a client to authenticate to a server, request session status information, inquire about the available directory data sets, query a directory data set, and close the session. The response element describes elements for a server to provide to a client session status, available directory data sets, and results from a directory query. No requirements are made concerning the synchronization of the request and the response in this document. However, a transport mapping of XDAP MAY make such requirements if necessary. Both the request and response elements have optional 'sessionToken' attributes to aid in synchronization. In this specification they are OPTIONAL, however a transport mapping MAY require them. The definition of a session is dependent on the underlying transport, but is generally understood to be the context in which requests and responses are conducted with respect to authentication. The following description of the protocol does not describe every detailed aspect necessary for implementation. While reading these following sections, please reference Section 5 for needed details on the formal XML specification. 2.1 Protocol Identification The root element of all XDAP instance documents must be . This element identifies the start of the XDAP elements, the namespace used as the identifier for the XDAP namespace, and the location of the schema. This element and the associated closing tag MUST be applied to all requests and responses sent by both clients and servers. An example: The use of the schema location URI in the Newton Expires January 15, 2002 [Page 5] Internet-Draft eXtensible Directory Access Protocol July 2001 element is OPTIONAL with respect to its use by this specification, and XDAP implementations MAY resolve it to retrieve the schema or they MAY use a locally cached version of the schema. The presence of this URI is mandatory according to [4]. The URI MUST be a valid URI, and SHOULD resolve if the appropriate network resources are available. Versioning of the XDAP protocol is accomplished by use of the namespace URI. A change in the URI indicates a change of the underlying schema and therefore a new version of the protocol. 2.2 Request Format A element holds children representing the different requests that can be made from a client to a server. This element has one attribute, 'sessionToken'. This attribute is a string of generated by the client and SHOULD NOT have any meaning to the server. Its purpose is to provide a mechanism for use by the client to match requests with responses, and it MAY be absent or empty. 2.2.1 Request Providing a mechanism for authentication, this element may have children of or derivatives of . The simple case requires and . The complex case is an abstract element to be defined by in the namespace of directories. Each type MUST contain an attribute of 'directoryNamespace' signifying the target directory namespace to apply this authentication. This value of this and directory namespace of a derived complex authentication element MAY be different. A client MAY reauthenticate more than once during session using the request. If reauthentication occurs with different credentials, all new requests are to be processed against the new credentials. Outstanding requests are to be processed against the old credentials. The specification for a directory namespace MAY choose to explicitly deny authentication using . 2.2.2 and Request The element allows the client to inquire about the current session it has with the server. This element has not content and no attributes. Clients SHOULD start sessions with a session inquiry. Newton Expires January 15, 2002 [Page 6] Internet-Draft eXtensible Directory Access Protocol July 2001 The element enables the client to query for a list of directory namespace identifiers. Authentication MUST not be required for this request. 2.2.3 Request The element enables a client to query a directory namespace of a directory service. It may have two element types as children: and . The content of the element is the name of an entity within a directory. The 'directoryNamespace' attribute is the namespace identifier for the directory in which the lookup operation is to take place. The element is abstract and MAY NOT legally appear in an XML instance. It provides the base type to be used by directory namespaces to define derived query types. 2.2.4 Request The element signals the clients intent to close the session. If the element containing a element does not contain a , , or element, the server MUST immediately close the session, else the server MUST respond with the results and then immediately close the session. 2.3 Response Format The element holds children of the different response types returned from a server to a client. This element has one attribute, 'sessionToken'. This attribute is a string generated by the client and SHOULD NOT have any meaning to the server. The value of this attribute MUST be identical to the value of the 'sessionToken' attribute of the corresponding element. 2.3.1 Response The element MUST be returned to the client in response to an or request. This element MUST also be returned to the client when authentication is required in response to requests. The MUST contain one of these child elements: o MUST be the response if the client issues an request. If the client issues a request and the client is authenticated by means Newton Expires January 15, 2002 [Page 7] Internet-Draft eXtensible Directory Access Protocol July 2001 of a lower layer protocol, the server MUST respond with this answer. If the client issues an request and is already authenticated by means of a lower layer protocol, the server MUST respond with this answer regardless of the authentication credentials in the method. o MUST be the child of if authentication is required to proceed with any requests, or in response to a request when the client is not authenticated. o MUST be the child of if no authentication is required, or in response to a request when the client is not required to authenticate. The element MAY contain the element. This element signifies the failure to correctly parse the XML of the corresponding request. 2.3.2 Response The element is a response to the . A server MAY require authentication before serving this information. If authentication is required and the client is not authenticated, a server MUST return a element instead of a element. If the client is authenticated, this element MUST contain child elements of . The contents of each child MUST contain one directory namespace identifier. In this state, the element MUST contain a child element for each directory namespace for which the server allows queries. A server MAY NOT require separate authentication credentials for this response than for the response. In other words, if a client is a authenticated to receive responses, then it MUST also be authenticated to receive these responses. 2.3.3 Response The element is a response to a request. Each child element is a response to a corresponding child element in the request element, and the order of these children MUST be the same order as their corresponding request elements. Newton Expires January 15, 2002 [Page 8] Internet-Draft eXtensible Directory Access Protocol July 2001 The children MUST be one of the following types: o is an abstract element and MAY NOT be legally placed in an XML instance. It provides the base type to be used by directory namespaces to define derived result types. A derivative of the element MAY be followed by a element. The element communicates to the client the location of a style sheet which MAY be used in the rendering of the contents of the element. o The contents of is a URI. This element notifies the client of a reference to an entity. The URI SHOULD be an XDAP URI. Resolution of the URI is OPTIONAL by the client. o The element children MUST contain one element and one element. Directory namespaces MAY derive a new type from to match transport protocol needs. o The following error elements: * - the corresponding query requires resources unobtainable by the server. * - a name given in a query is not syntactically correct. * - parameters of the corresponding query are not semantically meaningful. * - the corresponding query requires more resources than allowed. * - the name given in a query does not match a known entity. * - the authentication given does not allow access to a specific result entry. This is not the same as denying access to all responses because of failed authentication. * - the XML of the directory namespace of the corresponding query does not validate. Newton Expires January 15, 2002 [Page 9] Internet-Draft eXtensible Directory Access Protocol July 2001 3. Extension Framework Because the XDAP schema defines no useful query types, no directory structure, and no result types, it is useless by itself. Extension of XDAP is accomplished through the use a base XDAP schema, as defined in [3] and [4], and extension of it by directories constructed on top of XDAP. 3.1 Derived Elements The XML Schema definition of XDAP requires schemas of directory namespaces to derive element types from base types in the XDAP definition. The schema definitions of directory namespaces SHOULD derive elements for definition of typed queries and results. While the XDAP schema definition does not prohibit the derivation of any elements, directory namespace schemas SHOULD restrict the derivations to the following types: o - as defined this element contains no content and has no valid attributes. It is abstract and therefore only derivatives of it MAY appear in an XML instance. o - as defined this element contains no content and has no valid attributes. It is abstract and therefore only derivatives of it MAY appear in an XML instance. o - as defined this element contains a , , and elements. Derivations SHOULD extend the content to include information necessary establishing sessions by lower layer protocols, but SHOULD NOT restrict derivations to content less than what is defined. o - as defined this element contains no content and has one valid attribute, 'directoryNamespace'. It is abstract and therefore only derivatives of it MAY appear in an XML instance. Its purpose is to provide a means for the definition of authentication more complex than an identifier and password (i.e. XML PKI ). 3.2 Namespace Identifier Requirements The namespace identifier for a directory namespace and the XML namespace identifier used by the XML Schema describing the directory MUST be the same. These namespace identifiers MUST be restricted to any valid URN[7]. This is a restriction on XML_NS[2], which specifies a namespace identifier is any valid URI[6]. Newton Expires January 15, 2002 [Page 10] Internet-Draft eXtensible Directory Access Protocol July 2001 3.3 Names of Entities The names of entities in a directory namespace MUST be of type CDATA defined by [3]. They may not contain XML markup. Their use SHOULD be transcribable. Names of entities SHOULD be unique within an instance of a directory namespace. Two entities SHOULD NOT have the same name, but a single entity MAY be known by multiple names. In situations where a single name may result in two entities, the directory namespace should make allowances by defining result types that contain entity references to both entities (i.e. "foo.com" can refer to both the domain foo.com and the host foo.com). However, this type of conflict should generally be avoided. Newton Expires January 15, 2002 [Page 11] Internet-Draft eXtensible Directory Access Protocol July 2001 4. URI Requirements XDAP does not have single URI definition because of the dependencies on a URI by the mapping between XDAP and a transport protocol. However, any valid XDAP URI definition MUST meet the following requirements: o Using the layout form syntax of RFC2396[6], each XDAP URI MUST contain a component within its component. The component MUST be composed of the directory namespace identifier, a '/' (slash) character, and the name of an entity within the directory namespace . The layout form syntax of the component MUST be: / o The URI MUST be an absolute URI, therefore the scheme component is always present. o The URI MUST contain the URI component as defined above. This component MUST contain the component and the component and therefore MUST always be an entity reference. o Each transport mapping MUST define a scheme name. The scheme name MAY NOT be used by other XDAP transport mappings. There is no default URI scheme or transport mapping. Newton Expires January 15, 2002 [Page 12] Internet-Draft eXtensible Directory Access Protocol July 2001 5. Formal XML Syntax XDAP is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of XDAP suitable for automated validation of XDAP XML instances. eXtensible Directory Access Protocol (XDAP) Schema v1 Newton Expires January 15, 2002 [Page 13] Internet-Draft eXtensible Directory Access Protocol July 2001 Newton Expires January 15, 2002 [Page 14] Internet-Draft eXtensible Directory Access Protocol July 2001 Newton Expires January 15, 2002 [Page 15] Internet-Draft eXtensible Directory Access Protocol July 2001 Newton Expires January 15, 2002 [Page 16] Internet-Draft eXtensible Directory Access Protocol July 2001 Newton Expires January 15, 2002 [Page 17] Internet-Draft eXtensible Directory Access Protocol July 2001 Newton Expires January 15, 2002 [Page 18] Internet-Draft eXtensible Directory Access Protocol July 2001 6. Internationalization Considerations XDAP is represented in XML, which provides native support for encoding information using the double-byte Unicode character set and its more compact representations including UTF-8. Compliant XML processors are required to understand both UTF-8 and raw Unicode character sets; XML also includes a provision for identifying other character sets through use of an "encoding" attribute in an processing instruction. The complete list of character set encoding identifiers is maintained by IANA and is described in [12] and [8]. Newton Expires January 15, 2002 [Page 19] Internet-Draft eXtensible Directory Access Protocol July 2001 7. IANA Considerations XML schemas require a URI for unique identification. Schemas MUST be registered to ensure URI uniqueness, but the IETF does not currently have a recommended repository for the registration of XML schemas. This document uses URNs to describe XML namespaces and XML schemas. IANA SHOULD maintain a registry of XML namespace and schema URI assignments. Per policies described in [9], URI assignment requests SHOULD be reviewed by a designated expert, and values SHOULD be assigned only as a result of standards action taken by the IESG. Newton Expires January 15, 2002 [Page 20] Internet-Draft eXtensible Directory Access Protocol July 2001 8. Security Considerations XDAP provides only a simple client authentication mechanism. A passive attack is sufficient to recover client identifiers and passwords, allowing trivial session forgery. Protection against most common attacks should be provided by the underlying transport protocol or protocols. The simple client authentication mechanism uses a variant of the PLAIN SASL mechanism described in [10] to provide a application-layer authentication capability. Where the PLAIN SASL mechanism specifies provision of an authorization identifier, authentication identifier, and password as a single string separated by ASCII NUL characters, XDAP specifies use of a combined authorization and authentication identifier and a password provided as distinct XML elements. XDAP also allows for the definition of complex authentication mechanisms in directory namespaces which derive their schemas from XDAP. The specification for these complex mechanisms MUST describe all relevant security considerations. Repeated password guessing attempts can be discouraged by limiting the number of attempts that can be attempted on an open session. A server MUST discontinue a session if three attempts are made with either an invalid client identifier, an invalid password, or both an invalid client identifier and an invalid password. Referral XDAP directory results may contain entity lookups and search continuations which result in a client query operation against another directory service. The authentication credentials used to obtain the directory results SHOULD NOT be used to conduct a subsequent entity lookup or search continuation. As specified, XDAP allows a valid XML instance to contain both a and a . Applications and processes acting only as a client for a given session MUST issue an in response to all requests regardless of the authentication identifier and password. Applications and processes MAY act in the role of both a client and server in a session. Newton Expires January 15, 2002 [Page 21] Internet-Draft eXtensible Directory Access Protocol July 2001 References [1] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, . [2] World Wide Web Consortium, "Namespaces in XML", W3C XML Namespaces, January 1999, . [3] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XML Schema, October 2000, . [4] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XML Schema, October 2000, . [5] World Wide Web Consortium, "Extensible Stylesheet Language (XSL) Version 1.0", W3C XSL, November 2000, . [6] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [7] Moats, R., "URN Syntax", RFC 2141, May 1997. [8] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", RFC 1700, STD 2, October 1994. [9] Narten, T. and H.T. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, BCP 26, October 1998. [10] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999. [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [12] Newton Expires January 15, 2002 [Page 22] Internet-Draft eXtensible Directory Access Protocol July 2001 Author's Address Andrew L. Newton VeriSign, Inc. 505 Huntmar Park Drive Herndon, VA 20170 USA Phone: +1 703 948 3382 EMail: anewton@research.netsol.com URI: http://www.research.netsol.com/ Newton Expires January 15, 2002 [Page 23] Internet-Draft eXtensible Directory Access Protocol July 2001 Appendix A. Expressing a Base in XDAP The concept of a base, a specific search or lookup starting point, is not common to the inherent structure of all directories. Therefore XDAP does not explicitly define a one. The problem of expressing a starting point is solved by use of well-known entity references which return a search continuation. An XDAP URI is an entity reference and therefore capable of being the base of a directory. To illustrate, given the following fictional XDAP URI: xdap://some.host/urn:iana:xmlns:fooDS/foostart The client may resolve the URI by issuing a request and the response would be: xdap some.host 5555 foo1: This mechanism can be used to define both the base of a directory Newton Expires January 15, 2002 [Page 24] Internet-Draft eXtensible Directory Access Protocol July 2001 namespace or a directory instance. When the search continuation contains a host reference to the same host of the directory instance to which the entity lookup was conducted, this can be considered a base of a directory instance. If the host reference is to a different host, this can be considered a base of a directory namespace. This document makes no specification or assumptions about roots, search bases, or entity meshes. Newton Expires January 15, 2002 [Page 25] Internet-Draft eXtensible Directory Access Protocol July 2001 Appendix B. Schema Discovery This specification does not provide a direct mechanism for schema discovery. However, a method is available. A client may use the schema location URI of the element (the second URI) to retrieve the XML Schema document of an unknown directory namespace (assuming the network resources are available). This document contains valid XML which may be used by the client to determine the structure of the unknown directory namespace. A distinction for the proper use and placement of the elements inside XDAP requests and responses may be obtained by evaluating the base types derived from the XDAP schema. XML schema type libraries should be employed to better facilitate the understanding of common data types. In addition, a directory namespace may define query and result derivatives especially designed for schema discovery within its area and specific to its needs. Newton Expires January 15, 2002 [Page 26] Internet-Draft eXtensible Directory Access Protocol July 2001 Appendix C. An Example Directory Namespace The following is an example of an XDAP directory for part numbers. The XML instances are the exchange between the client and server. C.1 Part Number Schema This is the formal XML Schema syntax for a mythical directory application known as urn:iana:xmlns:partno1. Part number directory schema conformant to XDAP schema Newton Expires January 15, 2002 [Page 27] Internet-Draft eXtensible Directory Access Protocol July 2001 C.2 Example Login Newton Expires January 15, 2002 [Page 28] Internet-Draft eXtensible Directory Access Protocol July 2001 This XML instance is a request to authenticate. bjansen fly7crow1 This XML instance is a response from Figure 7. C.3 Example Service Inquiry Newton Expires January 15, 2002 [Page 29] Internet-Draft eXtensible Directory Access Protocol July 2001 This instance is a service inquiry request. This XML instance is a response to Figure 9. urn:iana:xmlns:partno1 urn:iana:xmlns:foo1 C.4 Example Search Newton Expires January 15, 2002 [Page 30] Internet-Draft eXtensible Directory Access Protocol July 2001 This XML instance demonstrates a directory search request to look up a part number. This instance is the response sent in reply to Figure 11. It demonstrates a simple directory result. Wacky Widget Wonko World's Wonderful Wacky Widget 5656573-3993A 29 Newton Expires January 15, 2002 [Page 31] Internet-Draft eXtensible Directory Access Protocol July 2001 C.5 Another Example Search This instance is a request to list all the part number categories. This is the response to Figure 14. It demonstrates a more complex result set consisting of entities in the queried directory, entity references located elsewhere, and search continuations for other directories. Generic Widgets 29 Wacky Widgets 30 Wild Widgets Newton Expires January 15, 2002 [Page 32] Internet-Draft eXtensible Directory Access Protocol July 2001 31 xdap://localhost:8676/urn:iana:xmlns:partno1?/categoryId/32 xdap://localhost:8676/urn:iana:xmlns:partno1?/categoryId/33 xdap://localhost:8676/urn:iana:xmlns:partno1?/categoryId/34 xdap localhost 3933 C.6 Example Entity Lookup Newton Expires January 15, 2002 [Page 33] Internet-Draft eXtensible Directory Access Protocol July 2001 This instance is an entity lookup request. Notice that it is the logical continuation from one of the entity references in Figure 14 /category/32 This instance is the response to Figure 15. xdap localhost 5555 Newton Expires January 15, 2002 [Page 34] Internet-Draft eXtensible Directory Access Protocol July 2001 Appendix D. Document Terminology 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 RFC2119[11]. Newton Expires January 15, 2002 [Page 35] Internet-Draft eXtensible Directory Access Protocol July 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). 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 implementation 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 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Newton Expires January 15, 2002 [Page 36]