Eric A. Hall Consultant INTERNET-DRAFT Andrew Newton Document: draft-hall-ldap-whois-00.txt VeriSign, Inc. Expires: May, 2002 November 2001 The Internet Resource Query Service and the WHOIS Resource Schema Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. 1. Abstract This document describes an architectural framework for locating and retrieving information about network resources, using LDAPv3 for the data-formatting and query-processing services. This document also defines LDAP schema and processing rules for four Internet resource types: DNS domains, IPv4 addresses, IPv6 address, and AS numbers. The framework specified in this document allows additional documents to define additional Internet resource types and their handling rules. INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 Table of Contents 1. Abstract..................................................1 2. Definitions and Terminology...............................3 3. Background, Objectives and Overview.......................4 3.1. Background.............................................4 3.2. Objectives.............................................6 3.3. Overview...............................................8 4. Resource Naming Syntax....................................9 4.1. Namespace Example.....................................10 4.2. The domainComponent LDAP hierarchy....................12 4.3. The inetResources Container...........................13 4.4. Resource-Specific Entries.............................13 4.5. Redirects and Referrals...............................14 5. The LDAP-WHOIS Object Classes and Attributes.............19 5.1. The inetResources Object Class........................20 5.2. The inetDnsDomain Object Class........................26 5.3. The inetIpv4Network Object Class......................32 5.4. The inetIpv6Network Object Class......................37 5.5. The inetAsNumber Object Class.........................43 5.6. The inetOrgPerson Object Class........................49 5.7. The referral Object Class.............................50 5.8. Object Class and Attribute Permissions................50 6. Search and Match Filters.................................52 6.1. Search Filter Expressions.............................52 6.2. Matching Filter Definitions...........................54 7. Query Processing Models..................................60 7.1. Top-Down Processing...................................60 7.2. Bottom-Up Processing..................................65 7.3. Targeted Search Processing............................70 7.4. Supplemental Query Processing Mechanisms..............72 8. Internationalization and Localization....................80 9. DIT Replication..........................................80 10. Security Considerations..................................81 11. IANA Considerations......................................82 12. References...............................................82 13. Author's Addresses.......................................83 14. Transition Issues........................................83 14.1. NIC Handles...........................................84 14.2. Nameserver Attributes.................................84 14.3. Change-Logs...........................................85 14.4. Open Issues...........................................86 Hall & Newton I-D Expires: May 2002 [page 2] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 2. Definitions and Terminology This document unites, enhances and clarifies several pre-existing technologies. Readers are expected to be familiar with the following specifications: RFC 2247 - Using Domains in LDAP/X.500 DNs RFC 2251 - Lightweight Directory Access Protocol (v3) RFC 2252 - Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions. RFC 2254 - The String Representation of LDAP Search Filters RFC 2256 - A Summary of the X.500(96) User Schema for use with LDAPv3 RFC 2798 - Definition of the inetOrgPerson LDAP Object Class [namedref] - - Named Subordinate References in LDAP Directories The following abbreviations are used throughout this document: DIT (Directory Information Tree) - A DIT is a contained branch of the LDAP namespace, having a root of a particular distinguished name. "dc=example,dc=com" is used throughout this document as one DIT, with many example entries being stored in this DIT. DN (Distinguished Name) - A distinguished name provides a unique identifier for an entry, through the use of a multi- level naming syntax. Entries are named according to their location relevant to the root of their containing DIT. For example, "cn=inetResources,dc=example,dc=com" is a DN which uniquely identifies the "inetResources" entry within the "dc=example,dc=com" DIT. RDN (Relative DN) - An RDN provides a locally-scoped unique identifier for an entry. A complete, globally-unique DN is formed by concatenating the RDNs of an entry together. For example, "cn=admins,cn=inetResources,dc=example,dc=com" consists of two RDNs ("cn=admins" and "cn=inetResources") Hall & Newton I-D Expires: May 2002 [page 3] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 within the "dc=example,dc=com" DIT. RDNs are typically only referenced within their local scope. OID (Object Identifier) - An OID is a globally-unique, concatenated set of integers which provide a kind of "serial number" to attributes, object classes, syntaxes and other schema elements. 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. 3. Background, Objectives and Overview 3.1. Background The WHOIS information service was originally provided as a networked front-end to a centralized repository of ARPANET resources and users. Over time, multiple WHOIS information servers have been deployed which provide similar services for Internet resources and users, with each server offering information associated with a specific resource allocation group. For example, there are scores of WHOIS servers which serve one or more of the top-level domains ("com", "jp", etc.), with each server providing information about the sub-domains which have been delegated beneath each of the managed TLDs, and which also provide information about the human operators of those domains, among other details. Similarly, there are WHOIS servers which provide information about different portions of the IPv4 address space. There are also WHOIS servers which are operated by service providers, with these servers providing information about the network resources in use by that organization and its customers. All told, there are hundreds of WHOIS servers available on the public Internet, with each server providing general information about the particular network resources under the control of each organization. Unfortunately, the WHOIS specification does not define a strict set of data-formatting requirements, and as a result, each of the different implementations provide information in different data formats. Some servers provide limited amounts of unstructured information, while others provide information in a highly-detailed and highly-structured form. Similarly, some servers provide Hall & Newton I-D Expires: May 2002 [page 4] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 information in only one language and charset, while others support multiple languages and charsets, and use input switches to control the output format. Essentially, every WHOIS server has its own data formats and syntaxes, with little consistency between them. This wide variety has made programmatic processing somewhat difficult, which has in turn reduced the effectiveness of the information which is provided. Furthermore, each WHOIS server operates as a self-contained entity, with no knowledge or linkage between the different servers, meaning that WHOIS servers cannot redirect queries to other WHOIS servers, nor can clients be redirected to other servers for additional information. As a result, end-users must have prior knowledge of the management entity which is responsible for a particular network resource, must know the domain name of the WHOIS server which provides information about that resource, and must know the syntax for that server. Users are often required to query multiple servers in order to locate the appropriate server for a specific resource (particularly when a resource has been delegated through multiple entities), or to obtain details about a related entity (such as querying for DNS information related to a previously-queried IPv4 address), so these demands can be encountered frequently, raising significant hurdles towards the acquisition of public operational data. Finally, the WHOIS services being operated today offer no means of client authentication, requiring that server operators publish all data with a single "world-readable" permission. However, this single permission conflicts with the privacy and security restrictions within different governmental jurisdictions. A more flexible mechanism for defining and controlling the release of physical and personal information is required in order to meet the demanding requirements of these constituencies. There are many other secondary issues with the WHOIS service as it exists in current form. However, the largest problems are a lack of standardized data formats, a lack of widely-supported referral mechanisms, and lack of privacy and security controls, as described in the preceding text. This document attempts to address these issues by defining operational and protocol guidelines for a distributed WHOIS-like service, using DNS as the directed-lookup protocol and LDAP as the transfer protocol. Hall & Newton I-D Expires: May 2002 [page 5] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 3.2. Objectives The primary design objectives addressed by this document are: * Structured data formats. This service provides structured data in the form of standardized naming and schema in order to facilitate the programmatic access of operational data. This service reuses some existing object classes and attributes where feasible, and also introduces some new schema definitions. * Structured redirects. This document defines a distributed service in order to facilitate programmatic redirects between participating servers. This model is closer in concept to the distributed management model used by DNS than the centralized management model traditionally used by the legacy WHOIS service, in that queries may be directed between resource hierarchies according to the information provided by a queried server. * Distributed management. As part of the above, this document also defines a delegated administrative model whereby data that relates to a specific entity is managed and maintained by that entity. A delegation body can provide delegation data about a resource, while an operational body can provide operational data about that resource, and the two views are independently maintained as independent entries. Moreover, organizations can leverage common security mechanisms for the purpose of inter-organizational resource management, such that a delegation entity can choose to allow the operational entity to change the delegation data independently, as required by the operational entity. * Privacy and physical security controls. Organizations can provide as much or as little information as they wish, as dictated by local security policies, government regulations or personal privacy concerns. Implementers can also restrict the amount of information which is returned for anonymous queries, while providing greater amounts of information to authenticated and authorized users. * Internationalization and localization. Given the widespread use of the Internet and its resources in international markets, the need for a service which is capable of supporting internationalized and localized data is Hall & Newton I-D Expires: May 2002 [page 6] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 paramount. The service model described by this document leverages the data formats which are already provided by the LDAP service to achieve this objective, and also provides additional guidance on the presentation of this information to the user. * Consistent architecture. In support of the above, this document defines an architecture which is consistent for all of the participating organizations, regardless of the role they play in the community (whether registry, registrar or operator), and regardless of the size of their resource pool. * Reuse of known technology. One of the basic objectives for this specification is to reuse existing technology wherever possible, if that technology has been proven to be functionally usable for this service. To that end, this document does not define any new transport layer mechanisms, data transfer services, schema languages, or directory service technology, but instead reuses existing technologies for each of these elements. This specification also reuses schema definitions for base objects and common practices for data management, where applicable. * Extensibility. This document defines a set of schema which are required for use with some common core services, but also allows for the creation and use of additional services. For example, it would be possible to layer a public-key lookup service on top of the provided architecture, or to define any number of application- specific data storage and retrieval mechanisms. In short, the primary objective of this service is to facilitate a distributed and highly structured WHOIS-like service. This is achieved by using LDAP as a rich and highly structured query/response transfer mechanism, using the existing DNS domain delegation hierarchy for the purposes of a fast and lightweight server-locator service, and using well-defined common schema for the search inputs, answer data, and redirection mechanisms. This approach satisfies all of the objectives stated above, and also provides an extensible framework that allows for programmatic queries regarding all types of network resources, including future uses which are not defined in this document. Hall & Newton I-D Expires: May 2002 [page 7] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 In addition, this approach also provides at two notable ancillary benefits, which are: * Replication. The service model described by this document benefits from the standardized replication mechanisms which are already provided by the LDAP service, and which are supported by DNS. This allows information stores to be replicated across multiple servers, and for the clients to locate a preferred server for any given query. * Common access. The service described in this document is intended to be used with service-specific clients and servers which implement the necessary LDAP features and extensions. However, this service is also usable with traditional LDAP clients and servers, with the caveat that these systems will exhibit less functionality (particularly in the area of searching). It is also expected that LDAP- WHOIS gateways will be developed in the form of proxy servers which gateway between TCP port 43 and the LDAP data, thereby providing legacy WHOIS clients with access to the data. 3.3. Overview This document defines four basic service components and their interaction as part of a distributed resource-locator service. Each of these components work together to provide a structured and distributed resource-locator service. The four components of this service are: * Structured Naming Syntax. This document implicitly defines a virtual LDAP namespace which leverages the existing DNS delegation hierarchy, and is supplemented by a layered namespace consisting of service-specific containers and resource-specific entries. This namespace and the associated naming rules facilitate the programmatic formation of queries and answer sets. * Schema Definitions. This document reuses many existing LDAP schema definitions, but also introduces several new object classes, attributes, syntaxes and matching filters. Some of these definitions apply to the overall architecture, while others are concerned with specific resource types. Hall & Newton I-D Expires: May 2002 [page 8] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 * Searching Rules. This document defines several rules for forming queries which are designed to facilitate consistent answer sets, and to improve interoperability between compliant clients and servers. * Query Processing Models. This document also defines three distinct query-processing models which may be used for locating the authoritative servers associated with a named resource. These include a "top-down" model which is designed for locating centrally-administered and delegated global Internet resources, a "bottom-up" model which is designed for locating user-managed resources, and a "targeted search" model which is designed for issuing directed searches for known resources at known servers. This document also specifies protocol behavior for following subordinate reference referrals, continuation reference referrals, and attribute references. It is the intention of the authors that additional resource types will be added to this framework over time. As such, the architecture and protocols defined in this specification are purposefully designed to be capable of accommodating a variety of different usage models. 4. Resource Naming Syntax A key part of this service is the use of a predictable naming syntax, both for storing resource data and for programmatically creating searches for that data. Because of these two factors, predictability is of the utmost importance to this service. In order to ensure this predictability, this document defines a multi-layered standardized distinguished name (DN) syntax which MUST be used in all compliant implementations. This architecture uses three distinct elements within a DN. The right-most components of a DN use the domainComponent ("dc=") RDN syntax to map between DNS zones and LDAP directory information trees (DITs), such that the LDAP servers which are authoritative for a particular portion of the DNS hierarchy can be easily located, and so that the scope of the DIT can be easily determined. Within each distinct DIT is a service-specific container entry with an RDN of "cn=inetResources", which further contains resource-specific entries named according to resource- specific rules. The combination of these three structural elements Hall & Newton I-D Expires: May 2002 [page 9] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 results in a fully-formed DN which refers to an explicit Internet resource in an explicit DIT. In addition to the structured and predictable naming syntax, the LDAP-WHOIS service also makes provisions for the use of multiple referral services for the purpose of redirecting LDAP clients to foreign DITs. This allows organizations to consolidate DITs when beneficial, allows foreign objects to exist within a private DIT (such as allowing a third-party router to exist as a separately managed resource within an end-user DIT), and allows answer sets to contain responses from multiple servers. 4.1. Namespace Example Figure 1 below shows a subset example of the LDAP-WHOIS namespace, which will be used throughout this document to illustrate many of the concepts and mandates of this specification. Each of these elements are described throughout the remainder of this document. Figure 1: Namespace for Example Widgets' domain and network. DIT: dc=example,dc=com | +-cn=inetResources,dc=example,dc=com [inetResources object class] | +-attribute: o | [inherited from inetResources] | value: "Example Widgets, Inc." | +-attribute: inetSecurityContacts | [inherited from inetResources] | value: "ldap://example.com/cn=security, | ou=admins,dc=example,dc=com" | +-cn=example.com,cn=inetResources,dc=example,dc=com | [inetDnsDomain object class] | | | +-attribute: inetDnsContacts | [inherited from inetDnsDomain] | value: "ldap://example.com/cn=hostmaster, | ou=admins,dc=example,dc=com" | Hall & Newton I-D Expires: May 2002 [page 10] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 +-cn=2.0.192.in-addr.arpa,cn=inetResources,dc=example,dc=com | [inetDnsDomain object class] | | | +-attribute: inetDnsContacts | [inherited from inetDnsDomain] | value: "ldap://example.com/cn=hostmaster, | ou=admins,dc=example,dc=com" | +-cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com [inetIpv4Network object class] [referral object class] | +-attribute: ref [inherited from referral] value: "ldap://example.com/cn=192.0.2.0%2F24, cn=inetResources,dc=example,dc=net" DIT: dc=0,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa | +-cn=inetResources [inetResources object class] [referral object class] | +-attribute: ref [inherited from referral] value: "ldap://example.com/cn=inetResources, dc=example,dc=com" In the example shown in Figure 1, there are two DITs providing LDAP-WHOIS services: one for the "example.com" DNS domain ("dc=example,dc=com"), and another for the "192.0.2.0/24" IPv4 network ("dc=0,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa"). Both DITs have container entries called "cn=inetResources", although the container entry for the reverse-lookup hierarchy is a subordinate reference referral which points back to the "cn=inetResources, dc=example,dc=com" hierarchy. Within the "cn=inetResources,dc=example,dc=com" branch are subentries for the locally-managed resources, including the DNS domains and IPv4 networks. These entries also use strict naming syntaxes in order to facilitate the use of predictable queries. Figure 1 also shows an example of recursive referrals, where the "cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com" entry is being redirected to an entry on the "dc=example,dc=net" DIT. Also note that the LDAP URL for this referral escapes the "/" prefix Hall & Newton I-D Expires: May 2002 [page 11] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 separator (replacing it with "%2F") in order to comply with the URL notation rules. 4.2. The domainComponent LDAP hierarchy. For the top-level of the namespace, this document embraces the domainComponent naming syntax specified in RFC 2247, which maps DNS domain names to domainComponent ("dc=") relative distinguished names (RDNs). Therefore, this document requires that every LDAP DN which is to be specified by an LDAP-WHOIS operation MUST map to a DNS domain name. Examples of this syntax are shown in Figure 2. Note that the root DNS domain is specified with a "dc=." Figure 2: The LDAP-WHOIS domainComponent Namespace. dc=. | +----------------+---------------+ / | \ dc=arpa dc=com dc=[...] | | +--+--+ dc=example / \ dc=in-addr dc=ip6 The complete sequence of domainComponent RDNs represents the scope of the DIT. For example, a DIT with the DN of "dc=com" is authoritative for all of the LDAP resources within the "com" DNS domain, while a DIT with the DN of "dc=example,dc=com" is authoritative for resources within the "example.com" DNS domain. Similarly, the "dc=0,dc=2,dc=192,dc=in-addr,dc=arpa" DN is authoritative for resources within the "0.2.192.in-addr.arpa" DNS domain (including the IPv4 addresses in that subnet and the reverse-lookup domain name entries; the specific resources are indicated by the object class of each LDAP entry). "Authority" for a DIT and its associated resources is assigned through the use of DNS SRV resource records, meaning that the authority to process LDAP searches for the "dc=com" portion of the LDAP namespace hierarchy comes from the authority to process DNS queries for the "com" portion of the DNS hierarchy. What this also means is that DNS SRV query operations can be redirected to LDAP servers in a different DNS zone, which allows LDAP servers outside of a DIT to be authoritative for a DIT, where Hall & Newton I-D Expires: May 2002 [page 12] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 this is desirable. For example, the SRV resource records for the "0.2.192.in-addr.arpa" DNS domain can point to LDAP servers in the "example.com" hierarchy if the administrators choose to do so, although a "dc=0,dc=2,dc=192,dc=in-addr,dc=arpa" DIT would still need to exist on those servers (as a referral, at the least) in order for searches to succeed. 4.3. The inetResources Container Towards the principle objective of predictable naming, this specification requires the use of a mandatory LDAP entry with the well-known RDN of "cn=inetResources", which MUST exist in the root of every DIT that provides LDAP-WHOIS services. All resource- specific entries which are provided on public LDAP-WHOIS servers MUST be stored in the inetResources container. The primary motivation for this naming is for predictability, in that it allows searches to be formed programmatically (a search base for resources in the "dc=example,dc=com" DIT can be programmatically formed as "cn=inetResources,dc=example,dc=com", for example). However, there are other motivating factors for this naming syntax. For example, it is easier to apply a single anonymous read-only permission to the inetResources container than it is to apply the same permission to multiple discrete entries, which in turn means that it is more likely that the appropriate restrictions will be defined. Furthermore, the use of a single container entry for all of an organization's Internet resources allows that branch of the DIT to be redirected to another DIT through the use of a single referral operation. Another reason to use this naming syntax is that it shelters clients from server-side vagaries with DIT entries (where different vendors use different object classes to define the DITs). All told, the use of the "cn=inetResources" RDN facilitates smooth operations, and is important enough to justify the MANDATORY usage of this naming syntax. 4.4. Resource-Specific Entries This document defines four Internet resource types, and each of these resource types have their own naming rules. However, each resource type has a consistent naming principle, in that the Hall & Newton I-D Expires: May 2002 [page 13] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 specific managed resource has an RDN component which uniquely identifies that explicit resource, with this RDN residing within the inetResources container entry. For example, an entry for the DNS domain resource type associated with the "www.example.com" domain name might have a DN of "cn=www.example.com,cn=inetResources,dc=example,dc=com". Similarly, an IPv4 network resource type associated with the IPv4 network address of "192.0.2.0" might have a DN of "cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com". Although the exact naming syntax is different for each resource, the position of the name within a DIT is predictable. Most resource types cannot be located through simple LDAP browsing and equality matching search operations. Instead, resource- specific entries use structured naming rules in order to facilitate the extensible match search operations which are specific to each of the defined resource types. For example, there is not likely to be a specific entry for every possible IPv4 address, so finding the entry associated with a specific IPv4 address will require the client to use the inetIpv4NetworkMatch extensible matching search operation, and this matching rule locates such entries by analyzing the DNs of resource-specific entries. In this regard the use of predictable naming is still extremely important, even though the client may not be able to locate an entry programmatically based on a search value alone. The naming rules associated with each resource type are described in section 5. 4.5. Redirects and Referrals A critical objective for this service is the ability for servers to redirect clients to other DITs or entries when necessary. Towards this goal, this document specifies three methods for generating and processing redirects and referrals: subordinate reference referrals, continuation reference referrals, and attribute references. Subordinate reference referrals indicate that the queried entry is an alias for some other entry, and that the query has to be restarted in order for the current operation to be completed. Meanwhile, continuation references indicate that the search was successfully initiated, but that additional queries are required in order for the original query to be completely processed. Hall & Newton I-D Expires: May 2002 [page 14] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 Finally, attribute references simply indicate that supplemental data is available at some other location, but that no additional queries are required to satisfy the current operation. NOTE: RFC 2251 defines a superior reference referral which is used as a "default referral" for out-of-scope searches. However, this application specifically excludes support for superior reference referrals. Any superior reference referrals which are encountered with this service are treated as errors. Subordinate references and continuation references use the ref attribute and referral object class defined in [namedref]. Attribute references use a superset of the formatting rules associated with the labeledURI attribute, as defined in RFC 2079. All of these mechanisms use URLs which are subject to a series of service-specific formatting restrictions that are somewhat tighter than the source specifications allow. Among these rules: * Sources and targets MUST comply with the naming syntax rules specified in this document. This means that all entries MUST use the domainComponent ("dc=") naming syntax for their DITs, resource-specific entries MUST reside in the inetResources container, and target entries MUST comply with the naming rules for the target resource type. * Referral sources and targets MUST have the same resource- specific object classes defined (a referral source and target for a DNS domain resource would both have the inetDnsDomain object class defined, for example). This is a prerequisite for the proper handling of the search filters specified in this document. Attribute references are not referrals, so they are exempt from this requirement. * Targets MAY be referrals for other resources, but excessively recursive referrals are discouraged. * [namedref] and RFC 2079 specify that URLs are multi-valued. However, the redirection mechanisms supported in this specification are limited to one URL. * The protocol identifier of a URL MUST specify either the LDAP or LDAPS (LDAP over TLS/SSL) service types. Hall & Newton I-D Expires: May 2002 [page 15] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 * The host identifier MUST specify a domain name which is resolvable with a DNS SRV resource record lookup. * Port numbers SHOULD NOT be specified in the URL, and MUST be ignored if they present (SRV resource records provide port numbers for the servers associated with the queried domain name). * If a URL contains extended characters which must be escaped in order for the character to be sent in a URL, the URL must be stored in the escaped form. For example, the IPv4 and IPv6 addressing syntaxes defined for this document require the use of a "/" character in order to indicate an associated network prefix. If such an address needs to be specified in a URL, the URL must be stored with the "/" character already escaped (using "%2F" in this example). * Implementations MUST NOT restrict the URL values to known entries from local partitions. Implementations MAY validate targets, and they are encouraged to prevent errors where the target partition is known, but a lack of knowledge regarding a target MUST NOT be cause to prevent the entry from being specified. Each of the supported redirection mechanisms are discussed in more detail below. 4.5.1. Subordinate reference referrals Subordinate reference referrals are returned when the search base for an operation exists as a referral object class, pointing to some other entry in some other DIT. Any of the named entries specified in section 4 of this document MAY be defined as subordinate reference referrals which point to other entries. However, almost all of the search functions defined for use by this service use the inetResources container entry as the search base (the exceptions to this rule are targeted searches for explicit entries), so subordinate reference referrals will most commonly be seen when an inetResources container entry has been redirected to another DIT for the purpose of consolidated resource management. Hall & Newton I-D Expires: May 2002 [page 16] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 Servers MUST support the use of subordinate reference referrals for this purpose, and clients MUST be prepared to accept and process any subordinate reference referrals in answer sets. When subordinate reference referrals are used for this purpose, the referral object class MUST be defined in conjunction with the object class definition which is appropriate to the resource type in question. For example, a "cn=inetResources" entry which was implemented as a subordinate reference referral would need to have the inetResources and referral object classes defined, while a DNS domain resource-specific entry such as "dc=example.com" would need to have the inetDnsDomain and referral object classes defined (among the other object class definitions which were inherited by that entry). Referral targets need to use whatever object classes are appropriate for the resource in question, and MAY also be referrals to other entries. To illustrate this point, assume that a reverse-lookup DNS domain DIT is being referenced to a forward-lookup DNS domain DIT, in order to allow for consolidated resource management. In such a scenario, "cn=inetResources,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" could have the inetDnsDomain and the referral object classes defined, with the value of the ref attribute carrying an LDAP URL for "ldap://example.com/cn=inetResources,dc=example,dc=com". Whenever a query was received that specified the inetResources container entry of the reverse-lookup DIT, a referral would be returned which informed the client that the query needed to be restarted, using the "cn=inetResources,dc=example,dc=com" container entry as the new search base. Client rules for processing subordinate reference referrals are given in section 7.4.1. 4.5.2. Continuation reference referrals Continuation reference referrals are returned when a search operation has been successfully initiated, but the answer data includes referrals to other entries in some other DITs. These referrals are often provided as supplemental data to an answer set, although this is not required (a continuation reference referral MAY be the only response, but it won't be the only response in the most common case). Hall & Newton I-D Expires: May 2002 [page 17] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 Servers MUST support the use of continuation reference referrals for this purpose, and clients MUST be prepared to accept and process any subordinate reference referrals in answer sets. When continuation reference referrals are used for this purpose, entries MAY exist for the resource in question, and MAY include data from user-definable attributes (such as "mail" and "description"), but one or more entries are required with the referral object class defined, and which provide LDAP URLs that point to other entries which have additional information about the resource in question. For example, a domain registrar may have an entry for the "example.com" DNS domain resource, with this entry possibly having the DN of "cn=example.com,cn=inetResources,dc=netsol,dc=com". Such an entry would most likely contain information related to the delegation status of the "example.com" domain. However, if the administrators of that DIT knew of a DN which was managed by the "example.com" organization directly, that information could be provided as a continuation reference referral by creating another entry underneath the primary entry (perhaps with a DN of "cn=cref1,cn=example.com,cn=inetResources,dc=netsol,dc=com"), with this entry containing a ref attribute that pointed to the remote DN (such as "ldap://example.com/cn=example.com,cn=inetResources, dc=example,dc=com" in this case). Client rules for processing continuation reference referrals are given in section 7.4.3. 4.5.3. Attribute references This document defines attribute references as attribute values which provide LDAP or LDAPS URLs, for the purpose of providing pointers to contextually-related information regarding the entry currently being viewed. Attribute references use the same basic syntax as the labeledURI attribute defined in RFC 2079 (with some additional restrictions, as provided above). The contact attributes defined in this document use the attribute reference rules and formats to provide role-specific pointers to inetOrgPerson entries. Whenever one of these attributes is encountered, it is up to the client to deconstruct the provided URL in order to locate and read the inetOrgPerson entries, although such actions are secondary to the original query process, and are typically only performed at the user's request. Additional Hall & Newton I-D Expires: May 2002 [page 18] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 documents may reuse the attribute reference format and URLs or define their own URL handling rules, as necessary. The attribute reference URL uses a two-part notation of "url://any.host:port/any/path description", with the "description" string providing a free-text description of the target specified by the URL. This syntax is useful for human consumption, and is encouraged where appropriate. For example, a URL of "ldap://example.com/cn=admins,ou=admins,dc=example,dc=com Network administration role account" SHOULD result in that text description being displayed to the user, presumably as useful and potentially informative data. Client rules for processing attribute references are given in section 7.4.4. 5. The LDAP-WHOIS Object Classes and Attributes This document defines a general framework for locating resource data in a distributed environment, and a part of this definition includes schema definitions for global objects such as the inetResources container. This document also defines four resource- specific applications of this model (collectively referred to as the LDAP-WHOIS service), which also have naming and schema definitions that are designed to facilitate locating and searching global Internet resources (such as DNS domains, IPv4 addresses, and so forth). The following schema are defined in this section: * Organizational and summary data. The inetResources object class defines a variety of general-purpose attributes for describing an organization and its resources. For example, there is a free-text attribute which may be used to provide general comments about the network resources, attributes for providing general-use postal and email addresses, and so forth. The inetResources object class also defines several attributes which may be used to provide attribute references for a variety of administrative roles. * DNS domains. The inetDnsDomain object class is subordinate to the inetResources object class, providing attributes for describing a particular DNS domain, and inheriting attributes from the inetResources object class. Hall & Newton I-D Expires: May 2002 [page 19] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 * IPv4 address blocks. The inetIpv4Network object class is also subordinate to the inetResources object class, and provides attributes related to the management of IPv4 networks in particular. * IPv6 address blocks. The inetIpv6Network object class provides summary data about IPv6 networks, similar to the data provided by the inetIpv4Network object class. * Autonomous system (AS) identifiers. IPv4 and IPv6 networks can also be collectively identified as a single autonomous system (AS), thereby allowing groups of discontiguous address blocks to be treated as a single managed entity. The inetAsNumber object class provides attributes for these AS number assignments, and is also subordinate to the inetResources object class. In addition to these object class definitions, this document also makes explicit use of some pre-existing schema. In particular, this document makes extensive use of the inetOrgPerson object class, and dictates the use of this object class in the context of the LDAP-WHOIS service. Each of the attributes and object classes listed above represent the Internet-wide network resources which MAY be offered by an LDAP-WHOIS server or client. The mechanisms defined in this document are designed to be extended with additional network resource definitions. 5.1. The inetResources Object Class The inetResources object class is a structural object class which defines the attributes associated with a "cn=inetResources" container entry, and which provides general information about the network resources associated with the current DIT. 5.1.1. Naming syntax This document requires the presence of an entry named "cn=inetResources" in the root of every DIT which provides LDAP- WHOIS services. Hall & Newton I-D Expires: May 2002 [page 20] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 5.1.2. Schema definition Every DIT which provides public LDAP-WHOIS data MUST have a "cn=inetResources" entry in the root of the DIT. The inetResources entry MUST exist with the top and inetResources object classes defined. If the entry exists as a referral, the entry MUST also be defined with the referral object class, in addition to the above requirements. The inetResources object class is a structural object class which is subordinate to the top abstract class, and which MUST be treated as a container class capable of holding additional subordinate entries. The inetResources object class has one mandatory attribute which is "cn" (the naming attribute), and also has several optional attributes. Each of the other object classes defined by this document are subordinate to the inetResources object class and inherit the attributes defined for the inetResources object class. The inetResources object class is intended to provide summary information about a collection of resources under the control of a single organization or management body. For example, the mail attribute is intended to be used as a general-purpose email address for the organization as a whole (such as "info@example.com"), rather than being used as an email address for a particular administrative role. Because this object class is also inherited by the resource-specific object classes, these attributes can be defined at each of the subordinate entries if a global set of values is undesirable or unfeasible. The inetResources object class provides several multi-valued contact-related attributes for a variety of well-known administrative roles. This model allows the inetResources entry and each of the subordinate managed resources to share a common set of administrative roles, or to have unique roles for each resource, as seen fit by the managing entity. The contact attribute values follow the same rules as the labeledURI attribute defined in RFC 2079, with additional restrictions as described in section 4.5 of this document. The various ModifiedBy and ModifiedDate attributes SHOULD be treated as operational attributes. Their values SHOULD be filled in automatically by the database management application, and SHOULD NOT be returned except when explicitly requested. Hall & Newton I-D Expires: May 2002 [page 21] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 Since multiple directory trees can share a single inetResources entry (through the use of subordinate reference referrals), it is important for the associated data to be applicable for all of the objects which refer to it. For example, it would be effective for a small private company to use a shared set of inetResources attributes for their DNS domain names and IP network blocks, but it would probably be counter-productive for a global ISP to share contact data across all of their hosted domains and routed networks. If separate contacts are required for each resource, the contact data should be specified within each entry, rather than being linked to the inetResources entry. The schema definition for the inetResources object class is as follows: inetResources ( 1.3.6.1.4.1.7161.1.0.0 NAME 'inetResources' DESC 'The inetResources container for the LDAP-WHOIS service' SUP top STRUCTURAL MUST cn MAY ( o $ ou $ description $ inetResourceComments $ businessCategory $ telephoneNumber $ facsimileTelephoneNumber $ mail $ labeledURI $ preferredDeliveryMethod $ physicalDeliveryOfficeName $ postOfficeBox $ postalAddress $ postalCode $ street $ l $ st $ c $ inetAbuseContacts $ inetAbuseContactsModifiedBy $ inetAbuseContactsModifiedDate $ inetGeneralContacts $ inetGeneralContactsModifiedBy $ inetGeneralContactsModifiedDate $ inetSecurityContacts $ inetSecurityContactsModifiedBy $ inetSecurityContactsModifiedDate $ inetTechContacts $ inetTechContactsModifiedBy $ inetTechContactsModifiedDate ) ) The attributes from the inetResources object class are described below: businessCategory, see RFC 2256, section 5.16 c (country), see RFC 2256, section 5.7 cn (commonName), see RFC 2256, section 5.4 description, see RFC 2256, section 5.14 facsimileTelephoneNumber, see RFC 2256, section 5.24 Hall & Newton I-D Expires: May 2002 [page 22] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 inetAbuseContacts ( 1.3.6.1.4.1.7161.1.0.1 NAME 'inetAbuseContacts' DESC 'Contacts for reporting abusive behavior or acceptable-use policy violations.' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) inetAbuseContactsModifiedBy ( 1.3.6.1.4.1.7161.1.0.2 NAME 'inetAbuseContactsModifiedBy' DESC 'Person who last mast modified the inetAbuseContacts attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetAbuseContactsModifiedDate ( 1.3.6.1.4.1.7161.1.0.3 NAME 'inetAbuseContactsModifiedDate' DESC 'Last modification date of the inetAbuseContacts attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) inetGeneralContacts ( 1.3.6.1.4.1.7161.1.0.4 NAME 'inetGeneralContacts' DESC 'Contacts for general administrative issues.' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) inetGeneralContactsModifiedBy ( 1.3.6.1.4.1.7161.1.0.5 NAME 'inetGeneralContactsModifiedBy' DESC 'Person who last mast modified the inetGeneralContacts attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetGeneralContactsModifiedDate ( 1.3.6.1.4.1.7161.1.0.6 NAME 'inetGeneralContactsModifiedDate' DESC 'Last modification date of the inetGeneralContacts attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) Hall & Newton I-D Expires: May 2002 [page 23] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 inetResourceComments ( 1.3.6.1.4.1.7161.1.0.7 NAME 'inetResourceComments' DESC 'General comments about this entry' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) inetSecurityContacts ( 1.3.6.1.4.1.7161.1.0.8 NAME 'inetSecurityContacts' DESC 'Contacts for general security issues.' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) inetSecurityContactsModifiedBy ( 1.3.6.1.4.1.7161.1.0.9 NAME 'inetSecurityContactsModifiedBy' DESC 'Person who last mast modified the inetSecurityContacts attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetSecurityContactsModifiedDate ( 1.3.6.1.4.1.7161.1.0.10 NAME 'inetSecurityContactsModifiedDate' DESC 'Last modification date of the inetSecurityContacts attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) inetTechContacts ( 1.3.6.1.4.1.7161.1.0.11 NAME 'inetTechContacts' DESC 'Contacts for general technical issues.' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) inetTechContactsModifiedBy ( 1.3.6.1.4.1.7161.1.0.12 NAME 'inetTechContactsModifiedBy' DESC 'Person who last mast modified the inetTechContacts attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetTechContactsModifiedDate ( 1.3.6.1.4.1.7161.1.0.13 NAME 'inetTechContactsModifiedDate' DESC 'Last modification date of the inetTechContacts attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) Hall & Newton I-D Expires: May 2002 [page 24] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 l (locality), see RFC 2256, section 5.8 labeledURI, see RFC 2079 mail, see RFC 2798, section 9.1.3 o (organization), see RFC 2256, section 5.11 ou (organizational unit), see RFC 2256, section 5.12 physicalDeliveryOfficeName, see RFC 2256, section 5.20 postalAddress, see RFC 2256, section 5.17 postalCode, see RFC 2256, section 5.18 postOfficeBox, see RFC 2256, section 5.19 preferredDeliveryMethod, see RFC 2256, section 5.29 st (stateOrProvinceName), see RFC 2256, section 5.9 street (streetAddress), see RFC 2256, section 5.10 telephoneNumber, see RFC 2256, section 5.21 5.1.3. Example An example of the inetResources object class in use is shown in Figure 3 below. Figure 3: The Example Widgets inetResources container entry. cn=inetResources,dc=example,dc=com [inetResources object class] | +-attribute: o | value: "Example Widgets' network resources" | +-attribute: inetGeneralContacts | value: "ldap://example.com/cn=admins,ou=admins, | dc=example,dc=com" | Hall & Newton I-D Expires: May 2002 [page 25] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 +-attribute: telephoneNumber | value: "1-800-555-1212" | +-attribute: mail | value: "info@example.com" | +-attribute: inetResourceComments value: "Please don't send complaints to the postmaster@example.com mailbox." 5.2. The inetDnsDomain Object Class The inetDnsDomain object class is a structural object class which provides administrative information about a specific DNS domain name resource. 5.2.1. Naming syntax The naming syntax for DNS domain entries MUST follow the form of "cn=,cn=inetResources,". Each DNS domain name which is managed as a discrete LDAP-WHOIS network resource MUST have a dedicated entry in each of the DITs which provide public LDAP-WHOIS data regarding that domain name. The inetDnsDomainSyntax component of an entry is subject to DN rules, although the inetDnsDomainSyntax is also used for extended search operations, and is therefore subject to specific syntax rules. The basic rules for this format are that domain names MUST be stored as sequences of labels, where each label consists of a maximum of 63 characters, with each label being separated by a full-stop (period) character, and with the entire domain name sequence being a maximum of 255 characters. For example, the "www.example.com" DNS domain name resource stored in the "dc=example,dc=com" DIT would be represented as an entry named "cn=www.example.com,cn=inetResources,dc=example,dc=com", while the "2.0.192.in-addr.arpa" reverse-lookup domain which was stored in the "dc=example,dc=com" DIT would be named "cn=2.0.192.in-addr.arpa,cn=inetResources,dc=example,dc=com". Note that the domain name syntax rules defined by STD 13 allow any eight-bit character code to be used within any domain name, although the host naming rules defined by RFC 952, STD 13 and STD 3 only allow a subset of the printable characters from US-ASCII to Hall & Newton I-D Expires: May 2002 [page 26] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 be used for domain names which specify connection targets. However, many domain names will need to be queried which will not conform to the host naming rules ("_ldap._tcp.example.com" might be specified in a search), so any eight-bit character MUST be considered valid for this service. RFC 2253 defines several escaping mechanisms for use when handling certain "special" characters, and these mechanisms MUST be used whenever a domain name needs to be escaped in order for an assertion value to be parsed. However, STD 13 also allows the use of special characters, and also provides several mechanisms for escaping special characters in DNS domain names, and these rules MUST also be accommodated if valid DNS names are to be supported. In order to facilitate this potential overlap and to minimize confusion during handling, LDAP-WHOIS clients MUST allow DNS domain name query strings to be entered as raw eight-bit data, but if any of the characters need to be escaped for the assertion value to be properly built, then the client MUST escape these characters before the search is submitted. Secondarily, if the user needs to search for a DNS domain name which would normally require escaping or other special handling in order for the domain name to be processed, then the user MUST provide the domain name in its escaped form. By extension, this also means that these DNS domain names MUST be stored as RDNs in their escaped form. For example, STD 13 and RFC 2253 both use a common method of escaping special characters with a reverse solidus (backslash) character, and by following the escape character with the special character itself, or with a two-digit decimal code for the character which has been escaped. If a user needs to specify a domain name of "weird name.example.com" (where "weird name" is a valid domain name label with an embedded space), then the domain name would have an RDN of "cn=weird\32name.example.com" in the directory, and would have to be provided to the client as a search for "weird\32name.example.com". The client would then perform a secondary escape to form "weird\\32name.example.com" as the assertion value, and this secondary escape would be removed by the LDAP-WHOIS server upon receipt. Thus a match would be found. NOTE: Remember that IPv4 addresses are also stored in DNS for reverse-lookup purposes, and the associated zones and PTR domain names may also require escaping, particularly when used with site-specific CIDR notation. Hall & Newton I-D Expires: May 2002 [page 27] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 The common reference to the root domain is a single full-stop (".") character, and this usage is also endorsed by this document when the root domain name needs to be explicitly queried. The maximum size of a valid DNS domain name is 255 characters (this limit applies to the unescaped domain name, and does not include escape sequences). Clients MUST restrict assertion values to this range on input, prior to submitting the LDAP query. The domain name component of the DN MUST match the domain name of the managed resource exactly as the domain name exists in the DNS namespace. For example, if an organization wishes to provide information about "www.example.com", then a RDN entry would need to exist for "cn=www.example.com". If an organization wishes to provide information about the "www.example.com" canonical target "server1.example.net", then a RDN for "cn=server1.example.net" would need to exist. If an organization wishes to provide information about "server1.example.net" whenever a query is received for "www.example.com", then the "cn=www.example.com" entry would need to be defined as a subordinate reference referral, with the ref attribute pointing to the "cn=server1.example.net" entry. This usage model also applies to reverse-lookup domains. If an organization is the authority for the "2.0.192.in-addr.arpa" reverse-lookup domain associated with an IPv4 network (this is different from providing information about the network block in particular, as is discussed separately in section 5.3), then that syntax would also be used to form the RDN for the associated inetDnsDomain entry. 5.2.2. Schema definition DNS domain name entries MUST exist with the top, inetResources and inetDnsDomain object classes defined. If an entry exists as a referral, the entry MUST also be defined with the referral object class, in addition to the above requirements. The inetDnsDomain object class is a structural object class which is subordinate to the inetResources object class, and which MUST be treated as a container class capable of holding additional subordinate entries. The inetDnsDomain object class has no mandatory attributes, although it does have several optional attributes. Hall & Newton I-D Expires: May 2002 [page 28] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 The inetDnsDomain object class defines attributes which are specific to DNS domains, particularly as this relates to domain delegation (DNS operational information is available through DNS itself). This includes information such as the delegation date and the status of the delegation. The inetDnsDomain object class is subordinate to the inetResources object class, so it inherits those attributes as well. Some of the inetDnsDomain object class attributes define contact- related referrals which provide LDAP URLs that refer to inetOrgPerson entries, and these entries will need to be queried separately if detailed information about a particular contact is required. The contact attribute values follow the same rules as the labeledURI attribute defined in RFC 2079, with additional restrictions as described in section 4.5 of this document. The various ModifiedBy and ModifiedDate attributes SHOULD be treated as operational attributes. Their values SHOULD be filled in automatically by the database management application, and SHOULD NOT be returned except when explicitly requested. The schema definition for the inetDnsDomain object class is as follows: inetDnsDomain ( 1.3.6.1.4.1.7161.1.1.0 NAME 'inetDnsDomain' DESC 'DNS domain attributes.' SUP inetResources STRUCTURAL MAY ( inetDnsDelegationStatus $ inetDnsDelegationDate $ inetDnsDelegationModifiedDate $ inetDnsDelegationModifiedBy $ inetDnsContacts $ inetDnsContactsModifiedBy $ inetDnsContactsModifiedDate ) ) The attributes from the inetDnsDomain object class are described below: inetDnsContacts ( 1.3.6.1.4.1.7161.1.1.2 NAME 'inetDnsContacts' DESC 'Contacts for reporting problems with this domain name.' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) Hall & Newton I-D Expires: May 2002 [page 29] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 inetDnsContactsModifiedBy ( 1.3.6.1.4.1.7161.1.1.3 NAME 'inetDnsContactsModifiedBy' DESC 'Person who last mast modified the inetDnsContacts attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetDnsContactsModifiedDate ( 1.3.6.1.4.1.7161.1.1.4 NAME 'inetDnsContactsModifiedDate' DESC 'Last modification date of the inetDnsContacts attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) inetDnsDelegationDate ( 1.3.6.1.4.1.7161.1.1.5 NAME 'inetDnsDelegationDate' DESC 'Date of original delegation.' EQUALITY GeneralizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) inetDnsDelegationModifiedBy ( 1.3.6.1.4.1.7161.1.1.6 NAME 'inetDnsDelegationModifiedBy' DESC 'Person who last mast modified the inetDnsDelegationStatus attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetDnsDelegationModifiedDate ( 1.3.6.1.4.1.7161.1.1.7 NAME 'inetDnsDelegationModifiedDate' DESC 'Last modification date of the inetDnsDelegationStatus attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) inetDnsDelegationStatus ( 1.3.6.1.4.1.7161.1.1.8 NAME 'inetDnsDelegationStatus' DESC 'Current delegation status code for this domain.' EQUALITY numericStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27{2} SINGLE-VALUE ) Hall & Newton I-D Expires: May 2002 [page 30] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 NOTE: In an effort to facilitate internationalization and programmatic processing, the current status of a delegation is identified by a 16-bit integer. The values and status mapping is as follows: 0 Reserved delegation (permanently inactive) 1 Assigned and active (normal state) 2 Assigned but not yet active (new delegation) 3 Temporarily inactive (pending dispute resolution) 4 Revocation pending (database purge pending) 5 Revoked but still active (database purged) Additional values for the inetDnsDelegationStatus attribute are reserved for future use, and are to be administered by IANA. Note that there is no status code for "unassigned"; unassigned entries SHOULD NOT exist, and SHOULD NOT be returned as answers. The inetDnsDomainSyntax syntax is as follows: inetDnsDomainSyntax ( 1.3.6.1.4.1.7161.1.1.1 NAME 'inetDnsDomainSyntax' DESC 'A fully-qualified DNS domain name.' ) 5.2.3. Example An example of the inetDnsDomain object class in use is shown in Figure 4 below, with some additional attributes inherited from the parent inetResources entry. This query is most likely being sent to the LDAP servers responsible for operating the "example.com" DNS domain. Figure 4: The example.com inetDnsDomain entry. cn=example.com,cn=inetResources,dc=example,dc=com [inetDnsDomain and inetResources object classes] | +-attribute: description | [inherited from inetResources] | value: "The example.com DNS domain" | Hall & Newton I-D Expires: May 2002 [page 31] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 +-attribute: inetDnsContacts | [inherited from inetDnsDomain] | value: "ldap://example.com/cn=hostmaster,ou=admins, | dc=example,dc=com" | +-attribute: inetGeneralContacts [inherited from inetResources] value: "ldap://example.com/cn=admins,ou=admins, dc=example,dc=com" 5.3. The inetIpv4Network Object Class The inetIpv4Network object class is a structural object class which provides administrative information about a specific IPv4 address and an associated subnet prefix (this pairing is most often used to represent the starting address of an IPv4 network, but can also be used to identify a specific host). 5.3.1. Naming syntax The naming syntax for IPv4 network entries MUST follow the form of "cn=,cn=inetResources,". Each IPv4 network address which is managed as a discrete LDAP-WHOIS network resource MUST have a dedicated entry in each of the DITs which provide public LDAP-WHOIS data regarding that network address. The inetIpv4NetworkSyntax component of an entry is subject to DN rules, although the inetIpv4NetworkSyntax is also used for extended search operations, and is therefore subject to specific syntax rules. The inetIpv4NetworkSyntax specifically requires the use of the starting address from a range of inclusive addresses, and specifically requires the use of CIDR prefix annotation. In this manner, it is possible to create an inetIpv4Network entry for a range of addresses (by specifying the starting address and the network prefix size), or a single host (by specifying the host- specific address and a /32 prefix). In this definition, inetIpv4NetworkSyntax uses the traditional "dotted-quad" notation, where each of four sub-components provide a decimal value that represents one octet from a 32-bit IPv4 address, with each sub-component being separated by a full-stop (period) character, and with the four-part sequence being followed Hall & Newton I-D Expires: May 2002 [page 32] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 by a "/" character and a three-digit decimal "prefix" value. An augmented BNF for this syntax is as follows: inetIpv4NetworkSyntax = vFourPart "." vFourPart "." vFourPart "." vFourPart "/" vFourPrefix vFourPart = decimal value between "0" and "255" inclusive, with the non-affective leading zeroes removed vFourPrefix = decimal value between "1" and "32" inclusive, with the non-affective leading zeroes removed For example, an IPv4 network with a range of addresses between "10.0.0.0" and "10.0.255.255" inclusive would be written as "10.0.0.0/16", and would appear with an RDN of "cn=10.0.0.0/16". Similarly, a host address of "192.0.2.14" would have the RDN of "cn=192.0.2.14/32". The leading zeroes from each octet MUST be removed during query string formation. Octets which have a value of zero MUST be represented by the numeric value of "0". Note that the use of "/" as data in LDAP URLs is illegal. This character MUST be escaped as "%2F" when an inetIpv4Network entry is specified in a ref attribute. 5.3.2. Schema definition IPv4 network entries MUST exist with the top, inetResources and inetIpv4Network object classes defined. If an entry exists as a referral, the entry MUST also be defined with the referral object class, in addition to the above requirements. The inetIpv4Network object class is a structural object class which is subordinate to the inetResources object class, and which MUST be treated as a container class capable of holding additional subordinate entries. The inetIpv4Network object class has no mandatory attributes, although it does have several optional attributes. The inetIpv4Network object class defines attributes which are specific to IPv4 networks, such as the delegation date and the status of the delegation. The inetIpv4Network object class is subordinate to the inetResources object class, so it inherits those attributes as well. Hall & Newton I-D Expires: May 2002 [page 33] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 Some of the inetIpv4Network object class attributes define contact-related referrals which provide LDAP URLs that refer to inetOrgPerson entries, and these entries will need to be queried separately if detailed information about a particular contact is required. The contact attribute values follow the same rules as the labeledURI attribute defined in RFC 2079, with additional restrictions as described in section 4.5 of this document. The various ModifiedBy and ModifiedDate attributes SHOULD be treated as operational attributes. Their values SHOULD be filled in automatically by the database management application, and SHOULD NOT be returned except when explicitly requested. The schema definition for the inetIpv4Network object class is as follows: inetIpv4Network ( 1.3.6.1.4.1.7161.1.2.0 NAME 'inetIpv4Network' DESC 'IPv4 network attributes.' SUP inetResources STRUCTURAL MAY ( inetIpv4DelegationStatus $ inetIpv4DelegationDate $ inetIpv4DelegationModifiedDate $ inetIpv4DelegationModifiedBy $ inetIpv4Contacts $ inetIpv4ContactsModifiedBy $ inetIpv4ContactsModifiedDate $ inetIpv4RoutingContacts $ inetIpv4RoutingContactsModifiedBy $ inetIpv4RoutingContactsModifiedDate $ inetAssociatedAsNumber ) ) The attributes from the inetIpv4Network object class are described below: inetAssociatedAsNumber ( 1.3.6.1.4.1.7161.1.4.2 NAME 'inetAssociatedAsNumber' DESC 'The autonomous system number directly associated with this network.' EQUALITY caseIgnoreMatch SYNTAX inetAsNumberSyntax SINGLE-VALUE ) inetIpv4Contacts ( 1.3.6.1.4.1.7161.1.2.2 NAME 'inetIpv4Contacts' DESC 'Contacts for reporting problems with this IPv4 network.' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) Hall & Newton I-D Expires: May 2002 [page 34] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 inetIpv4ContactsModifiedBy ( 1.3.6.1.4.1.7161.1.2.3 NAME 'inetIpv4ContactsModifiedBy' DESC 'Person who last mast modified the inetIpv4Contacts attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetIpv4ContactsModifiedDate ( 1.3.6.1.4.1.7161.1.2.4 NAME 'inetIpv4ContactsModifiedDate' DESC 'Last modification date of the inetIpv4Contacts attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) inetIpv4DelegationDate ( 1.3.6.1.4.1.7161.1.2.5 NAME 'inetIpv4DelegationDate' DESC 'Date of original delegation.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) inetIpv4DelegationModifiedBy ( 1.3.6.1.4.1.7161.1.2.6 NAME 'inetIpv4DelegationModifiedBy' DESC 'Person who last mast modified the inetIpv4DelegationStatus attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetIpv4DelegationModifiedDate ( 1.3.6.1.4.1.7161.1.2.7 NAME 'inetIpv4DelegationModifiedDate' DESC 'Last modification date of the inetIpv4DelegationStatus attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) inetIpv4DelegationStatus ( 1.3.6.1.4.1.7161.1.2.8 NAME 'inetIpv4DelegationStatus' DESC 'Current delegation status code for this network.' EQUALITY numericStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27{2} SINGLE-VALUE ) Hall & Newton I-D Expires: May 2002 [page 35] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 NOTE: In an effort to facilitate internationalization and programmatic processing, the current status of a delegation is identified by a 16-bit integer. The values and status mapping is as follows: 0 Reserved delegation (permanently inactive) 1 Assigned and active (normal state) 2 Assigned but not yet active (new delegation) 3 Temporarily inactive (pending dispute resolution) 4 Revocation pending (database purge pending) 5 Revoked but still active (database purged) Additional values for the inetIpv4DelegationStatus attribute are reserved for future use, and are to be administered by IANA. Note that there is no status code for "unassigned"; unassigned entries SHOULD NOT exist, and SHOULD NOT be returned as answers. inetIpv4RoutingContacts ( 1.3.6.1.4.1.7161.1.2.9 NAME 'inetIpv4RoutingContacts' DESC 'Contacts for routing issues with this IPv4 network.' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) inetIpv4RoutingContactsModifiedBy ( 1.3.6.1.4.1.7161.1.2.10 NAME 'inetIpv4RoutingContactsModifiedBy' DESC 'Person who last mast modified the inetIpv4RoutingContacts attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetIpv4RoutingContactsModifiedDate ( 1.3.6.1.4.1.7161.1.2.11 NAME 'inetIpv4RoutingContactsModifiedDate' DESC 'Last modification date of the inetIpv4RoutingContacts attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) The inetIpv4NetworkSyntax syntax is as follows: inetIpv4NetworkSyntax ( 1.3.6.1.4.1.7161.1.2.1 NAME 'inetIpv4NetworkSyntax' DESC 'An IPv4 address and prefix.' ) Hall & Newton I-D Expires: May 2002 [page 36] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 5.3.3. Example An example of the inetIpv4Network object class is shown in Figure 5 below, with attributes from the inetResources object class also being used to provide administrative contacts. This data is a result of a query which was sent to the LDAP servers responsible for operating the "192.0.2.0/24" network block. Figure 5: The 192.0.2.0/24 inetIpv4Network entry. cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com [inetIpv4Network and inetResources object classes] | +-attribute: description | [inherited from inetResources] | value: "The example.com network" | +-attribute: inetIpv4Contacts | [inherited from inetIpv4Network] | value: "ldap://example.com/cn=hostmaster,ou=admins, | dc=example,dc=com" | +-attribute: inetGeneralContacts [inherited from inetResources] value: "ldap://example.com/cn=admins,ou=admins, dc=example,dc=com" As stated earlier, reverse-lookup DNS domains for IPv4 address blocks are managed as inetDnsDomain object class entries. These are entirely different network resources, and should not be confused with inetIpv4Network object class entries. 5.4. The inetIpv6Network Object Class The inetIpv6Network object class is a structural object class which provides administrative information about a specific IPv6 address and an associated subnet prefix (this pairing is most often used to represent the starting address of an IPv6 network, but can also be used to identify a specific host). Hall & Newton I-D Expires: May 2002 [page 37] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 5.4.1. Naming syntax The naming syntax for IPv6 network entries MUST follow the form of "cn=,cn=inetResources,". Each IPv6 network address which is managed as a discrete LDAP-WHOIS network resource MUST have a dedicated entry in each of the DITs which provide public LDAP-WHOIS data regarding that network address. The inetIpv6NetworkSyntax component of an entry is subject to DN rules, although the inetIpv6NetworkSyntax is also used for extended search operations, and is therefore subject to specific syntax rules. This syntax specifically requires the use of the starting address from a range of inclusive addresses, and specifically requires the use of the common IPv6 prefix annotation. In this manner, it is possible to create an inetIpv6Network entry for a range of addresses (by specifying the starting address and the network prefix size), or a single host (by specifying the host-specific address and a /128 prefix). In this definition, the inetIpv6NetworkSyntax uses the uncompressed, 32-nibble IPv6 addressing syntax, where the network address consists of eight sub-components, with each sub-component consisting of four hexadecimal values that represent one nibble, with each sub-component being separated by a colon character, and with the entire sequence being followed by a "/" character and a three-digit decimal "prefix" value. An augmented BNF for this syntax is as follows: inetIpv6NetworkSyntax = vSixPart ":" vSixPart ":" vSixPart ":" vSixPart ":" vSixPart ":" vSixPart ":" vSixPart ":" vSixPart "/" vSixPrefix vSixPart = 4*4nibblePart nibblePart = hexadecimal digit between "0" and "F" inclusive vSixPrefix = decimal value between "1" and "128" inclusive, with the non-affective leading zeroes removed For example, an IPv6 network with a range of addresses between "3ffe:ffff::" and "3ffe:ffff:ffff:ffff:ffff:ffff:ffff:ffff" inclusive would have a RDN of "cn=3ffe:ffff:0000:0000:0000:0000:0000:0000/32". Similarly, a host Hall & Newton I-D Expires: May 2002 [page 38] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 address of "3ffe:ffff::1:2:3:4" would have the RDN of "cn=3ffe:ffff:0000:0000:0001:0002:0003:0004/128". Each of the 16-bit colon-separated values MUST be written in the uncompressed form. Nibbles with a value of zero MUST be represented by the hexadecimal sequence of "0000". Note that the use of "/" as data in LDAP URLs is illegal. This character MUST be escaped as "%2F" when an inetIpv6Network entry is specified in a ref attribute. 5.4.2. Schema Definition IPv6 network entries MUST exist with the top, inetResources and inetIpv6Network object classes defined. If an entry exists as a referral, the entry MUST also be defined with the referral object class, in addition to the above requirements. The inetIpv6Network object class is a structural object class which is subordinate to the inetResources object class, and which MUST be treated as a container class capable of holding additional subordinate entries. The inetIpv6Network object class has no mandatory attributes, although it does have several optional attributes. The inetIpv6Network object class defines attributes which are specific to IPv6 networks, such as the delegation date and the status of the delegation. The inetIpv6Network object class is subordinate to the inetResources object class, so it inherits those attributes as well. Some of the inetIpv6Network object class attributes define contact-related referrals which provide LDAP URLs that refer to inetOrgPerson entries, and these entries will need to be queried separately if detailed information about a particular contact is required. The contact attribute values follow the same rules as the labeledURI attribute defined in RFC 2079, with additional restrictions as described in section 4.5 of this document. The various ModifiedBy and ModifiedDate attributes SHOULD be treated as operational attributes. Their values SHOULD be filled in automatically by the database management application, and SHOULD NOT be returned except when explicitly requested. Hall & Newton I-D Expires: May 2002 [page 39] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 The schema definition for the inetIpv6Network object class is as follows: inetIpv6Network ( 1.3.6.1.4.1.7161.1.3.0 NAME 'inetIpv6Network' DESC 'IPv6 network attributes.' SUP inetResources STRUCTURAL MAY ( inetIpv6DelegationStatus $ inetIpv6DelegationDate $ inetIpv6DelegationModifiedDate $ inetIpv6DelegationModifiedBy $ inetIpv6Contacts $ inetIpv6ContactsModifiedBy $ inetIpv6ContactsModifiedDate $ inetIpv6RoutingContacts $ inetIpv6RoutingContactsModifiedBy $ inetIpv6RoutingContactsModifiedDate $ inetAssociatedAsNumber ) ) The attributes from the inetIpv6Network object class are described below: inetAssociatedAsNumber, see section 5.3 inetIpv6Contacts ( 1.3.6.1.4.1.7161.1.3.2 NAME 'inetIpv6Contacts' DESC 'Contacts for reporting problems with this network.' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) inetIpv6ContactsModifiedBy ( 1.3.6.1.4.1.7161.1.3.3 NAME 'inetIpv6ContactsModifiedBy' DESC 'Person who last mast modified the inetIpv6Contacts attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetIpv6ContactsModifiedDate ( 1.3.6.1.4.1.7161.1.3.4 NAME 'inetIpv6ContactsModifiedDate' DESC 'Last modification date of the inetIpv6Contacts attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) inetIpv6DelegationDate ( 1.3.6.1.4.1.7161.1.3.5 NAME 'inetIpv6DelegationDate' DESC 'Date of original delegation.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) Hall & Newton I-D Expires: May 2002 [page 40] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 inetIpv6DelegationModifiedBy ( 1.3.6.1.4.1.7161.1.3.6 NAME 'inetIpv6DelegationModifiedBy' DESC 'Person who last mast modified the inetIpv6DelegationStatus attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetIpv6DelegationModifiedDate ( 1.3.6.1.4.1.7161.1.3.7 NAME 'inetIpv6DelegationModifiedDate' DESC 'Last modification date of the inetIpv6DelegationStatus attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) inetIpv6DelegationStatus ( 1.3.6.1.4.1.7161.1.3.8 NAME 'inetIpv6DelegationStatus' DESC 'Current delegation status code for this network.' EQUALITY numericStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27{2} SINGLE-VALUE ) NOTE: In an effort to facilitate internationalization and programmatic processing, the current status of a delegation is identified by a 16-bit integer. The values and status mapping is as follows: 0 Reserved delegation (permanently inactive) 1 Assigned and active (normal state) 2 Assigned but not yet active (new delegation) 3 Temporarily inactive (pending dispute resolution) 4 Revocation pending (database purge pending) 5 Revoked but still active (database purged) Additional values for the inetIpv6DelegationStatus attribute are reserved for future use, and are to be administered by IANA. Note that there is no status code for "unassigned"; unassigned entries SHOULD NOT exist, and SHOULD NOT be returned as answers. inetIpv6RoutingContacts ( 1.3.6.1.4.1.7161.1.3.9 NAME 'inetIpv6RoutingContacts' DESC 'Contacts for routing issues with this network.' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) Hall & Newton I-D Expires: May 2002 [page 41] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 inetIpv6RoutingContactsModifiedBy ( 1.3.6.1.4.1.7161.1.3.10 NAME 'inetIpv6RoutingContactsModifiedBy' DESC 'Person who last mast modified the inetIpv6RoutingContacts attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetIpv6RoutingContactsModifiedDate ( 1.3.6.1.4.1.7161.1.3.11 NAME 'inetIpv6RoutingContactsModifiedDate' DESC 'Last modification date of the inetIpv6RoutingContacts attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) The inetIpv6NetworkSyntax syntax is as follows: inetIpv6NetworkSyntax ( 1.3.6.1.4.1.7161.1.3.1 NAME 'inetIpv6NetworkSyntax' DESC 'An IPv6 address and prefix.' ) 5.4.3. Example An example of the inetIpv6Network object class is shown in Figure 6 below, with attributes from the inetResources object class also being used to provide administrative contacts. This data is a result of a query which was sent to the LDAP servers responsible for operating the ip6.arpa delegation domain. Figure 6: The 3ffe:ffff:0000:0000:0000:0000:0000:0000/32 inetIpv6Network delegation entry. cn=3ffe:ffff:0000:0000:0000:0000:0000:0000/32, cn=inetResources,dc=ip6,dc=arpa [inetIpv6Network and inetResources object classes] | +-attribute: description | [inherited from inetResources] | value: "The example.net top-level network" | Hall & Newton I-D Expires: May 2002 [page 42] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 +-attribute: inetIpv6Contacts | [inherited from inetIpv6Network] | value: "ldap://example.com/cn=hostmaster,ou=admins, | dc=example,dc=net" | +-attribute: inetGeneralContacts [inherited from inetResources] value: "ldap://example.com/cn=admins,ou=admins, dc=example,dc=net" Reverse-lookup DNS domains for IPv6 address blocks are managed as inetDnsDomain object class entries which are entirely different network resources, and which should not be confused with the inetIpv6Network object class entries. Note that due to the 128-bit address size and the structuring rules defined in RFC 1886, a fully-formed IPv6 reverse-lookup domain name will have 34 labels, which can result in very large distinguished names. 5.5. The inetAsNumber Object Class The inetAsNumber object class is a structural object class which provides administrative information about a specific autonomous system (AS) number. AS numbers are used to identify routing domains, allowing multiple discontiguous IPv4 and IPv6 network blocks to be referenced with a single, globally-unique identifier. 5.5.1. Naming syntax The naming syntax for AS number entries MUST follow the form of "cn=,cn=inetResources,". Each AS number which is managed as a discrete LDAP-WHOIS network resource MUST have a dedicated entry in each of the DITs which provide public LDAP-WHOIS data regarding that autonomous system. The inetAsNumberSyntax component of an entry is subject to DN rules, although the inetAsNumberSyntax is also used for search and compare operations, and is therefore subject to specific syntax rules. The AS number syntax uses the decimal equivalent of a 16-bit autonomous system number, with the non-affective leading zeroes removed. An augmented BNF for this syntax is as follows: inetAsNumberSyntax = decimal value between "0" and "65535" inclusive, with the non-affective leading zeroes removed Hall & Newton I-D Expires: May 2002 [page 43] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 For example, an entry for AS number "1" from the "dc=arin,dc=net" DIT would have a DN of "cn=1,cn=inetResources,dc=arin,dc=net", while an entry for AS number "65535" from the same DIT would have a DN of "cn=65535,cn=inetResources,dc=arin,dc=net". 5.5.2. Schema definition AS number entries MUST exist with the top, inetResources and inetAsNumber object classes defined. If an entry exists as a referral, the entry MUST also be defined with the referral object class, in addition to the above requirements. The inetAsNumber object class is a structural object class which is subordinate to the inetResources object class, and which MUST be treated as a container class capable of holding additional subordinate entries. The inetAsNumber object class has no mandatory attributes, although it does have several optional attributes. The inetAsNumber object class defines attributes which are specific to autonomous systems and their associated routing domains, such as the delegation date, the status of the delegation, and the IPv4 and IPv6 networks which are directly associated with the AS number. The inetAsNumber object class is subordinate to the inetResources object class, so it inherits those attributes as well. Some of the inetAsNumber object class attributes define contact- related referrals which provide LDAP URLs that refer to inetOrgPerson entries, and these entries will need to be queried separately if detailed information about a particular contact is required. The contact attribute values follow the same rules as the labeledURI attribute defined in RFC 2079, with additional restrictions as described in section 4.5 of this document. The various ModifiedBy and ModifiedDate attributes SHOULD be treated as operational attributes. Their values SHOULD be filled in automatically by the database management application, and SHOULD NOT be returned except when explicitly requested. The network-specific attributes MUST only contain network addresses which are directly associated with the AS number, and MUST use the largest superior prefix delegated to those networks (using the inetIpv4NetworkSyntax and inetIpv6NetworkSyntax rules); Hall & Newton I-D Expires: May 2002 [page 44] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 these attributes MUST NOT contain host or subnet addresses which are subordinate to another value which is already listed, and these attributes MUST NOT contain network addresses of networks which are associated with any other AS number. The schema definition for the inetAsNumber object class is as follows: inetAsNumber ( 1.3.6.1.4.1.7161.1.4.0 NAME 'inetAsNumber' DESC 'Autonomous system attributes.' SUP inetResources STRUCTURAL MAY ( inetAsnDelegationStatus $ inetAsnDelegationDate $ inetAsnDelegationModifiedDate $ inetAsnDelegationModifiedBy $ inetAsnContacts $ inetAsnContactsModifiedBy $ inetAsnContactsModifiedDate $ inetAsnRoutingContacts $ inetAsnRoutingContactsModifiedBy $ inetAsnRoutingContactsModifiedDate $ inetAsnIpv4Networks $ inetAsnIpv4NetworksModifiedBy $ inetAsnIpv4NetworksModifiedDate $ inetAsnIpv6Networks $ inetAsnIpv6NetworksModifiedBy $ inetAsnIpv6NetworksModifiedDate ) ) The attributes from the inetIpv4Network object class are described below: inetAsnContacts ( 1.3.6.1.4.1.7161.1.4.3 NAME 'inetAsnContacts' DESC 'Contacts for reporting problems with this routing domain.' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) inetAsnContactsModifiedBy ( 1.3.6.1.4.1.7161.1.4.4 NAME 'inetAsnContactsModifiedBy' DESC 'Person who last mast modified the inetAsnContacts attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetAsnContactsModifiedDate ( 1.3.6.1.4.1.7161.1.4.5 NAME 'inetAsnContactsModifiedDate' DESC 'Last modification date of the inetAsnContacts attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) Hall & Newton I-D Expires: May 2002 [page 45] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 inetAsnDelegationDate ( 1.3.6.1.4.1.7161.1.4.6 NAME 'inetAsnDelegationDate' DESC 'Date of original delegation.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) inetAsnDelegationModifiedBy ( 1.3.6.1.4.1.7161.1.4.7 NAME 'inetAsnDelegationModifiedBy' DESC 'Person who last mast modified the inetAsnDelegationStatus attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetAsnDelegationModifiedDate ( 1.3.6.1.4.1.7161.1.4.8 NAME 'inetAsnDelegationModifiedDate' DESC 'Last modification date of the inetAsnDelegationStatus attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) inetAsnDelegationStatus ( 1.3.6.1.4.1.7161.1.4.9 NAME 'inetAsnDelegationStatus' DESC 'Current delegation status code for this AS number.' EQUALITY numericStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27{2} SINGLE-VALUE ) NOTE: In an effort to facilitate internationalization and programmatic processing, the current status of a delegation is identified by a 16-bit integer. The values and status mapping is as follows: 0 Reserved delegation (permanently inactive) 1 Assigned and active (normal state) 2 Assigned but not yet active (new delegation) 3 Temporarily inactive (pending dispute resolution) 4 Revocation pending (database purge pending) 5 Revoked but still active (database purged) Additional values for the inetIpv6DelegationStatus attribute are reserved for future use, and are to be administered by IANA. Note that there is no status code for "unassigned"; unassigned entries SHOULD NOT exist, and SHOULD NOT be returned as answers. Hall & Newton I-D Expires: May 2002 [page 46] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 inetAsnIpv4Networks ( 1.3.6.1.4.1.7161.1.4.10 NAME 'inetAsnIpv4Networks' DESC 'The IPv4 networks directly associated with this AS number' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX inetIpv4NetworkSyntax ) inetAsnIpv4NetworksModifiedBy ( 1.3.6.1.4.1.7161.1.4.11 NAME 'inetAsnIpv4NetworksModifiedBy' DESC 'Person who last mast modified the inetAsnIpv4Networks attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetAsnIpv4NetworksModifiedDate ( 1.3.6.1.4.1.7161.1.4.12 NAME 'inetAsnIpv4NetworksModifiedDate' DESC 'Last modification date of the inetAsnIpv4Networks attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) inetAsnIpv6Networks ( 1.3.6.1.4.1.7161.1.4.13 NAME 'inetAsnIpv6Networks' DESC 'The IPv6 networks directly associated with this AS number' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX inetIpv6NetworkSyntax ) inetAsnIpv6NetworksModifiedBy ( 1.3.6.1.4.1.7161.1.4.14 NAME 'inetAsnIpv6NetworksModifiedBy' DESC 'Person who last mast modified the inetAsnIpv6Networks attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetAsnIpv6NetworksModifiedDate ( 1.3.6.1.4.1.7161.1.4.15 NAME 'inetAsnIpv6NetworksModifiedDate' DESC 'Last modification date of the inetAsnIpv6Networks attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) Hall & Newton I-D Expires: May 2002 [page 47] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 inetAsnRoutingContacts ( 1.3.6.1.4.1.7161.1.4.16 NAME 'inetAsnRoutingContacts' DESC 'Contacts for routing issues with this IPv4 network.' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) inetAsnRoutingContactsModifiedBy ( 1.3.6.1.4.1.7161.1.4.17 NAME 'inetAsnRoutingContactsModifiedBy' DESC 'Person who last mast modified the inetAsnRoutingContacts attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetAsnRoutingContactsModifiedDate ( 1.3.6.1.4.1.7161.1.4.18 NAME 'inetAsnRoutingContactsModifiedDate' DESC 'Last modification date of the inetAsnRoutingContacts attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) The inetAsNumberSyntax syntax is as follows: inetAsNumberSyntax ( 1.3.6.1.4.1.7161.1.4.1 NAME 'inetAsNumberSyntax' DESC 'An autonomous system number.' ) 5.5.3. Example An example of the inetAsNumber object class is shown in Figure 5 below, with attributes from the inetResources object class also being used to provide administrative contacts. This data is a result of a query which was sent to the LDAP servers associated with the "arin.net" domain. Hall & Newton I-D Expires: May 2002 [page 48] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 Figure 7: The inetAsNumber delegation entry for AS 65535. cn=65535,cn=inetResources,dc=arin,dc=net [inetAsNumber and inetResources object classes] | +-attribute: description | [inherited from inetResources] | value: "The example.net network" | +-attribute: inetAsnContacts | [inherited from inetAsNumber] | value: "ldap://example.com/cn=hostmaster,ou=admins, | dc=example,dc=net" | +-attribute: inetGeneralContacts [inherited from inetResources] value: "ldap://example.com/cn=admins,ou=admins, dc=example,dc=net" 5.6. The inetOrgPerson Object Class This document provides several contact-related attributes which use LDAP URLs to refer to inetOrgPerson entries. Whenever one of these contact attributes are returned, a separate query for the inetOrgPerson entry associated with the contact attribute will be required if the details of that contact are needed. In order to facilitate programmatic access to this data, LDAP URLs provided in contact attributes MUST refer to entries which use the inetOrgPerson object class, and MUST refer to an entry in a DIT which uses the domainComponent object class syntax ("dc="). The model put forth in this document allows each contact attribute to refer to a variable number of contacts. In this model, a query for a contact attribute MAY return a variable number of LDAP URLs, and each of these contacts can then be queried individually. This allows for multiple explicit contacts per role, while also providing predictable naming and query structures. The target entries MAY exist anywhere in the LDAP hierarchy (as long as they follow the domainComponent naming syntax). It is expected that pre-existing inetOrgPerson entries will be used for this purpose. If this is not desirable or feasible, then an entry MUST be created which meets the minimum requirements defined in this document. Regardless of where the entry is located, the Hall & Newton I-D Expires: May 2002 [page 49] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 target inetOrgPerson entries MUST conform with the schema specification defined in RFC 2798. The target inetOrgPerson entries MAY have any number of attributes defined, with any number of access restrictions, as required by local security policies, government regulations or personal privacy concerns. However, the mail attribute MUST be defined, MUST be valid, and MUST have anonymous read permissions. Furthermore, all of the attributes MUST be secured against anonymous add, delete and modify permissions. 5.7. The referral Object Class This document allows the use of the referral object class to define subordinate reference referrals and continuation reference referrals for inetResources container entries and all of the resource-specific entries. Referral entries MUST conform to the schema specification defined in [namedref]. In particular, referral entries MUST NOT contain any user-definable attributes other than the mandatory "cn" naming attribute and the mandatory "ref" operational attribute. By extension, referral entries MUST be leaf nodes, and MUST NOT have any subordinate entries defined at the referral source. 5.8. Object Class and Attribute Permissions The information presented through the LDAP-WHOIS service will be used for many operational and problem-resolution purposes. In order for this information to be suitable for this purpose, it must be accurate. In order to ensure the veracity of the information, a minimal set of operational guidelines are provided in this section. For the most part, these rules are designed to prevent unauthorized modifications to the data. Note that these rules only apply to data which is willingly provided; no data is required to be entered, but where the data is provided, it MUST be accurate, and it MUST be secured against unauthorized modifications. * The inetResources container entry and all of the resource- specific subordinate entries within every public DIT that provides LDAP-WHOIS resources SHOULD have anonymous read- Hall & Newton I-D Expires: May 2002 [page 50] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 only access permissions, and SHOULD NOT have anonymous add, delete or modify permissions. * With the exception of contact-related attributes from the inetOrgPerson object class, each attribute MAY have whatever restrictions are necessary in order to suit local security policies, government regulations or personal privacy concerns. When the inetOrgPerson object class is used to provide contact details, the mail attribute MUST be defined, SHOULD be valid, SHOULD have read-only anonymous access, and SHOULD NOT have anonymous add, delete or modify permissions. By using the inetOrgPerson object class, it is expected that existing contact-related entries can be reused. If reusing these entries is undesirable or unfeasible, entries with the necessary access SHOULD be made available. Note that contact pointers are entirely optional and are not required to exist. However, where they exist, they MUST comply with the above requirements. * End-users and implementers SHOULD provide anonymous read- only access to the creatorsName, createTimestamp, modifiersName and modifyTimestamp operational attributes associated with each entry in the inetResources branch, since this information is useful for determining the age of the information. * Server managers MAY define additional add, delete or modify permissions for authenticated users, using any LDAPv3 authentication mechanisms they wish. In particular, delegation entities MAY provide for the remote management of delegated resources (such as assigning modification privileges to the managers of a particular delegated domain or address block), although this is entirely optional, and is within the sole discretion of the delegation body. External applications SHOULD NOT make critical decisions based on the information provided through this service without having reason to trust the veracity of the information. Clients and users SHOULD limit the use of unknown or untrusted information to routine purposes. Hall & Newton I-D Expires: May 2002 [page 51] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 6. Search and Match Filters LDAP search filters are fairly flexible, in that they allow for a wide variety of configurable elements, such as the maximum number of entries which should be returned, the type of comparison operation that needs to be performed, and other details. In order to promote interoperability, many of these elements are defined with default settings for use with the LDAP-WHOIS service. In particular, this document defines several suggested and mandatory search filter qualifiers, which are described in detail in section 6.1. This document also defines extensibleMatch filter definitions which MUST be implemented whenever the associated resource types defined in this document are implemented by an LDAP-WHOIS client or server. These filter definitions are provided in section 6.2 below. 6.1. Search Filter Expressions Section 4.5.1 of RFC 2251 defines the LDAP search request specification, although it does not provide guidelines or recommended values for the filter settings. In an effort to promote interoperability among LDAP-WHOIS clients and servers, this document defines some recommended and mandatory values for searches within the LDAP-WHOIS service. NOTE: These rules ONLY apply to the LDAP-WHOIS search operations in particular. Any queries for other resources (such as requests for inetOrgPerson contact entries) MUST NOT impose these restrictions. Also note that other documents which define additional resource types can also define different restrictions, and those definitions will take preference over these guidelines. Generic LDAP clients may be used to browse and search for data, and in those cases, these rules are not likely to be followed. As such, servers MUST be prepared to enforce these rules independently of the client settings. The values of an LDAP search filter should be as follows: * Search base. The DIT to be used in a search will vary for each query operation. The methodology for determining the current search base for a query is defined by the query- Hall & Newton I-D Expires: May 2002 [page 52] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 processing protocols described in section 7, although LDAP- WHOIS searches are normally constrained to the "cn=inetResources" container of a particular DIT. * Scope. In order to support continuation reference referrals (which are defined as referral entries beneath a resource- specific entry), clients MUST use a sub-tree scope for LDAP-WHOIS searches. Servers MUST NOT arbitrarily limit the scope of search operations. * Dereference aliases. Although the LDAP-WHOIS service does not make direct use of alias entries, they are not prohibited. Clients SHOULD set the Dereference Aliases option to Always for LDAP-WHOIS searches. Servers SHOULD dereference any aliases which are encountered, where this is feasible (in particular, where the alias refers to another DIT on the same server). * Size limit. The size limit field specifies the maximum number of entries that a server should return. For the LDAP-WHOIS service, this setting SHOULD be set to a value between 25 and 100. This range ensures that the client is capable of receiving a sufficient number of entries and continuation references in a single response, but also works to prevent runaway queries that match everything (such as searches for "com", which can match every inetDnsDomain entry in the "cn=inetResources,dc=com" container). Servers MAY truncate answer sets to 100 responses if the client specifies a larger value. * Time limit. The time limit field specifies the maximum number of seconds that a server should process the search. For the LDAP-WHOIS service, this setting SHOULD be set to a value between 10 and 60 seconds. This range ensures that the server is able to process a sufficient number of entries, but also works to prevent runaway queries that match everything. Servers MAY stop processing queries after 60 seconds if the client specifies a larger value. * Types-only. The types-only setting is a Boolean flag which controls whether or not attribute values are returned in the answer sets. Since excessive queries are likely to be more burdensome than larger answer sets, this setting SHOULD be set to FALSE. Resource-constrained clients (such as PDAs) MAY set this value to TRUE, but such clients MUST be prepared to issue the necessary subsequent queries. Hall & Newton I-D Expires: May 2002 [page 53] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 * Filter. The search operation will depend on the type of data being queried. For LDAP-WHOIS queries, the filter MUST use the matching rules defined in section 6.2 for the relevant resource type. Other resource-specific documents may define their own handling rules. Note that the extensible match filters defined in this document MUST be supported by LDAP-WHOIS clients and servers. LDAP-WHOIS servers MAY also support additional sub-string filters, soundex filters, or any other filters they wish (these may be required for generic LDAP clients), although LDAP-WHOIS clients MUST NOT expect any additional filters to be available. * Attribute list. Clients MAY restrict the list of attributes which are returned in searches, but are discouraged from doing so without cause. 6.2. Matching Filter Definitions Each of the object classes defined in this document have their own search criteria which MUST be used whenever a collection of resource pools need to be searched. In this model, resource types are specified during the search operation, and most of the resource types have extensibleMatch definition which are used whenever the available resources need to be searched. For example, if a user wishes to find the inetIPv4network object class entry associated with a specific IPv4 address, then the inetIpv4NetworkMatch extensibleMatch filter MUST be specified by the client, and MUST be used by the server when attempting to locate the relevant inetIpv4Network entry. This document defines unique extensibleMatch filters for three of the four resource-specific object classes which are also defined herein: inetDnsDomain, inetIpv4Network, and inetIpv6Network. The inetResources, inetAsNumber and inetOrgPerson object classes can be searched with simple equalityMatch filters, and do not require dedicated extensibleMatch filters, although they do have specific handling rules. Hall & Newton I-D Expires: May 2002 [page 54] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 6.2.1. inetDnsDomainMatch The inetDnsDomainMatch filter provides an identifier and search string format which collectively inform a queried server that a specific DNS domain name should be searched for, and that any matching inetDnsDomain object class entries should be returned. The inetDnsDomainMatch extensibleMatch filter is defined as follows: inetDnsDomainMatch ( 1.3.6.1.4.1.7161.1.1.9 NAME 'inetDnsDomainMatch' SYNTAX inetDnsDomainSyntax ) The assertion value MUST be a valid DNS domain name, using the inetDnsDomainSyntax syntax rules defined in section 5.2. The server MUST compare the assertion value against the RDN of all entries in the inetResources container which have an object class of inetDnsDomain. Any entry for a DNS domain resource which is clearly superior to the DNS domain name provided in the input string MUST be returned to the client. Entries which do not encompass the queried domain name MUST NOT be returned. Entries which do not have an object class of inetDnsDomain MUST NOT be returned. For example, assume that the client has issued a query with the assertion value of "www.example.com". If the queried server has an inetDnsDomain object class entry with a DN of "cn=example.com,cn=inetResources,dc=com", then that entry would be returned to the client. Similarly, a continuation reference referral of "cn=cref1,cn=example.com,cn=inetResources,dc=com" would also be returned, since it has a "cn" component that is superior to the queried domain name, and has the inetDnsDomain object class. Domain names MUST be compared on label boundaries, and MUST NOT be qualified through simple character matching. Given two entries of "cn=example.com" and "cn=an-example.com", only the first would match an assertion value of "example.com". Using the notation format described in RFC 2254, the search filter expression for the inetDnsDomainMatch query above would be written as "(1.3.6.1.4.1.7161.1.1.9:=www.example.com)". Hall & Newton I-D Expires: May 2002 [page 55] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 Response entries MAY be fully-developed inetDnsDomain entries, or MAY be referrals generated from entries which have the inetDnsDomain and referral object classes defined. Any data which is received MUST be displayed by the client. If a subordinate reference referral is received as part of the answer set, the client MUST restart the query, using the provided data as the new search base. If any continuation reference referrals are received, the client SHOULD start new queries for each reference, and append the output to the original operation's output. 6.2.2. inetIpv4NetworkMatch The inetIpv4NetworkMatch filter provides an identifier and search string format which collectively inform a queried server that a specific IPv4 address should be searched for, and that any matching inetIpv4network object class entries should be returned. NOTE: IPv4 addresses are also stored in DNS for reverse- lookups, and those entries are treated as inetDnsDomain object class entries rather than being treated as inetIpv4Network object class entries (they are treated as DNS zones with their own operational administrators). As such, those entries use the inetDnsDomainMatch query described in section 6.2.1. The inetIpv4NetworkMatch extensibleMatch filter is defined as follows: inetIpv4NetworkMatch ( 1.3.6.1.4.1.7161.1.2.12 NAME 'inetIpv4NetworkMatch' SYNTAX inetIpv4NetworkSyntax ) The assertion value MUST be an IPv4 address, using the inetIpv4NetworkSyntax defined in section 5.3. Clients MUST provide assertion values in this syntax. If an input string does not match this syntax, the client MAY attempt to manipulate the input string such that an appropriate assertion value can be formed. For example, if a user enters a traditional IPv4 address without specifying a prefix value, the client MAY append "/32" to the end of the input string to form a valid assertion value. Similarly, if a user provides an octal or hexadecimal value, the client MAY attempt to convert the input string to the traditional dotted-quad IPv4 address notation. Hall & Newton I-D Expires: May 2002 [page 56] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 The server MUST compare the assertion value against the RDN of all entries in the inetResources container which have an object class of inetIpv4Network. Any entry for an IPv4 network resource which is clearly superior to the IPv4 address provided in the input string MUST be returned to the client. Superiority in this case means exactly what it sounds like: the address range specified by the inetIpv4Network object class entry (as determined by the network number and the prefix combination of the entry's RDN) MUST define a range of IPv4 addresses which encompasses the IPv4 address specified in the query, and any such entry MUST be returned in the response message. Entries which do not encompass the queried address MUST NOT be returned. Entries which do not have an object class of inetIpv4Network MUST NOT be returned. For example, assume that the client is submitting a search for "192.0.2.14/32", with the search base of "dc=in-addr,dc=arpa". The queried server may only have an inetIpv4Network entry for "cn=192.0.0.0/8,cn=inetResources,dc=in-addr,dc=arpa", and as such that would be the only entry returned. However, the server could also have multiple entries which matched the queried IPv4 address, "such as cn=192.0.0.0/8,cn=inetResources,dc=in-addr,dc=arpa" and "cn=192.0.2.0/24,cn=inetResources,dc=in-addr,dc=arpa", both of which reflected specific delegations. Similarly, a query for this IPv4 address which was sent to the LDAP servers responsible for the operational network could result in "cn=192.0.2.8/29,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" and "cn=192.0.2.14/32,dc=8/29,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" entries being returned to the client (assuming the subnet allocation policy of the network reflected this usage, and that there was an explicit entry for the IPv4 address in question). Using the notation format described in RFC 2254, the search filter expression for the inetDnsDomainMatch query above would be written as "(1.3.6.1.4.1.7161.1.2.12:=192.0.2.14/32)". Response entries MAY be fully-developed inetIpv4Network entries, or MAY be referrals generated from entries which have the inetIpv4Network and referral object classes defined. Any attribute values which are received MUST be displayed by the client. If a subordinate reference referral is received as part of the answer set, the client MUST restart the query, using the provided data as the new search base. If any continuation reference referrals are received, the client SHOULD start new queries for each reference, and append the output to the original operation's output. Hall & Newton I-D Expires: May 2002 [page 57] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 6.2.3. inetIpv6NetworkMatch The inetIpv6NetworkMatch filter provides an identifier and search string format which collectively inform a queried server that a specific IPv6 address should be searched for, and that any matching inetIpv6network object class entries should be returned. NOTE: IPv6 addresses are also stored in DNS for reverse- lookups, and those entries are treated as inetDnsDomain object class entries rather than being treated as inetIpv6Network object class entries (they are treated as DNS zones with their own operational administrators). As such, those entries use the inetDnsDomainMatch query described in section 6.2.1. The inetIpv6NetworkMatch extensibleMatch filter is defined as follows: inetIpv6NetworkMatch ( 1.3.6.1.4.1.7161.1.4.19 NAME 'inetIpv6NetworkMatch' SYNTAX inetIpv6NetworkSyntax ) The assertion value MUST be an IPv6 address, using the inetIpv6NetworkSyntax defined in section 5.4. Clients MUST provide assertion values in this syntax. If an input string does not match this syntax, the client MAY manipulate the input string to form a valid assertion value. For example, if a user provides a zero- compressed IPv6 address such as 3ffe:ffff::, the client MAY convert the input value to the inetIpv6NetworkSyntax form of "3ffe:ffff:0000:0000:0000:0000:0000:0000/32". The server MUST compare the assertion value against the RDN of all entries in the inetResources container which have an object class of inetIpv6Network. Any entry for an IPv6 network resource which is clearly superior to the IPv6 address provided in the input string MUST be returned to the client. Entries which do not encompass the queried address MUST NOT be returned. Entries which do not have an object class of inetIpv6Network MUST NOT be returned. Using the notation format described in RFC 2254, the search filter expression for the inetDnsDomainMatch query above would be written as "(1.3.6.1.4.1.7161.1.4.19:= 3ffe:ffff:0000:0000:0000:0000:0000:0000/32)". Hall & Newton I-D Expires: May 2002 [page 58] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 Response entries MAY be fully-developed inetIpv6Network entries, or MAY be referrals generated from entries which have the inetIpv6Network and referral object classes defined. Any attribute values which are received MUST be displayed by the client. If a subordinate reference referral is received as part of the answer set, the client MUST restart the query, using the provided data as the new search base. If any continuation reference referrals are received, the client SHOULD start new queries for each reference, and append the output to the original operation's output. 6.2.4. inetResources, inetAsNumber and inetOrgPerson equalityMatch DNS domains and IP addresses have specific subordinate delegation properties which require special processing rules as described above. Conversely, the inetResources, inetAsNumber and inetOrgPerson object classes do not have this inheritance problem, and these entries can be searched using relatively simple equalityMatch filters. In order to ensure that all of the relevant entries (including any referrals) are found, the search filters for these resources MUST specify two distinct elements: the object class of the resource being queried, and the naming element of the resource specified as a distinguished name attribute. For example, using the notation format described in RFC 2254, the search filter expression for the inetOrgPerson entry associated with "cn=admins,ou=admins,dc=example,dc=com" would be structured as "(&(objectclass=inetOrgPerson)(cn:dn:=admins))", using "ou=admins,dc=example,dc=com" as the search base. This would find all entries with the object class of inetOrgPerson (including all of the referral entries for inetOrgPerson entries) where the distinguished name contained the "cn" attribute of "admins". Similarly, a query for "(&(objectclass=inetAsNumber)(cn:dn:1))" with a search base of "cn=inetResources,dc=example,dc=com" would find all of the inetAsNumber object class entries associated with AS number "1" in the LDAP-WHOIS branch of "dc=example,dc=com". The input source and search base for these matches will vary according to the query being processed, but whenever an equalityMatch is called for during query processing, the above methods MUST be used in order to ensure that all of the related entries are located. Hall & Newton I-D Expires: May 2002 [page 59] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 Response entries MAY be fully-developed entries, or MAY be referrals generated from entries which have the referral object class defined. Any attribute values which are received MUST be displayed by the client. If a subordinate reference referral is received as part of the answer set, the client MUST restart the query, using the provided data as the new search base. If any continuation reference referrals are received, the client SHOULD start new queries for each reference, and append the output to the original operation's output. 7. Query Processing Models The LDAP-WHOIS service uses three different query-processing models. These are the "top-down" model which uses service-specific delegation hierarchies to direct queries through a tree, a "bottom-up" model which uses DNS delegation data to direct queries to user-managed servers, and a "targeted" search model which is functionally identical to traditional LDAP searches. Furthermore, each of these mechanisms may require additional search operations as a result of subordinate reference referrals, continuation reference referrals, or attribute references. Each of the query models are appropriate to different usage environments. For example, the top-down model is best suited for searches about global resources which are centrally managed and delegated (such as IP addresses and DNS domains), and where delegation information is a critical element of the resource data. Meanwhile, the bottom-up model is most appropriate for those resources which are managed by the end-users directly, and which are not managed from a centralized delegation authority (this includes information such as private keys, mail servers, and other leaf-node resources). Finally, the targeted model is best suited for explicit queries where a particular resource is supposed to exist with a known DN (such as with contact pointers). LDAP-WHOIS clients and servers MUST implement all three models, although clients MUST default to using the top-down model, but MUST also provide a user-selectable option for the disposition of individual queries. 7.1. Top-Down Processing The top-down model is primarily suited for locating Internet resources which are centrally managed and delegated. The top-down Hall & Newton I-D Expires: May 2002 [page 60] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 model is similar to other distributed WHOIS protocols in this regard, with the principle difference being the use of LDAP for standardized syntaxes, data and referrals, rather than using a specialized protocol specifically for this application. The top-down model uses DNS lookups to map a queried string to a delegation entity's LDAP servers. Once this process completes, additional LDAP search operations are processed in order to produce supplemental answer sets. For example, a search operation with the assertion value of "www.example.com" would result in the client attempting to locate the LDAP servers responsible for the "com" domain. Once a server had been located, the client would issue an extensibleMatch search for "www.example.com", using "cn=inetResources,dc=com" as the search base. If the queried server had data about that resource, it could be returned as answer data. If the server knew of other sources of information about the resource (such as the registrar for the domain, or the entity operating the domain, or both), continuation reference referrals could be returned. Any of the subsequent queries could return additional answers and/or referrals, according to the data they had. IP address blocks and AS numbers are processed in a similar fashion. If a client needed to locate information about the "192.0.2.14/32" IPv4 address, it would begin the process by building a reverse-lookup DNS domain name from the input string, and then issuing a DNS query for the LDAP servers associated with the "arpa" top-level domain. Once a server had been located, an LDAP query with the assertion value of "192.0.2.14/32" would be submitted with a search base of "cn=inetResources,dc=arpa". The server would return data or a referral, with this process repeating until the query string had been completely processed. Note that entries for the inetResources and inetOrgPerson object classes are not searchable with this model, since they do not have centralized delegation authorities. The bottom-up or targeted search models MUST be used for those resource types. The top-down model uses DNS delegation data in many of the operations, although it is not strictly tied to the DNS delegation hierarchy. For example, when the first query is issued, the client would use DNS to locate the LDAP servers for the top-level domain associated with the resource name and type. However, a referral could point to an LDAP entry which was outside of the delegation hierarchy (possibly returning a referral for a domain registry Hall & Newton I-D Expires: May 2002 [page 61] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 entity such as "dc=netsol,dc=com", or an IPv4 assignment body such as "dc=arin,dc=net"). Although those entries are also subject to DNS lookups for their SRV resource records, the query chain will have diverged from the original DNS delegation hierarchy, meaning that each resource type has a namespace which is different from the underlying DNS namespace. 7.1.1. Processing steps The steps for processing top-down queries are described below: a. Determine the input type (DNS Domain, IPv4 Address, etc.) b. Determine the authoritative domain name for the query. 1. Separate the input string into discrete elements where this is possible. For DNS domain names, this would be "www", "example" and "com". For an IPv4 network number, this would be "192", "0", "2" and "14". AS numbers only have a single value and require no separation. Do not discard the original query string. 2. IP addresses and AS numbers require additional conversion. For IPv4 addresses, strip off the prefix and convert the input string into a reverse-lookup DNS domain name by reversing the order of the octets and appending "in-addr.arpa" to the right of the domain name. For IPv6 addresses, strip off the prefix and reverse the nibble order of the address (where each nibble is represented by a single hexadecimal character), and append "ip6.arpa". For AS numbers, append only the "arpa" domain name. c. Form the LDAP search base for the query. 1. Convert the right-most element from the domain name formed in step 7.1.1.b above into a domainComponent DN (such as "dc=com" or "dc=arpa"). This represents the DIT for the current query. 2. Append the "cn=inetResources" RDN to the front of the domainComponent syntax ("cn=inetResources,dc=com"). This will form the fully-qualified search base for the LDAP query. Hall & Newton I-D Expires: May 2002 [page 62] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 d. Locate the LDAP servers associated with the resource by processing the domain name formed in step 7.1.1.b above through the SRV query steps provided in section 7.4.5. e. If the SRV lookup succeeds: 1. Choose the best LDAP server, using the weighting formula described in RFC 2782. 2. Construct the LDAP search filter according to the rules specified in section 6.1, using the appropriate matching rule from section 6.2. 3. Formulate the LDAP search using the search base and search filter constructed above. For example, if the input query string was for "www.example.com", then the client would begin the process by submitting an inetDnsDomainMatch extensibleMatch search with the assertion value of "www.example.com", and with a search base of "dc=inetResources,dc=com". Similarly, if the input query string was "192.0.2.14", then the client would begin the process by submitting an inetIpv4NetworkMatch extensibleMatch search, with the assertion value of "192.0.2.14/32", and with the search base of "cn=inetResources,dc=arpa". 4. Submit the search operation. If the operation fails, report the failure to the user and exit. Otherwise, display any answer data which is returned. 5. If the answer data contains a subordinate reference referral or a continuation reference referral, new query processes MUST be spawned. For subordinate reference referrals, process the URLs according to the rules described in section 7.4.1 and restart the query process at step 7.1.1.e. For each continuation reference referral, display the answer data received so far, process the LDAP URLs according to the rules described in section 7.4.3 and start new query processes for each referral at step 7.1.1.e, appending the output from these searches to the current output. Any additional subordinate reference referrals or continuation reference referrals which are encountered Hall & Newton I-D Expires: May 2002 [page 63] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 from any subsequent searches will need to be processed in the same manner as specified above, until no additional referrals are received. f. If the SRV lookup fails (where failure is defined as any DNS response message other than an answer), report the failure to the user and exit the current search operation. 7.1.2. Top-Down example In the example below, the user has entered a search string of "www.example.com" and has indicated that the query is for a DNS domain name. a. The input string is broken into the discrete label components ("www", "example" and "com"). b. The right-most label ("com") is used to form the DNS SRV lookup ("_ldap._tcp.com"), in order to find the LDAP servers authoritative for the delegation hierarchy. c. One of the LDAP servers is contacted, and an inetDnsDomainMatch search filter is submitted with the assertion value of "www.example.com" and a search base of "cn=inetResources,dc=com". d. The server responds with a continuation reference referral with the LDAP URL of "ldap://netsol.com/cn=example.com, cn=inetResources,dc=netsol,dc=com", indicating that the domain delegation is managed under the "dc=netsol,dc=com" DIT. The client uses the continuation reference information to start a new query process. No additional data was provided for the client to display. e. The "netsol.com" host identifier in the URL is used to form a new DNS SRV query for the LDAP servers associated with the domain name of "_ldap._tcp.netsol.com". f. An inetDnsDomainMatch extensibleMatch search is submitted to one of the LDAP servers, using the search base of "cn=example.com,cn=inetResources,dc=netsol,dc=com". g. The queried server returns the information that it has. No additional referrals are provided. The client displays the data and exits the query. Hall & Newton I-D Expires: May 2002 [page 64] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 7.2. Bottom-Up Processing The bottom-up model is best used when a leaf-node resource needs to be queried, and where an LDAP-WHOIS server is expected to be able to answer the query. In this case, navigating through a delegation hierarchy would be either fruitless or inefficient. The bottom-up model uses DNS lookups to map a queried string to an LDAP server which is directly responsible for that resource. In case of failure, the query is incrementally broadened until a server is located (or until a non-recoverable error occurs). Once this process completes, additional LDAP search operations are processed in order to produce supplemental answer sets. The bottom-up approach relies almost exclusively on DNS delegation authority, and this makes it appropriate for locating resources which are not delegated by centralized management authorities. For example, some private keys are created and managed by end-users directly, and those resources would be most effectively queried for in a bottom-up model. Similarly, retrieving mail-routing data associated with a mail domain would be more efficient in the bottom-up model, since there is no global delegation body for Internet mail (the DNS domains are delegated, but the message routing is specific to the operational entities responsible for the domain name). The bottom-up approach is predominately useful for resources which are managed by the operational entities responsible for those resources. This includes entries which have unique attributes within an organization (such as web servers or mail-routing hosts, each of which may have unique operational contacts), infrastructure devices which are leased from third-parties (and which have different organizational attributes, even though they "reside in" the end-user's DIT), and private keys or other user- managed resources which would benefit from being queried individually, rather than being queried as globally unique, centrally delegated resource. The bottom-up model can also be used for DNS domain names, IPv4 addresses, and IPv6 addresses, although this will generally prove to be less useful than top-down queries, given the limited number of user-managed servers deployed. Hall & Newton I-D Expires: May 2002 [page 65] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 Note that entries for inetAsNumber and inetOrgPerson object classes are not searchable with this model, since they are not represented in the DNS delegation hierarchy. The top-down or targeted search models MUST be used for those resource types. In the bottom-up model, a query with the assertion value of "www.example.com" would result in the client attempting to locate the LDAP servers responsible for the "www.example.com" domain name. If this lookup failed, a subsequent DNS query might attempt to locate the LDAP servers responsible for the "example.com" domain, which might be followed by yet another DNS query for the LDAP servers associated with the "com" domain. If an LDAP for the "example.com" domain were located, the client would issue an inetDnsDomainMatch extensibleMatch search for "www.example.com", using "cn=inetResources,dc=example,dc=com" as the search base. If the queried server had data about that resource, it would be returned. If the server knew of other sources of information about the resource, referrals to those entries would be returned for the client to process. IP address blocks are processed in a similar fashion. If a client needed to locate information about the "192.0.2.14" IPv4 address, it would begin by issuing a DNS query for the LDAP servers responsible for the "14.2.0.192.in-addr.arpa" domain name, with the left-most labels being truncated as the search for an authoritative server was broadened. Once a server had been located, an inetIpv4NetworkMatch extensibleMatch search with the assertion value of "192.0.2.14/32" would be submitted. If the server knew of any information about that resource, it would return data or a referral, with this process repeating until the query string had been processed as completely as possible. 7.2.1. Processing steps The steps for processing bottom-up queries are described below: a. Determine the input type (DNS Domain, IPv4 Address, etc.) b. Determine the authoritative DNS domain for the resource. 1. Separate the input string into discrete elements where this is possible. For DNS domain names, this would be "www", "example" and "com". For an IPv4 network Hall & Newton I-D Expires: May 2002 [page 66] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 number, this would be "192", "0", "2" and "14". Do not discard the original query string. 2. IP addresses require additional conversion. For IPv4 addresses, strip off the prefix and convert the input string into a reverse-lookup DNS domain name by reversing the order of the octets and appending "in-addr.arpa" to the right of the resulting sequence. For IPv6 addresses, strip off the prefix and reverse the nibble order of the address (where each nibble is represented by a single hexadecimal character), and append "ip6.arpa" to the right of the resulting sequence. c. Form the LDAP search base for the query. 1. Convert the domain name formed in step 7.2.1.b above into a domainComponent DN (such as "dc=www,dc=example,dc=com" or "dc=0,dc=2,dc=0,dc=192, dc=in-addr,dc=arpa"). This represents the DIT for the current query. 2. Append the "cn=inetResources" RDN to the left of the domainComponent syntax (perhaps resulting in "cn=inetResources,dc=www,dc=example,dc=com"). This will become the search base for the LDAP query. d. Locate the LDAP servers associated with the resource by processing the domain name formed in step 7.2.1.b above through the SRV query steps provided in section 7.4.5. e. If the SRV lookup fails with an NXDOMAIN response code (as described in RFC 2308), then the domain name used for the SRV lookup does not exist, and a substitute LDAP server and search base must be identified. This process involves determining the parent zone for the domain name in question, issuing an SRV lookup for that zone, and using the domain name of the zone as the new LDAP search base, with this process repeating until a search base can be located, or until a critical failure forces an exit. 1. Remove the left-most label from the domain name formed in step 7.2.1.b. 2. If this process has already resulted in a query domain name at a top-level domain such as "com" or "arpa", Hall & Newton I-D Expires: May 2002 [page 67] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 convert the query domain name to "." (to signify the root domain). 3. If the queried domain name is already set to ".", the query can go no higher (this most likely indicates a malformed DNS configuration, a connectivity problem, or a typo in the query). Exit and report the failure to the user. 4. Restart the process at step 7.1.1.c, using the domain name formed above. Repeat until a server is located or a critical failure forces an exit. For example, if the original input string of "www.example.com" resulted in a failed SRV lookup for "_ldap._tcp.www.example.com", then the first fallback SRV query would be for "_ldap._tcp.example.com", and the next fallback query would be for "_ldap._tcp.com", possibly being followed by "_ldap._tcp.", and possibly resulting in failure after that. f. If the SRV lookup succeeds: 1. Choose the best LDAP server, using the weighting formula described in RFC 2782. 2. Construct the LDAP search filter according to the rules specified in section 6.1, and choose the appropriate matching rule from section 6.2. 3. Formulate the LDAP search using the search base and search filter constructed above. For example, if the input query string was for "www.example.com", then the client would begin the process by submitting an inetDnsDomainMatch extensibleMatch search with the assertion value of "www.example.com", with the search base of "cn=inetResources,dc=www,dc=example,dc=com". 4. Submit the search operation. If the operation fails, report the failure to the user and exit. Otherwise, display any answer data which is returned. 5. If the answer data contains a subordinate reference referral or a continuation reference referral, new query processes MUST be spawned. Hall & Newton I-D Expires: May 2002 [page 68] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 For subordinate reference referrals, process the URLs according to the rules described in section 7.4.1 and restart the query process at step 7.2.1.f. For each continuation reference referral, display the answer data received so far, process the LDAP URLs according to the rules described in section 7.4.3 and start new query processes for each referral at step 7.2.1.f, appending the output from these searches to the current output. Any additional subordinate reference referrals or continuation reference referrals which are encountered from any subsequent queries will need to be processed in the same manner as specified above, until no additional referrals are received. g. If a fatal DNS error condition occurs, report the error to the user and stop processing the current query. A fatal DNS error is any response message with an RCODE of FORMERR, SERVFAIL, NOTIMPL, or REFUSED, or where a query results in NODATA (implying that an "_ldap._tcp" domain name exists but it doesn't have an SRV resource record associated with it, which is most likely a configuration error). 7.2.2. Bottom-Up example In the example below, the user has entered a search string of "www.example.com" and has indicated that the query is for a DNS Domain Name. a. The query string is used to form the DNS SRV lookup ("_ldap._tcp.www.example.com"), in order to find the LDAP servers authoritative for that domain name. b. The SRV lookup fails with NXDOMAIN, indicating that the queried domain name does not exist. c. The client creates a new query for the parent domain ("_ldap._tcp.example.com"), which succeeds. d. The client contacts one of the servers, and issues an inetDnsDomainMatch extensibleMatch search with the assertion value of "www.example.com", and with the search base of "cn=inetResources,dc=example,dc=com". Hall & Newton I-D Expires: May 2002 [page 69] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 e. The server returns a continuation reference referral of "ldap://example.net/cn=server1.example.net, cn=inetResources,dc=example,dc=net", indicating that the queried resource is a referral for a web hosting server at Example Networks. The client uses this information to start a new query. No additional data was provided for the client to display. f. The "example.net" host identifier in the URL is used to form a new DNS SRV query for the LDAP servers associated with the domain name of "_ldap._tcp.example.net". g. An inetDnsDomainMatch extensibleMatch search is submitted to one of the LDAP servers, using the search base of "cn=server1.example.net,cn=inetResources,dc=example,dc=net" h. The queried server returns the information that it has. No additional referrals are provided. The client displays the data and exits the query. 7.3. Targeted Search Processing The targeted search model is similar to the bottom-up query model described in the preceding section, except that it does not provide fallback processing of DNS domain names. In this regard, the targeted search model is closely similar to the traditional LDAP searching model, in that a client queries a specified LDAP server for a specific entry, under the assumption that the resource exists at that location. If the server or resource does not exist, the entire query fails. For this reason, the targeted search model is not suitable for search operations against generic Internet resources, but instead is mostly suitable for searches against known entries which are presumed to exist at a known location. In terms of the LDAP-WHOIS service in particular, this includes inetOrgPerson entries which are provided in contact-related attributes. However, the targeted search model can be used for any resource type, and it can be useful for diagnosing problems with resource types. For this reason, clients SHOULD support this model for use with all known resource types. The targeted search takes an LDAP URL as the query input (along with the resource-type identifier), and uses the URL to determine the query server, the search base, and the assertion value. Hall & Newton I-D Expires: May 2002 [page 70] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 7.3.1. Processing steps The steps for processing targeted search queries are described below: a. Process the LDAP URLs according to the continuation reference referral handling rules described in section 7.4.3. This process will determine the search base and assertion value of the query, and will also generate DNS SRV lookups for the LDAP servers associated with the URL. b. If the SRV lookup succeeds: 1. Choose the best LDAP server, using the weighting formula described in RFC 2782. 2. Construct the LDAP search filter according to the rules specified in section 6.1, and choose the appropriate matching rule from section 6.2. 3. Submit the search operation. If the operation fails, report the failure to the user and exit. Otherwise, display any answer data which is returned. 4. If the answer data contains a subordinate reference referral or a continuation reference referral, new query processes MUST be spawned. For subordinate reference referrals, process the URLs according to the rules described in section 7.4.1 and restart the query process at step 7.3.1.b. For each continuation reference referral, display the answer data received so far, process the LDAP URLs according to the rules described in section 7.4.3 and start new query processes for each referral at step 7.3.1.b. Any additional subordinate reference referrals or continuation reference referrals which are encountered from any subsequent queries will need to be processed in the same manner as specified above, until no additional referrals are received. Hall & Newton I-D Expires: May 2002 [page 71] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 c. If the SRV lookup fails (where failure is defined as any DNS response message other than an answer), report the failure to the user and exit the current search operation. 7.3.2. Targeted search example In the example below, the user has provided an LDAP URL of "ldap://example.com/cn=hostmaster,ou=admins,dc=example,dc=com", and has indicated that the query is for an inetOrgPerson entry. a. The query string is used to form the DNS SRV lookup ("_ldap._tcp.example.com"), in order to find the LDAP servers authoritative for that domain name. b. The client contacts one of the servers, and issues a search for "(&(objectclass=inetOrgPerson)(cn:dn:=hostmaster))", with a search base of "ou=admins,dc=example,dc=com". c. The queried server returns the information that it has. No additional referrals are provided. The client displays the data and exits the query. 7.4. Supplemental Query Processing Mechanisms During the course of normal query processing, an LDAP-WHOIS client may need to use additional mechanisms to complete an operation, such as processing a URL received from a redirect operation, or issuing DNS SRV lookups against a provided domain name. 7.4.1. URL processing URL processing in this specification is a function of both content and context. Different attributes and result codes provide different types of URLs, and the disposition of these URLs will depend on the query-resolution process currently being executed. On the content front, this specification allows three different forms of URLs to appear throughout this service: labeledURI attribute values, attribute references, and referral messages. Each of these usage scenarios have slightly different restrictions and formats. Hall & Newton I-D Expires: May 2002 [page 72] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 * The labeledURI attribute is included with the inetResources object class for the purpose of informing end-users of a generic resource associated with an entry (such as an organization's home page). The labeledURI attribute is defined in RFC 2079 for the purpose of storing generic URLs as attribute values, and uses a two-part syntax of "url://any.host:port/any/path description", with the "description" string providing a free-text description of the target specified by the URL. * Attribute references also use the two-part format of the labeledURI attribute, but with some additional restrictions as described in section 4.5 of this document. * Subordinate and continuation reference referrals use URLs for the purpose of providing referral targets. The URL format specified in [namedref] is also an explicit subset of the labeledURI format, but without the "description" free-text block. When used with the LDAP-WHOIS service, subordinate and continuation referrals are subject to some additional rules as described in section 4.5 of this document. In order to facilitate multi-tiered searching, the use of URLs with subordinate and continuation reference referrals and attribute references MUST be limited to single-valued responses, MUST specify the LDAP or LDAPS protocols, MUST specify domain names which are resolvable with DNS SRV lookups, and MUST NOT specify port numbers. All of the URLs provided as part of LDAP- WHOIS service (regardless of their type) MUST specify a domain name and a path. Relative URLs without a domain identifier are explicitly forbidden by this specification, as are URLs that do not contain a path specification. Non-compliance with these requirements amounts to an error, and is sufficient cause to stop processing a query. Clients MAY implement support for additional protocol identifiers, and MAY attempt to resolve the IP address of a host part identifier if an SRV lookup fails (these may be useful features for browsing traditional LDAP servers or DITs). However, clients MUST NOT violate any other mandates in this document while doing so (in particular, clients MUST NOT break the query-processing procedures defined in sections 7.1, 7.2, and 7.3). Hall & Newton I-D Expires: May 2002 [page 73] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 7.4.2. Subordinate reference referrals Subordinate reference referrals and their schema are defined in [namedref]. Subordinate reference referrals use the SearchResultDone response with a Referral result code, which is defined and described in section 4.1.11 of RFC 2251. Subordinate reference referrals use a subset of the labeledURI syntax as defined in RFC 2079, and use the syntax definitions from RFC 2255 when LDAP URLs in particular are to be provided, although section 4.5 of this document also defines additional restrictions on the allowable URL syntax. In the context of the LDAP-WHOIS service, subordinate reference referrals are returned when the search base specified in a search operation exists as a referral object class with the ref attribute pointing to some other entry, resulting in queries with that search base being answered with a SearchResultDone referral response. This condition means that the current search operation cannot proceed past this point, and the search MUST be restarted. This will most often occur when the inetResources entry for a DIT has been redirected to another DIT, but it can also happen after continuation reference referrals have been followed or after targeted searches have been issued, and where the queried entry exists as a referral to some other entry. The output from processing a subordinate reference referral URL consists of a set of SRV resource records associated with a domain name, and a search base. These elements are used to restart a current search operation. The procedure for processing the URL returned in a subordinate reference referral is as follows: a. Validate that the attribute value only contains a single URL. This specification explicitly requires that only one URL be provided with subordinate reference referrals. b. Validate the protocol label. This specification only supports the use of LDAP and LDAPS service types. URLs with other protocol identifiers are treated as malformed. c. Extract the host identifier element and prepare to issue an SRV lookup against the provided domain name. This specification explicitly requires that host identifiers provide domain names which are usable for SRV lookups, and Hall & Newton I-D Expires: May 2002 [page 74] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 does not support the use of host-specific identifiers. URLs without host identifiers are to be treated as malformed. d. Extract and discard the port number identifier, if one has been provided in the URL. SRV resource records provide port numbers as answer data. e. Extract the path element from the URL for use as the search base of the subsequent search operation. URLs without path elements are to be treated as malformed. f. Extract and discard any description text which may have been provided with the URL. g. Process the domain name from step 7.4.2.c with an SRV lookup, as described in section 7.4.5. h. Restart the current search operation, using the path from step 7.4.2.e as the new search base. 7.4.3. Continuation reference referrals Continuation reference referrals and their schema are defined in [namedref]. Continuation reference referrals use the SearchResultReference response, which is defined and described in section 4.5.3 of RFC 2251. Continuation reference referrals use a subset of the labeledURI syntax as defined in RFC 2079, and use the syntax definitions from RFC 2255 when LDAP URLs in particular are to be provided, although section 4.5 of this document also defines additional restrictions on the allowable URL syntax. For this service, continuation reference referrals are returned when the search base specified in a search operation exists, but one or more of the answer elements exist as referral object classes, resulting in one or more SearchResultReference responses. This condition means that the current search operation has partially succeeded, but that additional searches SHOULD be started in order for all of the answer data to be retrieved (in many cases, no answer data will be provided, and in those situations, new queries will be required for any data to be retrieved). This will occur whenever the assertion value of a search has matched a resource entry which is being managed by another DIT, and can occur with any of the search operations described in this document. Hall & Newton I-D Expires: May 2002 [page 75] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 The output from processing a continuation reference referral URL consists of a set of SRV resource records associated with a domain name, a search base, and an assertion value. These elements are used to start new search operations. Multiple continuation reference referrals MAY be returned in response to a search, and each of them MUST be processed in order for all of the answer data to be retrieved. The procedure for processing the URL returned in a continuation reference referral is as follows: a. Validate that the attribute value only contains a single URL. This specification explicitly requires that only one URL be provided with continuation reference referrals. b. Validate the protocol label. This specification only supports the use of LDAP and LDAPS service types. URLs with other protocol identifiers are treated as malformed. c. Extract the host identifier element and prepare to issue an SRV lookup against the provided domain name. This specification explicitly requires that host identifiers provide domain names which are usable for SRV lookups, and does not support the use of host-specific identifiers. URLs without host identifiers are to be treated as malformed. d. Extract and discard the port number identifier, if one has been provided in the URL. SRV resource records provide port numbers as answer data. e. Extract the path element from the URL for use as the search base of the subsequent search operation. URLs without path elements are to be treated as malformed. f. Extract the left-most RDN from the search base constructed in step 7.4.3.e, and remove the naming attribute label from the resulting value. This string will be used as the assertion value for the subsequent search operation. For example, if the path element provided a distinguished name of "cn=example.com,cn=inetResources,dc=example,dc=com", then the "cn=example.com" RDN would be used to form the new assertion value of "example.com". g. Extract and discard any description text which may have been provided with the URL. Hall & Newton I-D Expires: May 2002 [page 76] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 h. Process the domain name from step 7.4.3.c with an SRV lookup, as described in section 7.4.5. i. Start a new search operation, using the new search base formed in step 7.4.3.e, and the new assertion value formed in step 7.4.3.f. 7.4.4. Attribute references Attribute references are defined in this document as attributes which provide URLs as pointers to contextually related information. These are not referrals, but instead are simple URLs returned as attribute values. In particular, this document defines multiple contact-related attributes which provide these URLs. Other documents may also define attributes which reuse the URL format defined here, or may define their own URL rules, as needed. Attribute references use the "url://domain.name/distinguished/name description" two-part URL syntax from RFC 2079, although section 4.5 of this document also defines additional restrictions on the allowable URL syntax. For this service, attribute reference URLs are returned when an entry has an attribute defined which uses them. Attribute references are not referrals, and do not require additional processing. Clients MAY automatically start new search operations when an attribute reference is encountered, or they MAY delay processing until a user requests the action. The output from processing a continuation reference referral URL consists of a set of SRV resource records associated with a domain name, a search base, an assertion value, and an object class filter. These elements are used to start new search operations. The procedure for processing the URL returned in an attribute reference is as follows: a. Validate that the attribute value only contains a single URL. This specification explicitly requires that only one URL be provided with attribute references. b. Validate the protocol label. This specification only supports the use of LDAP and LDAPS service types. URLs with other protocol identifiers are treated as malformed. Hall & Newton I-D Expires: May 2002 [page 77] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 c. Extract the host identifier element and prepare to issue an SRV lookup against the provided domain name. This specification explicitly requires that host identifiers provide domain names which are usable for SRV lookups, and does not support the use of host-specific identifiers. URLs without host identifiers are to be treated as malformed. d. Extract and discard the port number identifier, if one has been provided in the URL. SRV resource records provide port numbers as answer data. e. Extract the path element from the URL for use as the search base of the subsequent search operation. URLs without path elements are to be treated as malformed. f. Extract the left-most RDN from the search base constructed in step 7.4.4.e, and remove the naming attribute label from the resulting value. This string will be used as the assertion value for the subsequent search operation. For example, if the path element provided a distinguished name of "cn=example.com,cn=inetResources,dc=example,dc=com", then the "cn=example.com" RDN would be used to form the new assertion value of "example.com". g. Determine the object class filter to be used with the assertion value. This will depend on the attribute which provided the attribute reference. The contact-related attributes defined in this document refer to inetOrgPerson object class entries. h. Extract and discard any description text which may have been provided with the URL. i. Process the domain name from step 7.4.4.c with an SRV lookup, as described in section 7.4.5. j. Start a new search operation, using the new search base formed in step 7.4.4.e, the new assertion value formed in step 7.4.4.f, and the new object class filter formed in step 7.4.4.g. Hall & Newton I-D Expires: May 2002 [page 78] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 7.4.5. SRV processing The query models described in this document make extensive use of DNS SRV resource records in order to locate the LDAP servers which are authoritative for a particular resource (as specified by an input search string or a response URL). In both cases, a DNS domain name is constructed from the input, and a DNS SRV lookup is issued. The SRV resource records returned in response to such a query will identify the LDAP servers responsible for the queried domain name. The procedure for constructing this SRV lookup is as follows: a. Determine the service type associated with the request. For URLs, this will be indicated by a protocol identifier of either LDAP or LDAPS (for LDAP over SSL/TLS). For input queries, no identifier will be available, and the default assumption is LDAP. b. Construct an SRV-specific label pair for the service type. For LDAP queries, this will be "_ldap._tcp", while LDAPS will use "_ldaps._tcp". c. Append the SRV label pair to the left of the input domain name. In the case of an LDAP query for "example.com", this would result in an SRV-specific domain name of "_ldap._tcp.example.com". d. Issue a DNS query for the SRV resource records associated with the domain name formed in step 7.4.5.c. Multiple SRV resource records may be returned in response to a query. Each resource record identifies a different connection target, including the domain name of a server, and a port number for that server. The port number specified in a SRV resource record MUST be used for any subsequent bind and search operations. SRV resource records provide "priority" and "weight" values which MUST be used to determine the preferred server. If a server is unavailable or unreachable, a connection attempt must be made to the next-best server in the answer set. Refer to RFC 2782 for a detailed explanation of SRV resource records and their handling. Hall & Newton I-D Expires: May 2002 [page 79] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 8. Internationalization and Localization The LDAP-WHOIS model uses the internationalization and localization services provided by LDAPv3. In this regard, LDAP- WHOIS clients do not need to implement any special services in order to process and display attribute data, since the attribute types already provide direct support for internationalized data. LDAP-WHOIS clients may have some localization or language-specific presentation issues with regards to attribute names, in that the names of the attributes may need to be localized for specific markets. However, these services are outside the scope of the protocol operations. Any such requirements must be dealt with according to the services available on the client platform. In the case of legacy WHOIS servers which gateway requests between TCP port 43 and the LDAP-WHOIS service, the input and output language and/or locale codes MAY be specified by server-specific options, although these mechanisms must be defined as part of the WHOIS protocol for any widespread consistency to be possible, and are therefore beyond the scope of this document. 9. DIT Replication All DITs which provide data for global Internet resources SHOULD be replicated across two or more servers. Each of the authoritative LDAP servers for the managed resource MUST be specified with a unique DNS SRV resource record for the domain name associated with the top-level resource assignment space. For example, the top-level "com" delegation space SHOULD have two or more SRV resource records associated with the "_ldap._tcp.com" domain name, with each entry referring to separate LDAP servers, and with each of those servers maintaining accurate copies of the "dc=com" DIT (within reasonable timeliness). Similarly, the top- level " arpa" domain which is used by the IPv4 and IPv6 delegation trees SHOULD provide two or more SRV resource records for the "_ldap._tcp.arpa" domain name, as should the "in-addr.arpa" and "ip6.arpa" domain hierarchies. Branching DITs which serve multiple organizations SHOULD also be replicated. For example, an ISP which provides LDAP-WHOIS services for their customers SHOULD also follow these same rules, since Hall & Newton I-D Expires: May 2002 [page 80] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 outages of those servers will affect multiple parties. Leaf-node DITs associated with an user-managed resource MAY be replicated, and are encouraged to do so. Note that the most effective replication strategy will be for entities to replicate their DITs with the delegation parents, as this will allow queries for those resources to be processed by the parent servers (thereby eliminating the need for an additional query). In many cases, this will not be feasible (the servers for the "dc=com" DIT cannot be expected to host replicas of every subordinate DIT), but it is encouraged where practical. 10. Security Considerations This document describes an application of the LDAPv3 protocol, and as such it inherits the security considerations associated with LDAPv3, as described in section 7 of RFC 2251. The query processing models described in this document make use of DNS lookups in order to locate the LDAP servers associated with a particular resource. DNS is susceptible to certain attacks and forgeries which may be used to redirect clients to LDAP servers which are not authoritative for the resource in question. Furthermore, some operators may purposefully choose to provide misleading or erroneous information in an effort to avoid or escape responsibility for abusive behavior. In addition to the above, there are likely to be sporadic operator errors which will result in confusing or erroneous answers. For the reasons listed above, it is important that applications not make critical decisions based on the information provided without having reason to believe the veracity of the information. Clients and users should limit the use of unknown or untrusted information to routine purposes. Finally, there are physical security issues associated with any service which provides physical addressing and delivery information. Although organizations are generally encouraged to provide as much information as they feel comfortable with, no information is required. Hall & Newton I-D Expires: May 2002 [page 81] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 11. IANA Considerations This document defines an application of the LDAPv3 protocol rather than a new Internet application protocol. As such, there are no protocol-related IANA considerations. However, this document does define several LDAP schema elements, including object classes, attributes, syntaxes and extensibleMatch filters, and these elements should be assigned OID values from the IANA branch, rather than being assigned from a particular enterprise branch. Furthermore, this document defines delegation status codes for four of the resource types described herein, and IANA is expected to maintain the code-point mapping values associated with these attribute values. Each resource type may develop its own peculiar status codes, so each of the mapping tables will need to be maintained independently. Finally, this document also describes several instances where public DNS and LDAP servers are queried. It is expected that IANA will establish and maintain these LDAP servers (and the necessary DNS SRV domain names and resource records) required for this service to operate. This includes providing SRV resource records in the generic TLDs and the root domain, and also includes administering the referenced LDAP servers. 12. References RFC 1274 - The COSINE and Internet X.500 Schema RFC 2079 - Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs) RFC 2247 - Using Domains in LDAP/X.500 DNs RFC 2251 - Lightweight Directory Access Protocol (v3) RFC 2252 - Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions. RFC 2253 - Lightweight Directory Access Protocol (v3): UTF-8 String Representation of DNs RFC 2254 - The String Representation of LDAP Search Filters Hall & Newton I-D Expires: May 2002 [page 82] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 RFC 2255 - The LDAP URL Format RFC 2256 - A Summary of the X.500(96) User Schema for use with LDAPv3 RFC 2308 - Negative Caching of DNS Queries (DNS NCACHE) RFC 2782 - A DNS RR for specifying the location of services (DNS SRV) RFC 2798 - Definition of the inetOrgPerson LDAP Object Class RFC 2849 - The LDAP Data Interchange Format (LDIF) - Technical Specification [namedref] - - Named Subordinate References in LDAP Directories On a related note, VeriSign has been working on an RLDAP project [described in draft-newton-ldap-whois-00.txt (Whois Domain Data in LDAP)] that uses a query model very similar to the one described in this document, and which illustrates many of the points described in this document. The current RLDAP implementation has three client implementations, multiple distributed servers, and contains more than 32 million DNS domain entries, and 115 million resource-specific entries. In many regards, this document is an extension of RLDAP. 13. Author's Addresses Eric A. Hall ehall@ehsco.com Andrew Newton anewton@research.netsol.com 14. Transition Issues There are a handful of areas where the proposed service does not fully match with all of the existing WHOIS service offerings. These areas are discussed in more detail below. Hall & Newton I-D Expires: May 2002 [page 83] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 14.1. NIC Handles NIC handles represent a historical method of WHOIS lookups, tying unique identifiers to a specific record in a specific database. Given that the model proposed in this document uses a distributed lookup system rather than isolated databases, the NIC handle model is no longer necessary. Given its limited global usability, it is implicitly deprecated in this document and is replaced with a model that uses DNs for the lookup function. DNs provide the same basic functionality, but they work in a global distributed multi- server environment. However, NIC handles are an important part of the legacy service, and their continued usage is likely to be desired in at least some instances. There are two possible workarounds for this problem: * NIC handle output in legacy WHOIS systems SHOULD be replaced with an LDAP URL for the contact entries. This option facilitates faster coalescence around the LDAP-WHOIS system. * Referral entries MAY be defined for each existing NIC handle if the explicit NIC handle is still required for an application or usage, and queries for NIC handles MAY be processed through these referral entries. For example, the NIC handle of EH26 on Network Solutions server could be represented as "cn=EH26,cn=inetResources,dc=netsol,dc=com", with the inetOrgPerson and referral object classes defined, and with the ref attribute value pointing to an entry named "cn=Eric A. Hall,cn=inetResources,dc=ntrg,dc=com". Of the two mechanisms described above, the former is preferred. 14.2. Nameserver Attributes WHOIS servers for DNS domains have historically provided information about the DNS servers associated with a domain, such as providing the hostnames and IP addresses of the DNS servers which have been delegated authority over a particular domain. One problem with providing this information in the LDAP-WHOIS model is that it is difficult to integrate the data cleanly. The best design for such a service would entail an auxiliary object class for the inetDnsDomain object class which provided resource record attributes, and which stored NS and the associated A Hall & Newton I-D Expires: May 2002 [page 84] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 resource records as directory objects. While such a structure would provide multiple benefits to multiple problems, it seems imprudent to pursue this approach for the single short-term objective of caching delegation name servers. For this reason, attributes for this information are not provided in the LDAP-WHOIS service. Instead, users and application developers are encouraged to develop practices for querying the DNS zones for information related to DNS. However, if this information is absolutely required, server operators MAY provide it as unstructured data in the inetGeneralComments free-text attribute (possibly using a name:address pair for each server). 14.3. Change-Logs Several WHOIS services provide pseudo change-logs in their response data, listing each unique modification event which has occurred for a particular resource. For example, RIPE and some of its member ccTLDs provide WHOIS output which includes a series of "changed" fields that itemize every modification event ("updated", "added", etc.), the modifier, and the modification date, which cumulatively act as a change-log for the resource in question. While this service is useful and informative to the delegating bodies, this information is not necessarily useful to external entities. Organizations are certainly free to maintain this information on their internal systems (and are even encouraged to do so). However, this information is not necessary for the public view of the data via the LDAP-WHOIS service. Furthermore, it is difficult to mimic this usage in an LDAP-based WHOIS service in a form which can be easily parsed. Even though it would be possible to provide multi-value free-text fields which provide a similar service, the data would not be subject to referential integrity or programmatic parsing. For these reasons, this service is not provided in the LDAP-WHOIS service. However, if this information is absolutely required, implementers MAY provide it as additional unstructured data via the inetGeneralComments attribute (perhaps using an "event:modifier:date" format). Hall & Newton I-D Expires: May 2002 [page 85] INTERNET-DRAFT draft-hall-ldap-whois-00.txt November 2001 14.4. Open Issues The following issues require additional analysis: * inetIpv6Network entries will likely benefit from certificate-related data, although the extent and nature of this information (minimum requirements, preferred attributes, pre-existing schema, etcetera) is currently unknown by the authors. * The RIPE database v3 has several additional attributes: domain: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] zone-c: [mandatory] [multiple] [inverse key] nserver: [optional] [multiple] [inverse key] sub-dom: [optional] [multiple] [inverse key] dom-net: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] refer: [optional] [single] [ ] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] http://www.ripe.net/ripe/docs/databaseref-manual.html * The URL processing defined in this document does not follow "normal" URL processing rules. This is due to a strong desire to leverage the load-distribution functionality provided by SRV resource records, although URLs and SRV resource records overlap in some areas, yet both of them provide critical information to the referral process. In order for these two services to work together, the URL syntax has been optimized for use with this service (this practice is not entirely uncommon). However, this problem will not be completely resolved until a standards-track effort confronts the issue globally. Hall & Newton I-D Expires: May 2002 [page 86]