[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

                                                             Eric A. Hall
                                                               Consultant
  INTERNET-DRAFT                                            Andrew Newton
  Document: draft-hall-ldap-whois-01.doc                   VeriSign, Inc.
  Expires: August, 2002                                     February 2002
  
  
                     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 searching rules for four
     Internet resource types: DNS domains, IPv4 addresses, IPv6
     address, and AS numbers. The framework specified in this document
     also allows additional documents to define additional Internet
     resource types and their handling rules.
  
  
  
  
  
  
  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
     Table of Contents
  
     1.   Abstract..................................................1
     2.   Definitions and Terminology...............................3
     3.   Background, Objectives and Overview.......................4
       3.1.  Background..............................................4
       3.2.  Overview................................................5
     4.   The LDAP-WHOIS Namespace..................................6
       4.1.  Namespace Example.......................................7
       4.2.  The domainComponent LDAP Hierarchy......................9
       4.3.  The inetResources Container............................10
       4.4.  Resource-Specific Entries..............................11
       4.5.  Redirects and Referrals................................12
     5.   The LDAP-WHOIS Object Classes and Attributes.............17
       5.1.  The inetResources Object Class.........................18
       5.2.  The inetDnsDomain Object Class.........................24
       5.3.  The inetIpv4Network Object Class.......................31
       5.4.  The inetIpv6Network Object Class.......................36
       5.5.  The inetAsNumber Object Class..........................42
       5.6.  The inetAssociatedResources Object Class...............47
       5.7.  The inetOrgPerson Object Class.........................52
       5.8.  The referral Object Class..............................52
       5.9.  Object Class and Attribute Permissions.................53
     6.   Search and Match Filters.................................54
       6.1.  Search Filter Expressions..............................55
       6.2.  Matching Filter Definitions............................57
     7.   Query Processing Models..................................62
       7.1.  Top-Down Processing....................................63
       7.2.  Bottom-Up Processing...................................67
       7.3.  Targeted Search Processing.............................72
       7.4.  Supplemental Query Processing Mechanisms...............74
     8.   Internationalization and Localization....................80
     9.   DIT Replication..........................................81
     10.  Transition Issues........................................82
       10.1. NIC Handles............................................82
       10.2. Change-Logs............................................83
       10.3. Open Issues............................................83
     11.  Security Considerations..................................84
     12.  IANA Considerations......................................85
     13.  Author's Addresses.......................................86
     14.  References...............................................86
     15.  Changes from Previous Versions...........................87
  
  
  
  
  
  Hall & Newton          I-D Expires: August 2002              [page 2]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
  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] - <draft-zeilenga-ldap-namedref-04.txt> - Named
            Subordinate References in LDAP Directories
  
            [ir-dir-req] - <draft-newton-ir-dir-requirements-00.txt> -
            Internet Registry Directory Requirements
  
     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
  
  
  Hall & Newton          I-D Expires: August 2002              [page 3]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
            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")
            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 network
     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.
  
     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 that 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.
     Similarly, there are WHOIS servers which are operated by service
     providers which provide information about the 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
     information in only one language and charset, while others support
  
  
  Hall & Newton          I-D Expires: August 2002              [page 4]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     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,
     which has made programmatic processing of the data difficult.
  
     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 clients to
     other servers for additional information.
  
     Another concern is that the WHOIS services which are being
     operated today offer no means of client authentication, requiring
     that server operators essentially publish all data with a single
     "world-readable" permission. However, this single permission
     conflicts with the privacy and security policies of specific
     jurisdictions. A more flexible mechanism for controlling the
     release of physical and personal information is required in order
     to meet the requirements of the varying 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 and highly-
     structured WHOIS-like service, using the LDAP protocol for the
     query/response transfer service, and using LDAP schema for the
     search inputs, answer data, and redirection mechanisms. In short,
     the intention of this approach is to provide an extensible and
     scalable WHOIS service, leveraging the capabilities of LDAP.
  
  
  3.2.    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 Namespace. This document makes use of an LDAP
            namespace which is built upon the existing DNS delegation
            hierarchy, and which is supplemented by a layered namespace
  
  
  Hall & Newton          I-D Expires: August 2002              [page 5]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
            consisting of service-specific containers and resource-
            specific entries. This namespace and the associated naming
            rules facilitate the programmatic formation of queries,
            structured data, and referrals.
  
        *   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.
  
        *   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 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 querying centrally-managed Internet resources,
            a "bottom-up" model which is designed for querying user-
            managed resources, and a "targeted search" model which is
            designed for querying known servers for information about
            known resources. 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 data-types and usage models, including future uses which
     are not defined here.
  
  
  4.      The LDAP-WHOIS Namespace
  
     A critical aspect of this service is the use of a predictable
     naming syntax, both for the automatic creation of programmatic
     searches for data, and for publishing structured data and
     referrals. In order to ensure this predictability, this document
     defines a multi-layered syntax which MUST be used by all compliant
     implementations.
  
  
  
  
  Hall & Newton          I-D Expires: August 2002              [page 6]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     The LDAP-WHOIS service also makes provisions for the use of
     multiple referral services for the purpose of redirecting LDAP
     clients to foreign directory information trees (DITs). This allows
     organizations to redirect queries to external service providers,
     consolidate DITs within a single server, maintain foreign objects
     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.
     This namespace will be used throughout this document to illustrate
     many of the concepts from this specification.
  
     Figure 1: Namespace for Example Widgets' domain and network.
  
     DIT: dc=example,dc=com
      |
      +-cn=inetResources,dc=example,dc=com
        [top object class]
        [inetResources object class]
        |
        +-attribute: o
        | value: "Example Widgets, Inc. public network resources"
        |
        +-cn=example.com,cn=inetResources,dc=example,dc=com
        | [top object class]
        | [inetResources object class]
        | [inetDnsDomain object class]
        | |
        | +-attribute: inetDnsContacts
        |   value: "ldap://ldap.example.com/cn=hostmaster,
        |             ou=admins,dc=example,dc=com"
        |
        +-cn=2.0.192.in-addr.arpa,cn=inetResources,dc=example,dc=com
        | [top object class]
        | [inetResources object class]
        | [inetDnsDomain object class]
        | |
        | +-attribute: description
        | | value: "Example Widgets' reverse-lookup domain"
        | |
  
  
  
  
  Hall & Newton          I-D Expires: August 2002              [page 7]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
        | +-cn=cref1,cn=2.0.192.in-addr.arpa,
        |        cn=inetResources,dc=example,dc=com
        |   [top object class]
        |   [inetResources object class]
        |   [inetDnsDomain object class]
        |   [referral object class]
        |   |
        |   +-attribute: ref
        |     value: "ldap://ldap.example.com/cn=example.com,
        |               cn=inetResources,dc=example,dc=com"
        |
        +-cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com
          [inetResources object class]
          [inetIpv4Network object class]
          |
          +-attribute: inetIpv4Contacts
            value: "ldap://ldap.example.com/cn=hostmaster,
                      ou=admins,dc=example,dc=com"
  
     DIT: dc=2,dc=0,dc=192,dc=in-addr,dc=arpa
      |
      +-cn=inetResources
        [top object class]
        [inetResources object class]
        [referral object class]
        |
        +-attribute: ref
          value: "ldap://ldap.example.com/cn=inetResources,
                    dc=example,dc=com"
  
     Figure 1 shows different DITs, both of which are managed by the
     Example Widgets company. The "dc=example,dc=com" DIT is
     authoritative for the DNS domain of "example.com", while the
     "dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" DIT is authoritative for the
     reverse-lookup DNS domain of 2.0.192.in-addr.arpa and the IPv4
     network of "192.0.2.0/24".
  
     Both DITs have container entries called "cn=inetResources". This
     container entry is responsible for holding all of the entries
     which are associated with the Internet resources that are being
     managed by the LDAP-WHOIS service. For example, the
     "cn=inetResources,dc=example,dc=com" entry contains a subordinate
     entry for "cn=example.com", which is a DNS domain that is being
     managed through the LDAP-WHOIS service, and also contains entries
     for the 2.0.192.in-addr.arpa reverse-lookup DNS domain and the
     192.0.2.0/24 IPv4 network.
  
  
  Hall & Newton          I-D Expires: August 2002              [page 8]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
     The "cn=inetResources,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" entry
     only exists as a referral which will cause queries to be
     redirected to the "cn=inetResources,dc=example,dc=com" hierarchy.
  
     The naming syntax and rules are described throughout the remainder
     of this section 4.1. Figure 1 is only provided as an example a
     relatively complete namespace, for illustration and subsequent
     discussion purposes.
  
  
  4.2.    The domainComponent LDAP Hierarchy
  
     The top-level of the namespace defined for use with this service
     uses the domainComponent naming syntax specified in RFC 2247,
     which maps DNS domain names to domainComponent ("dc=") labels to
     form a DIT. Each DIT represents a primary identifier for the
     management body that is offering an LDAP server, and as such,
     provides a primary identifier for the Internet resources under the
     control of that organization. The DITs will be used to build LDAP
     queries for specific resources, and will also be used to locate
     the LDAP servers associated with the controlling organization.
  
     Examples of the RFC 2247 syntax are shown in Figure 2 below.
  
     Figure 2: The LDAP-WHOIS domainComponent Namespace.
  
                                    dc=.
                                      |
                     +----------------+---------------+
                    /                 |                \
               dc=arpa              dc=com          dc=[...]
                   |                  |
                +--+--+           dc=example
               /       \
         dc=in-addr   dc=ip6
  
     A complete sequence of domainComponent DNs represents the scope of
     the DIT. For example, a DIT with the distinguished name (DN) of
     "dc=com" is authoritative for all of the LDAP resources within the
     "com" DNS domain (for many LDAP-WHOIS queries, this will also
     include any sub-domains under the "com" domain). Meanwhile, a DIT
     with the DN of "dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" DIT is
     authoritative for domain name resources within the reverse-lookup
     "2.0.192.in-addr.arpa" DNS domain, as well as the IPv4 network
     addresses within the 192.0.2.0/24 network. At the other extreme,
  
  
  Hall & Newton          I-D Expires: August 2002              [page 9]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     the dc="." DIT is responsible for all Internet resources (although
     this DIT is rarely used).
  
     Since the DIT determines the scope of control over a set of
     resources, DITs that overlap also have overlapping scopes of
     control. For example, the "dc=com" and "dc=example,dc=com" DITs
     can both provide information about the "www.example.com" domain
     name resource. In order to allow end-users to specify which scope
     they wish to work with for any given query, this document defines
     three different query models (these are described in section 7).
  
     When the LDAP servers associated with the chosen DIT need to be
     located, the domainComponent DNs from the DIT are mapped to a DNS
     domain name, and a query is issued for the LDAP servers associated
     with that domain name (this process is also described in section
     7). This means that the authority to process LDAP searches for a
     DIT comes directly from the portion of the DNS namespace already
     under the control of that management body. For example, the LDAP
     servers which are used to process queries for the "dc=com" DIT
     will be located by querying the DNS zone responsible for the "com"
     portion of the DNS namespace, and so forth.
  
  
  4.3.    The inetResources Container
  
     This specification requires the use of a mandatory LDAP container
     entry with the well-known relative distinguished name (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
     cn=inetResources container entry.
  
     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 several 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
  
  
  Hall & Newton          I-D Expires: August 2002             [page 10]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     referral operation (this will be particularly important when the
     LDAP servers that are located by DNS lookups are not the same
     servers that provide LDAP-WHOIS services). 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, each of which
     have their own naming rules. However, each resource type has a
     consistent naming principle, in that the specific managed resource
     has an RDN which uniquely identifies that resource, with the RDN
     residing within the inetResources container entry.
  
     For example, an entry for the "www.example.com" domain name
     resource stored in the "dc=example,dc=com" DIT would have a DN of
     "cn=www.example.com,cn=inetResources,dc=example,dc=com", while an
     entry for the "192.0.2.0/24" IPv4 network resource would have a DN
     of "cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com". Although
     the relative naming syntax is different for each resource type,
     the resource naming is consistent for each type, and the position
     of the RDN within the DN is also predictable.
  
     Most resource types cannot be located through simple LDAP browsing
     and equality matches. 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. In order to allow the
     appropriate entry to be located, however, the client can use the
     inetIpv4NetworkMatch extensible matching search operation, which
     locates the appropriate entry based on the search input.
  
     The naming rules associated with each resource type are provided
     in section 5, along with the schema definitions for each of the
     resource types. The extensible matching filters associated with
     each resource type are described in section 6.
  
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 11]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  4.5.    Redirects and Referrals
  
     A critical objective behind this service is for servers to be able
     to redirect clients to other servers, entries, or DITs, when this
     is necessary or desirable. Towards this end, 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
     for the original query to be completely exhausted. 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 as a part of this service
            are to be 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 LDAP URLs as their input data,
     although these URLs have service-specific restrictions that are
     somewhat tighter than the source specifications allow.
  
     Among these rules:
  
        *   All referenced entries 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 entry, and resource-specific
            entries MUST comply with the naming rules for the resource
            type in question.
  
        *   Referral sources and targets MUST have the same resource-
            specific object classes defined (for example, the referral
  
  
  Hall & Newton          I-D Expires: August 2002             [page 12]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
            source and target for a DNS domain resource would both have
            the inetDnsDomain object class defined). 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.
  
        *   Referenced entries MAY exist as referrals to other entries,
            but recursive referrals are discouraged.
  
        *   Except where otherwise noted, the protocol identifier of a
            URL MUST specify either the LDAP or LDAPS (LDAP over
            TLS/SSL) service types. Although general-purpose LDAP
            referrals are allowed to specify any URL, LDAP-WHOIS
            referrals and references are intended to be used for
            automated queries, so the use of other protocols or
            services is expressly forbidden.
  
        *   The host identifier of a URL MUST specify either an IP
            address or a domain name. URLs which do not provide host
            identifiers are invalid in all cases.
  
        *   URLs MUST be provided and stored in a URL-safe format. For
            example, the IPv4 and IPv6 network address syntaxes defined
            in this document make use of the forward-slash ("/")
            character to indicate a subnet prefix, and if this
            character needs to be provided in a URL, it must be
            provided in the escaped form ("%2F" in this example).
            Furthermore, some of the matching rules described in this
            document require that the URLs also be stored in this
            format in order for the searches to succeed.
  
        *   Implementations MUST NOT restrict URL values to verifiable
            entries from local partitions. Implementations MAY validate
            targets when the partition is known and accessible, but a
            lack of knowledge regarding a target MUST NOT be cause to
            prevent the entry from being specified.
  
     Clients MAY implement support for additional protocol identifiers
     if they wish to act upon URLs which are provided in conflict with
     the requirements above. 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
     section 7 of this document).
  
     Each of the supported redirection mechanisms are discussed in more
     detail below.
  
  
  Hall & Newton          I-D Expires: August 2002             [page 13]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
  
  4.5.1.  Subordinate reference referrals
  
     Subordinate reference referrals are returned when the search base
     specified in a query names an entry which exists as a referral
     object class that points to some other entry.
  
     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 an inetResources container in another DIT.
  
     For example, the namespace shown in Figure 1 has an entry of
     "cn=inetResources,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" defined
     with the referral object class, with the ref attribute value
     pointing to the LDAP server of "ldap.example.com" and the DN of
     "cn=inetResources,dc=example,dc=com". Any queries for resources
     within "cn=inetResources,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa"
     would be answered with that subordinate reference referral, and
     these queries would have to be restarted using the specified
     search base and server before they would be processed.
  
     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 source MUST be defined with the referral object
     class, and MUST also be defined with the appropriate object class
     for that resource type. For example, a "cn=inetResources" entry
     which provided a subordinate reference referral would need to have
     both the referral and inetResources object classes defined, while
     a DNS domain resource such as "dc=example.com" would need to have
     both the referral and inetDnsDomain object classes defined (among
     the other object class definitions which were required for 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.
  
     Client rules for processing subordinate reference referrals are
     given in section 7.4.1.
  
  
  Hall & Newton          I-D Expires: August 2002             [page 14]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
  
  4.5.2.  Continuation reference referrals
  
     Continuation reference referrals are returned when a search
     operation has been successfully processed by the queried server,
     but the answer data also includes referrals to other entries.
     These referrals are often provided as supplemental data to an
     answer set, although this is not required (a continuation
     reference referral can be the only response, but it won't be the
     only response in the common case).
  
     For example, the namespace shown in Figure 1 has an entry of
     "cn=cref1,cn=2.0.192.in-addr.arpa,cn=inetResources,dc=example,
     dc=com" defined with the referral object class, with the ref
     attribute value pointing to the LDAP server of "ldap.example.com"
     and the DN of "cn=example.com,cn=inetResources,dc=example,dc=com".
     Any answers to any queries about "cn=2.0.192.in-addr.arpa" would
     also include the continuation reference referral, and new queries
     for the referral target would have to be issued before the
     original queries were completely processed.
  
     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 queried resource, but one or more
     entries MUST exist 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.
  
     Continuation reference referrals are returned in response to
     specific extensible match queries, and have specific naming
     requirements which are necessary for the matching functions to
     work properly. These considerations are described in 7.4.3.
  
     Client rules for processing continuation reference referrals are
     also 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
  
  
  Hall & Newton          I-D Expires: August 2002             [page 15]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     currently being viewed. Attribute references use the same basic
     syntax as the labeledURI attribute defined in RFC 2079, although
     there are additional restrictions, as described 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
     URLs in order to locate and read the inetOrgPerson entries,
     although such actions are secondary to the original query process,
     and will typically only be performed at the user's request.
  
     For example, the namespace shown in Figure 1 has an entry of
     "cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com" defined with
     the inetIpv4Network object class, with the inetIpv4Contacts
     attribute value pointing to the LDAP server of "ldap.example.com"
     and the DN of "cn=hostmaster,ou=admins,dc=example,dc=com". When
     this attribute is provided as part of an answer to a query, a
     client MAY choose to follow this URL for information about that
     contact, although this would be considered a new and separate
     query, and would not be required to satisfy the original query.
  
     Note that the attribute reference URLs are similar to the URLs
     defined in RFC 2079, and use 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. When the descriptive text is provided
     in an attribute reference, it SHOULD be displayed to the user as
     potentially informative data.
  
     Client rules for processing attribute references are given in
     section 7.4.4.
  
  4.5.4.  labeledURI references
  
     Some of the object classes defined in this document make use of
     the labeledURI attribute, as defined by RFC 2079. These attributes
     (and their values) are not governed by this document, but instead
     are governed by RFC 2079. As such, the rules set forth in RFC 2079
     always apply to those attributes. In particular, this means that
     those attribute values may reference any protocol (such as
     http://) and are not restricted to LDAP protocol targets.
  
  
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 16]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
  5.      The LDAP-WHOIS Object Classes and Attributes
  
     This document defines a general framework for locating information
     about public network resources in a distributed environment, and a
     critical element of this definition are schema definitions for the
     object classes and attributes that provide this information.
  
     Towards that end, this document defines a schema for the global
     inetResources object class which is inherited by all of the
     resource-specific types, defines four resource-specific object
     classes, and defines a generalized object class for cross-
     referencing resources. This document also takes advantage of some
     pre-existing schema definitions (in particular, the inetOrgPerson
     object class), where suitable schema were available. Each of the
     schema definitions provided in this document include attribute
     definitions, naming rules, and other definitions which are
     designed to facilitate searching and browsing Internet resources.
  
     The following resource definitions are provided 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 organization or the resources
            under its control, 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.
  
        *   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.
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 17]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
        *   Autonomous system (AS) identifiers. IPv4 and IPv6 networks
            can 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 numbers, and is also subordinate to the inetResources
            object class.
  
        *   Associated objects. Internet resources are typically
            assigned by independent entities, although there is often
            an extensive amount of cross-pollination. For example, AS
            Numbers are typically associated with IPv4 and IPv6 address
            blocks, with this association being considered as a
            mandatory linkage. However, less-formal associations also
            often exist, such as a private organization associating an
            IP address block with a specific DNS domain, or where a
            regional authority is responsible for all domain name and
            IP address delegations. Due to this flexibility, the LDAP-
            WHOIS service provides an auxiliary object class for
            associated objects which may be used with any of the
            resource-specific object classes defined in this document.
  
        *   Persons. This document makes use of the inetOrgPerson
            object class definition for the purpose of describing
            people and administrative roles.
  
     Each of the attributes and object classes listed above represent
     the Internet-wide network resources which MAY be offered by an
     LDAP-WHOIS server. It is expected that additional network resource
     definitions will be provided by other documents.
  
  
  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: August 2002             [page 18]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
  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: August 2002             [page 19]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     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 $
            inetGeneralDisclaimer ) )
  
     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: August 2002             [page 20]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
          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 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 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: August 2002             [page 21]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
          inetGeneralDisclaimer
          ( 1.3.6.1.4.1.7161.1.0.7 NAME 'inetResourceComments' DESC
            'General disclaimer text regarding this data' EQUALITY
            caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
            )
  
          inetResourceComments
          ( 1.3.6.1.4.1.7161.1.0.8 NAME 'inetResourceComments' DESC
            'General comments about this entry' EQUALITY
            caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
            )
  
          inetSecurityContacts
          ( 1.3.6.1.4.1.7161.1.0.9 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.10 NAME
            'inetSecurityContactsModifiedBy' DESC 'Person who last
            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.11 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.12 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.13 NAME 'inetTechContactsModifiedBy'
            DESC 'Person who last modified the inetTechContacts
            attribute.' EQUALITY distinguishedNameMatch SYNTAX
            1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
            distributedOperation )
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 22]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
          inetTechContactsModifiedDate
          ( 1.3.6.1.4.1.7161.1.0.14 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 )
  
          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.
  
  
  
  
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 23]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
     Figure 3: The Example Widgets inetResources container entry.
  
       cn=inetResources,dc=example,dc=com
       [top object class]
       [inetResources object class]
       |
       +-attribute: o
       | value: "Example Widgets' network resources"
       |
       +-attribute: inetGeneralContacts
       | value: "ldap://ldap.example.com/cn=admins,ou=admins,
       |           dc=example,dc=com"
       |
       +-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, such as a zone, a well-known host, or some other
     network resource which is primarily identified by a domain name.
  
  
  5.2.1.  Naming syntax
  
     The naming syntax for DNS domain entries MUST follow the form of
     "cn=<inetDnsDomainSyntax>,cn=inetResources,<dc-DIT>". Each DNS
     domain name which is managed as a discrete LDAP-WHOIS resource
     MUST have a dedicated entry in each of the DITs which provide
     public LDAP-WHOIS data for that resource.
  
     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
  
  
  Hall & Newton          I-D Expires: August 2002             [page 24]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     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
     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, for example), 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 character in 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 while minimizing
     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.
  
     STD 13 and RFC 2253 both use a common method of escaping special
     characters with a reverse solidus (backslash) character, with
  
  
  Hall & Newton          I-D Expires: August 2002             [page 25]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     either the special character or a two-digit decimal code for that
     character immediately following the reverse solidus.
  
     For example, if a user needs to specify the 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 entered into 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.
  
     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. For any
     domain name which contains a non-root label, the trailing period
     which normally signifies the root domain MUST be omitted. The
     maximum size of a valid DNS domain name is 255 characters (this
     limit applies to the unescaped assertion value). Clients MUST
     restrict input to this range, 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
  
  
  Hall & Newton          I-D Expires: August 2002             [page 26]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     syntax would also be used to form the RDN for the associated
     inetDnsDomain entry.
  
     Note that reverse-lookup domain names are mapped directly as they
     exist in the public DNS namespace. If a /24 IPv4 network block
     such as 192.0.2.0 has been delegated to an organization, the
     default controlling domain name of the reverse-lookup zone will be
     2.0.192.in-addr.arpa, and the name of the associated LDAP-WHOIS
     entry would be "cn=2.0.192.in-addr.arpa". However, if that network
     had been delegated to an ISP who had in turn delegated the
     192.0.2.0/29 address block and an associated reverse-lookup zone
     of 29-0.2.0.192.in-addr.arpa to a user, then the associated LDAP-
     WHOIS entry for that zone would be "cn=29-0.2.0.192.in-addr.arpa".
  
  
  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.
  
     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.
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 27]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     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 $ inetDnsAuthServers ) )
  
     The attributes from the inetDnsDomain object class are described
     below:
  
          inetDnsAuthServers
          ( 1.3.6.1.4.1.7161.1.1.2 NAME 'inetDnsAuthServers' DESC
            'Authoritative DNS servers for this domain.' EQUALITY
            caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
  
            The inetDnsAuthServers attribute provides a read-only
            summary of the authoritative servers associated with the
            zone. The attribute is defined as multi-valued, with each
            attribute value currently (tentatively) being defined as:
  
                 domain.dom [address/prefix]
  
            where "domain.dom" is the domain name of the authoritative
            server, written as an inetDnsDomainSyntax string, and where
            "address/prefix" is an IPv4 or IPv6 host-specific network
            address, written as either an inetIpv4NetworkSyntax or
            inetIpv6NetworkSyntax string. Clients that wish to obtain
            additional information about the listed servers can issue
            new queries for either the domain name or address syntax.
  
            NOTE: THIS IS A TEMPORARY ATTRIBUTE WHICH WILL EVENTUALLY
            BE REPLACED WITH GENERALIZED RESOURCE-RECORD ENTRIES AND
            ATTRIBUTES.
  
  
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 28]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
          inetDnsContacts
          ( 1.3.6.1.4.1.7161.1.1.3 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 )
  
          inetDnsContactsModifiedBy
          ( 1.3.6.1.4.1.7161.1.1.4 NAME 'inetDnsContactsModifiedBy'
            DESC 'Person who last 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.5 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.6 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.7 NAME 'inetDnsDelegationModifiedBy'
            DESC 'Person who last 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.8 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.9 NAME 'inetDnsDelegationStatus' DESC
            'Current delegation status code for this domain.' EQUALITY
  
  
  Hall & Newton          I-D Expires: August 2002             [page 29]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
            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   Assigned but on hold (disputed)
                 4   Assignment revoked (database purge pending)
  
            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
       [top object class]
       [inetResources object class]
       [inetDnsDomain object class]
       |
       +-attribute: description
       | value: "The example.com DNS domain"
       |
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 30]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
       +-attribute: inetDnsContacts
       | value: "ldap://ldap.example.com/cn=hostmaster,ou=admins,
       |           dc=example,dc=com"
       |
       +-attribute: inetGeneralContacts
         value: "ldap://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=<inetIpv4NetworkSyntax>,cn=inetResources,<dc-DIT>". 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 the sub-components being separated by a full-stop
     (period) character, and with the four-part sequence being followed
     by a "/" character and a three-digit decimal "prefix" value. An
     augmented BNF for this syntax is as follows:
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 31]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
          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 single-digit numeric value of "0".
  
     Note that the use of "/" is illegal in LDAP URLs when it is
     provided as data (in particular, URLs use this character as a part
     delimiter). This character MUST be escaped as "%2F" when it is
     provided as part of an inetIpv4Network entry 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: August 2002             [page 32]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     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 ) )
  
     The attributes from the inetIpv4Network object class are described
     below:
  
          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 )
  
          inetIpv4ContactsModifiedBy
          ( 1.3.6.1.4.1.7161.1.2.3 NAME 'inetIpv4ContactsModifiedBy'
            DESC 'Person who last modified the inetIpv4Contacts
            attribute.' EQUALITY distinguishedNameMatch SYNTAX
            1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
            distributedOperation )
  
  
  
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 33]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
          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 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: August 2002             [page 34]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
            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   Assigned but on hold (disputed)
                 4   Assignment revoked (database purge pending)
  
            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
            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 )
  
  
  
  
  
  
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 35]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
     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.' )
  
  
  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
       [top object class]
       [inetResources object class]
       [inetIpv4Network object class]
       |
       +-attribute: description
       | value: "The example.com network"
       |
       +-attribute: inetIpv4Contacts
       | value: "ldap://ldap.example.com/cn=hostmaster,ou=admins,
       |           dc=example,dc=com"
       |
       +-attribute: inetGeneralContacts
         value: "ldap://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
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 36]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     often used to represent the starting address of an IPv6 network,
     but can also be used to identify a specific host).
  
  
  5.4.1.  Naming syntax
  
     The naming syntax for IPv6 network entries MUST follow the form of
     "cn=<inetIpv6NetworkSyntax>,cn=inetResources,<dc-DIT>". 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
  
  
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 37]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
     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
     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 "/" is illegal in LDAP URLs when it is
     provided as data (in particular, URLs use this character as a part
     delimiter). This character MUST be escaped as "%2F" when it is
     provided as part of an inetIpv6Network entry 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.
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 38]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     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 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 ) )
  
     The attributes from the inetIpv6Network object class are described
     below:
  
          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 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 )
  
  
  
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 39]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
          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 )
  
          inetIpv6DelegationModifiedBy
          ( 1.3.6.1.4.1.7161.1.3.6 NAME 'inetIpv6DelegationModifiedBy'
            DESC 'Person who last 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   Assigned but on hold (disputed)
                 4   Assignment revoked (database purge pending)
  
            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: August 2002             [page 40]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
          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 )
  
          inetIpv6RoutingContactsModifiedBy
          ( 1.3.6.1.4.1.7161.1.3.10 NAME
            'inetIpv6RoutingContactsModifiedBy' DESC 'Person who last
            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.
  
  
  
  
  
  
  
  
  
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 41]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
     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
       [top object class]
       [inetResources object class]
       [inetIpv6Network object class]
       |
       +-attribute: description
       | value: "The example.net top-level network"
       |
       +-attribute: inetIpv6Contacts
       | value: "ldap://ldap.example.com/cn=hostmaster,ou=admins,
       |           dc=example,dc=net"
       |
       +-attribute: inetGeneralContacts
         value: "ldap://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=<inetAsNumberSyntax>,cn=inetResources,<dc-DIT>". 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.
  
  
  Hall & Newton          I-D Expires: August 2002             [page 42]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
     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
  
     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, and the status of the
     delegation. 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.
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 43]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     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);
     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 ) )
  
     The attributes from the inetIpv4Network object class are described
     below:
  
          inetAsnContacts
          ( 1.3.6.1.4.1.7161.1.4.2 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.3 NAME 'inetAsnContactsModifiedBy'
            DESC 'Person who last modified the inetAsnContacts
            attribute.' EQUALITY distinguishedNameMatch SYNTAX
            1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
            distributedOperation )
  
  
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 44]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
          inetAsnContactsModifiedDate
          ( 1.3.6.1.4.1.7161.1.4.4 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 )
  
          inetAsnDelegationDate
          ( 1.3.6.1.4.1.7161.1.4.5 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.6 NAME 'inetAsnDelegationModifiedBy'
            DESC 'Person who last 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.7 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.8 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 )
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 45]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
            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   Assigned but on hold (disputed)
                 4   Assignment revoked (database purge pending)
  
            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.
  
          inetAsnRoutingContacts
          ( 1.3.6.1.4.1.7161.1.4.9 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.10 NAME
            'inetAsnRoutingContactsModifiedBy' DESC 'Person who last
            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.11 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.' )
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 46]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
  5.5.3.  Example
  
     An example of the inetAsNumber object class is shown in Figure 7
     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.
  
     Figure 7: The inetAsNumber delegation entry for AS 65535.
  
       cn=65535,cn=inetResources,dc=arin,dc=net
       [top object class]
       [inetResources object class]
       [inetAsNumber object class]
       |
       +-attribute: description
       | value: "The example.net network"
       |
       +-attribute: inetAsnContacts
       | value: "ldap://ldap.example.com/cn=hostmaster,ou=admins,
       |           dc=example,dc=net"
       |
       +-attribute: inetGeneralContacts
         value: "ldap://ldap.example.com/cn=admins,ou=admins,
                   dc=example,dc=net"
  
  
  5.6.    The inetAssociatedResources Object Class
  
     The inetAssociatedResources object class defines cross-reference
     attributes which may be used with any of the object classes
     defined in this document. For example, it allows inetDnsDomain
     object class entries to be associated with IPv4 networks, or even
     to other DNS domains, if that information is known (this
     information may be useful if a single organization has multiple
     DNS domains registered). Furthermore, it allows inetOrgPerson
     object classes to be associated with managed resources such as IP
     networks or DNS domains. In short, any resource can be associated
     with any other resource through the use of this object class.
  
     The inetAssociatedResources object class MUST NOT be associated
     with an entry that only exists as a referral source.
  
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 47]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  5.6.1.  Naming syntax
  
     The inetAssociatedResources object class is an auxiliary object
     class, and not a structural object class. Entries which use this
     object class definition are primarily defined under the rules
     associated with the structural object class that defines the
     Internet resource in question. As such, the naming rules
     associated with the structural object class in use with that entry
     take precedence. Therefore, the inetAssociatedResources object
     class does not define a naming syntax.
  
  
  5.6.2.  Schema definition
  
     The inetAssociatedResources object class is an auxiliary object
     class which is subordinate to the top object class. The
     inetAssociatedResources object class has no mandatory attributes,
     although it does have several optional attributes.
  
     Although the inetAssociatedResources object class is subordinate
     to the top object class, it is intended to only be associated with
     the resource-specific structural object classes defined in this
     document. For example, the inetAssociatedResources object class is
     not likely to provide much value when it is associated with the
     inetResources object class, since the inetResources object class
     does not specifically define any resources (and since it does not
     define resources, it cannot define any associated resources). On
     the other hand, it is reasonable for the inetAssociatedResources
     object class to be associated with an inetOrgPerson object class
     entry, particularly if the referenced person (or role) is
     responsible for the management of multiple resources.
  
     Each of the associated resource attributes provide multi-valued
     data, using the syntax notations which are specific to the
     resource in question. For example, the inetAssociatedDnsDomain
     attribute provides associated DNS domain name resources using a
     multi-valued array, with each DNS domain name using the
     inetDnsDomainSyntax naming rules.
  
     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: August 2002             [page 48]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
     The schema definition for the inetAssociatedResources object class
     is as follows:
  
          inetAssociatedResources
          ( 1.3.6.1.4.1.7161.1.5.0 NAME 'inetAssociatedResources' DESC
            'Network resources associated with this entry.' SUP top
            AUXILIARY MAY ( inetAssociatedDnsDomains $
            inetAssociatedDnsDomainsModifiedBy $
            inetAssociatedDnsDomainsModifiedDate $
            inetAssociatedIpv4Networks $
            inetAssociatedIpv4NetworksModifiedBy $
            inetAssociatedIpv4NetworksModifiedDate $
            inetAssociatedIpv6Networks $
            inetAssociatedIpv6NetworksModifiedBy $
            inetAssociatedIpv6NetworksModifiedDate $
            inetAssociatedAsNumbers $
            inetAssociatedAsNumbersModifiedBy $
            inetAssociatedAsNumbersModifiedDate ) )
  
     The attributes from the inetAssociatedResources object class are
     described below:
  
          inetAssociatedAsNumbers
          ( 1.3.6.1.4.1.7161.1.5.2 NAME 'inetAssociatedAsNumbers' DESC
            'The autonomous system numbers associated with this entry.'
            EQUALITY caseIgnoreMatch SYNTAX inetAsNumberSyntax )
  
          inetAssociatedAsNumbersModifiedBy
          ( 1.3.6.1.4.1.7161.1.5.3 NAME
            'inetAssociatedAsNumbersModifiedBy' DESC 'Person who last
            modified the inetAssociatedAsNumbers attribute.' EQUALITY
            distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
            SINGLE-VALUE USAGE distributedOperation )
  
          inetAssociatedAsNumbersModifiedDate
          ( 1.3.6.1.4.1.7161.1.5.4 NAME
            'inetAssociatedAsNumbersModifiedBy' DESC 'Last modification
            date of the inetAssociatedAsNumbers 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: August 2002             [page 49]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
          inetAssociatedDnsDomains
          ( 1.3.6.1.4.1.7161.1.5.5 NAME 'inetAssociatedDnsDomains' DESC
            'The DNS domains associated with this entry.' EQUALITY
            caseIgnoreMatch SYNTAX inetDnsDomainSyntax )
  
          inetAssociatedDnsDomainsModifiedBy
          ( 1.3.6.1.4.1.7161.1.5.6 NAME
            'inetAssociatedDnsDomainsModifiedBy' DESC 'Person who last
            modified the inetAssociatedDnsDomains attribute.' EQUALITY
            distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
            SINGLE-VALUE USAGE distributedOperation )
  
          inetAssociatedDnsDomainsModifiedDate
          ( 1.3.6.1.4.1.7161.1.5.7 NAME
            'inetAssociatedDnsDomainsModifiedBy' DESC 'Last
            modification date of the inetAssociatedDnsDomains
            attribute.' EQUALITY generalizedTimeMatch ORDERING
            generalizedTimeOrderingMatch SYNTAX
            1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
            distributedOperation )
  
          inetAssociatedIpv4Networks
          ( 1.3.6.1.4.1.7161.1.5.8 NAME 'inetAssociatedIpv4Networks'
            DESC 'The IPv4 networks associated with this entry.'
            EQUALITY caseIgnoreMatch SYNTAX inetIpv4NetworkSyntax )
  
          inetAssociatedIpv4NetworksModifiedBy
          ( 1.3.6.1.4.1.7161.1.5.9 NAME
            'inetAssociatedIpv4NetworksModifiedBy' DESC 'Person who
            last modified the inetAssociatedIpv4Networks attribute.'
            EQUALITY distinguishedNameMatch SYNTAX
            1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
            distributedOperation )
  
          inetAssociatedIpv4NetworksModifiedDate
          ( 1.3.6.1.4.1.7161.1.5.10 NAME
            'inetAssociatedIpv4NetworksModifiedDate' DESC 'Last
            modification date of the inetAssociatedIpv4Networks
            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: August 2002             [page 50]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
          inetAssociatedIpv6Networks
          ( 1.3.6.1.4.1.7161.1.5.11 NAME 'inetAssociatedIpv6Networks'
            DESC 'The IPv6 networks associated with this entry.'
            EQUALITY caseIgnoreMatch SYNTAX inetIpv6NetworkSyntax )
  
          inetAssociatedIpv6NetworksModifiedBy
          ( 1.3.6.1.4.1.7161.1.5.12 NAME
            'inetAssociatedIpv6NetworksModifiedBy' DESC 'Person who
            last modified the inetAssociatedIpv6Networks attribute.'
            EQUALITY distinguishedNameMatch SYNTAX
            1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
            distributedOperation )
  
          inetAssociatedIpv6NetworksModifiedDate
          ( 1.3.6.1.4.1.7161.1.5.13 NAME
            'inetAssociatedIpv6NetworksModifiedDate' DESC 'Last
            modification date of the inetAssociatedIpv6Networks
            attribute.' EQUALITY generalizedTimeMatch ORDERING
            generalizedTimeOrderingMatch SYNTAX
            1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
            distributedOperation )
  
  
  5.6.3.  Example
  
     An example of the inetAssociatedResources object class is shown in
     Figure 8 below.
  
     Figure 8: The inetAssociatedResources attributes associated with
     the 192.0.2.0/24 IPv4 network entry.
  
       cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com
       [top object class]
       [inetResources object class]
       [inetIpv4Network object class]
       [inetAssociatedResources object class]
       |
       +-attribute: description
       | value: "The example.com network"
       |
       +-attribute: inetAssociatedAsNumbers
       | value: "65535"
       |
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 51]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
       +-attribute: inetAssociatedDnsDomains
         value: "example.com"
  
  
  5.7.    The inetOrgPerson Object Class
  
     This document provides several contact-related attributes which
     use LDAP URLs to reference 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, MUST refer to an entry in a DIT which
     uses the domainComponent object class syntax ("dc="), and MUST
     specify the LDAP or LDAPS protocol-types for the URL.
  
     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
     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.8.    The referral Object Class
  
     This document allows the use of the referral object class to
     define subordinate reference referrals and continuation reference
  
  
  Hall & Newton          I-D Expires: August 2002             [page 52]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     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.
  
     Furthermore, in order to facilitate programmatic access to this
     data, LDAP URLs provided in ref attributes MUST refer to entries
     which use the same object classes as the source entry, MUST refer
     to an entry in a DIT which uses the domainComponent object class
     syntax ("dc="), and MUST specify the LDAP or LDAPS protocol-types
     for the URL.
  
  
  5.9.    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-
            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
  
  
  Hall & Newton          I-D Expires: August 2002             [page 53]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
            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 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.
  
  
  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 are returned, the type of comparison operation
     that needs to be performed, and other details. In order to promote
     interoperability, default values are defined here for many of
     these elements, although these defaults are only applicable when
     they are used with the LDAP-WHOIS service.
  
     In particular, this document defines several suggested and
     mandatory search filter qualifiers, which are described in detail
  
  
  Hall & Newton          I-D Expires: August 2002             [page 54]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     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-
            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
  
  
  Hall & Newton          I-D Expires: August 2002             [page 55]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
            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 these clients MUST
            be prepared to issue the necessary subsequent queries.
  
        *   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),
  
  
  Hall & Newton          I-D Expires: August 2002             [page 56]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
            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 which are discussed below.
  
  
  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 )
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 57]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     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)".
  
     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 attribute
     values which are received MUST be displayed by the client. If a
     subordinate reference referral is received, 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
     of those queries to the original query's output.
  
  
  6.2.2.  inetIpv4NetworkMatch
  
     The inetIpv4NetworkMatch filter provides an identifier and search
     string format which collectively inform a queried server that a
  
  
  Hall & Newton          I-D Expires: August 2002             [page 58]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     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.
  
     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
  
  
  Hall & Newton          I-D Expires: August 2002             [page 59]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     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, 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
     of those queries to the original query's output.
  
  
  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.
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 60]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     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)".
  
     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, 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
     of those queries to the original query'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
  
  
  Hall & Newton          I-D Expires: August 2002             [page 61]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     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.
  
     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, 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 of those queries to the
     original query's output.
  
  
  7.      Query Processing Models
  
     The LDAP-WHOIS service uses three different query-processing
     models. These are the "top-down" model which initiates the query
     process at the top-level of a DNS delegation hierarchy, a "bottom-
  
  
  Hall & Newton          I-D Expires: August 2002             [page 62]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     up" model which directs queries to user-managed servers, and a
     "targeted" search model which is functionally identical to
     traditional LDAP searches. Furthermore, any of these mechanisms
     may be redirected to other servers, either through simple DNS
     query processing, or by way of LDAP redirections (including
     subordinate reference referrals, continuation reference referrals,
     attribute references, or labeledURI attributes).
  
     Each of the three 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.
     Clients MUST default to using the top-down model, but clients 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
     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 an input string to construct an LDAP
     assertion value and search base, with DNS queries being used to
     locate the LDAP servers associated with the appropriate top-level
     delegation entity. Once this process completes, an extensible
     match query is issued to the specified servers. The query may also
     be redirected through the use of LDAP referrals, if additional
     data is known to exist elsewhere.
  
     For example, a top-down search for the domain name of
     "www.example.com" would result in the client building an
  
  
  Hall & Newton          I-D Expires: August 2002             [page 63]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     inetDnsDomainMatch extensible match query with the search base of
     "cn=inetResources,dc=com", and with the client issuing a DNS query
     for the LDAP servers associated with "com" domain. If the queried
     server had information about the "www.example.com" resource, it
     would 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 and/or referrals, 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. One of the other search models
     MUST be used for those resource types.
  
  
  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 a DNS domain name of
                 "www.example.com", this would be "www", "example" and
                 "com". For the IPv4 network number of "192.0.2.14",
                 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
  
  
  Hall & Newton          I-D Expires: August 2002             [page 64]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
                 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.
  
        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".
  
  
  Hall & Newton          I-D Expires: August 2002             [page 65]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
            4.   Submit the search operation to the chosen server and
                 port number. 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.2. 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.2,
                 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 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
  
  
  Hall & Newton          I-D Expires: August 2002             [page 66]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
            assertion value of "www.example.com" and a search base of
            "cn=inetResources,dc=com".
  
        d.  The server responds with a continuation reference referral
            URL of "ldap://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, and is hosted at the "ldap.netsol.com" server. The
            client uses this information to start a new query. No
            additional data was provided for the client to display.
  
        e.  An inetDnsDomainMatch extensibleMatch search is submitted
            to "ldap.netsol.com", using the search base of
            "cn=example.com,cn=inetResources,dc=netsol,dc=com".
  
        f.  The queried server returns the information that it has. No
            additional referrals are provided. The client displays the
            data and exits the query.
  
  
   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 down through a
     delegation hierarchy would be either fruitless or inefficient. For
     example, information about 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 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.
  
     The bottom-up model uses an input string to construct an LDAP
     assertion value and search base, with DNS queries being used to
     locate the LDAP servers which are associated with the management
     entity that is directly responsible for the resource in question.
     Once this process completes, an extensible match query is issued
     to the specified servers. The query may also be redirected through
     the use of LDAP referrals, if additional data is known to exist
     elsewhere.
  
     For example, a bottom-up search for the domain name of
     "www.example.com" would result in the client building an
  
  
  Hall & Newton          I-D Expires: August 2002             [page 67]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     inetDnsDomainMatch extensible match query with the search base of
     "cn=inetResources,dc=www,dc=example,dc=com", and with the client
     issuing a DNS query for the LDAP servers associated with
     "www.example.com" domain. If the DNS lookup failed, the client
     would issue a subsequent query for the LDAP servers associated
     with the "example.com" domain, and so forth, until a server had
     been located. If the queried server had information about the
     "www.example.com" resource, it would 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 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.
  
     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. One of the other
     search models MUST be used for those resource types.
  
  
  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 a DNS domain name of
                 "www.example.com", this would be "www", "example" and
                 "com". For the IPv4 network number of "192.0.2.14",
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 68]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
                 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: August 2002             [page 69]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
                 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 to the chosen server and
                 port number. 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: August 2002             [page 70]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
                 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.2. 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.2,
                 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: August 2002             [page 71]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
        e.  The server returns a continuation reference referral of
            "ldap://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.  An inetDnsDomainMatch extensibleMatch search is submitted
            to the "ldap.example.net" server, using the search base of
            "cn=server1.example.net,cn=inetResources,dc=example,dc=net"
  
        g.  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: August 2002             [page 72]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  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 servers, search base
            and assertion value of the query.
  
        b.  If this process succeeds:
  
            1.   Construct the LDAP search filter according to the
                 rules specified in section 6.1, and choose the
                 appropriate matching rule from section 6.2.
  
            2.   Submit the search operation to the chosen server and
                 port number. If the operation fails, report the
                 failure to the user and exit. Otherwise, display any
                 answer data which is returned.
  
            3.   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.
  
        c.  If this process fails, report the failure to the user and
            exit the current search operation.
  
  
  7.3.2.  Targeted search example
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 73]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     In the example below, the user has provided an LDAP URL of
     "ldap://ldap.example.com/cn=admins,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 a DNS lookup of the
            specified server ("ldap.example.com").
  
        b.  The client contacts the servers, and issues a search for
            "(&(objectclass=inetOrgPerson)(cn:dn:=admins))", 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.
  
        *   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.
  
  
  Hall & Newton          I-D Expires: August 2002             [page 74]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
        *   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.
  
     Non-compliance with the requirements provided in section 4.5
     amounts to an error, and is sufficient cause for a client to stop
     processing a query.
  
  
  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 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 procedure for processing URLs returned in a subordinate
     reference referral is as follows:
  
  
  Hall & Newton          I-D Expires: August 2002             [page 75]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
        a.  RFC 2251 allows multiple URLs to be provided, although the
            URLs are not provided with any "preference" or "weighting"
            values. If a set of URLs are provided, only one of the URLs
            need to be tried (implementations MAY perform additional
            queries in an attempt to recover from temporary failures,
            although this is not required). Select one of the URLs at
            random ("round-robin"), and continue to the next step in
            the process.
  
        b.  Extract and discard any description text which may have
            been provided with the URL.
  
        c.  Validate the protocol label. This specification only
            supports the use of LDAP and LDAPS service types. URLs with
            other protocol identifiers are to be treated as malformed.
  
        d.  Extract the host identifier element and perform any DNS
            lookups which may be required. URLs without host
            identifiers are to be treated as malformed.
  
        e.  Extract the port number provided with the URL, and set it
            aside for use with the subsequent connection attempt. If no
            port number has been provided in the URL, use the default
            port numbers associated with the protocol, as discovered in
            step 7.4.2.c.
  
        f.  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.
  
        g.  Restart the current search operation, using the LDAP server
            from step 7.4.2.d, the port number from step 7.4.2.e, and
            the search base formed in step 7.4.2.f.
  
  
  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.
  
  
  Hall & Newton          I-D Expires: August 2002             [page 76]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
     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.
  
     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 URLs returned in a continuation
     reference referral is as follows:
  
        a.  RFC 2251 allows multiple URLs to be provided, although the
            URLs are not provided with any "preference" or "weighting"
            values. If a set of URLs are provided, only one of the URLs
            need to be tried (implementations MAY perform additional
            queries in an attempt to recover from temporary failures,
            although this is not required). Select one of the URLs at
            random ("round-robin"), and continue to the next step in
            the process.
  
        b.  Extract and discard any description text which may have
            been provided with the URL.
  
        c.  Validate the protocol label. This specification only
            supports the use of LDAP and LDAPS service types. URLs with
            other protocol identifiers are to be treated as malformed.
  
        d.  Extract the host identifier element and perform any DNS
            lookups which may be required. URLs without host
            identifiers are to be treated as malformed.
  
        e.  Extract the port number provided with the URL, and set it
            aside for use with the subsequent connection attempt. If no
            port number has been provided in the URL, use the default
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 77]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
            port numbers associated with the protocol, as discovered in
            step 7.4.3.c.
  
        f.  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.
  
        g.  Extract the left-most RDN from the search base constructed
            in step 7.4.3.e, and delete the naming attribute label. The
            resulting string will be used as the assertion value for
            the subsequent search operation. For example, if the path
            element from a URL 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 an assertion
            value of "example.com".
  
        h.  Start a new search operation, using the LDAP server from
            step 7.4.3.d, the port number from step 7.4.3.e, the search
            base formed in step 7.4.3.f, and the assertion value formed
            in step 7.4.3.g.
  
  
  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.
  
     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 procedure for processing the URLs returned in an attribute
     reference is as follows:
  
        a.  RFC 2251 allows multiple URLs to be provided, although the
            URLs are not provided with any "preference" or "weighting"
            values. If a set of URLs are provided, only one of the URLs
            need to be tried (implementations MAY perform additional
  
  
  Hall & Newton          I-D Expires: August 2002             [page 78]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
            queries in an attempt to recover from temporary failures,
            although this is not required). Select one of the URLs at
            random ("round-robin"), and continue to the next step in
            the process.
  
        b.  Extract and discard any description text which may have
            been provided with the URL.
  
        c.  Validate the protocol label. This specification only
            supports the use of LDAP and LDAPS service types. URLs with
            other protocol identifiers are to be treated as malformed.
  
        d.  Extract the host identifier element and perform any DNS
            lookups which may be required. URLs without host
            identifiers are to be treated as malformed.
  
        e.  Extract the port number provided with the URL, and set it
            aside for use with the subsequent connection attempt. If no
            port number has been provided in the URL, use the default
            port numbers associated with the protocol, as discovered in
            step 7.4.4.c.
  
        f.  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.
  
        g.  Extract the left-most RDN from the search base constructed
            in step 7.4.4.e, and delete the naming attribute label. The
            resulting string will be used as the assertion value for
            the subsequent search operation. For example, if the path
            element from a URL 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 an assertion
            value of "example.com".
  
        h.  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.
  
        i.  Start a new search operation, using the LDAP server from
            step 7.4.4.d, the port number from step 7.4.4.e, the search
            base formed in step 7.4.4.f, the assertion value formed in
            step 7.4.4.g, and the new object class filter formed in
            step 7.4.4.h.
  
  
  Hall & Newton          I-D Expires: August 2002             [page 79]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
  
  7.4.5.  SRV processing
  
     The query models described in this document make use of DNS SRV
     resource records whenever a new query process is started, as a way
     to locate the LDAP servers associated with a DIT.
  
     The procedure for constructing this SRV lookup is as follows:
  
        a.  Construct an SRV-specific label pair for the service type.
            For LDAP queries, this will be "_ldap._tcp", while LDAPS
            will use "_ldaps._tcp".
  
        b.  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".
  
        c.  Issue a DNS query for the SRV resource records associated
            with the domain name formed in step 7.4.5.b.
  
     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.
  
  
  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 internationalized attribute data,
     since the attribute types already provide direct support for
     internationalized data.
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 80]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     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.
  
     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 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.
  
     Similarly, any referrals which present URLs as answer data SHOULD
     provide multiple URLs, each of which reference different hosts on
     different networks. For leaf-node referrals, attribute references,
     and labeledURI references, this behavior MAY be relaxed, although
     it is still encouraged.
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 81]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     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 referral
     queries). 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.     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.
  
  
  10.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. Furthermore, given the limited global
     usability of NIC handles, they should be deprecated.
  
     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' WHOIS server can 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.
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 82]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  10.2.   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 as useful to external entities.
     Furthermore, the principle use of this information is for the
     purpose of internal audits, rather than external information.
     Finally, a subset of this kind of information is already provided
     in the *modified* operational attributes, which are always
     available for public review.
  
     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 public view of the
     data in the LDAP-WHOIS service. Where the auditing information
     will be required, a format which is more suitable to legal review
     will be required and more appropriate.
  
     For these reasons, this service is not supported 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).
  
  
  10.3.   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]
  
  
  Hall & Newton          I-D Expires: August 2002             [page 83]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
            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]     [ ]
            see http://www.ripe.net/ripe/docs/databaseref-manual.html
  
  
  11.     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.
  
     By nature, LDAP is a read-write protocol, while the legacy WHOIS
     service has always been a read-only service. As such, there are
     significant risks associated with allowing unintended updates by
     unauthorized third-parties. Moreover, allowing the LDAP-WHOIS
     service to update the underlying delegation databases could result
     in network resources being stolen from their lawful operators. For
     example, if the LDAP front-end had update access to a domain
     delegation database, a malicious third-party could theoretically
     take ownership of that domain by exploiting an authentication
     weakness, thereby causing ownership of the domain to be changed to
     another party. For this reason, it is imperative that the LDAP-
     WHOIS service not be allowed to make critical modifications to
     delegated resources without ensuring that all possible precautions
     have been taken.
  
     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.
  
     Some operators may choose to purposefully provide misleading or
     erroneous information in an effort to avoid responsibility for bad
     behavior. In addition, there are likely to be sporadic operator
     errors which will result in confusing or erroneous answers.
  
  
  Hall & Newton          I-D Expires: August 2002             [page 84]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
  
     This document provides multiple query models which will cause the
     same query to be answered by different servers (one would be
     processed by a delegation entity, while another would be processed
     by an operational entity). As a result, each of the servers may
     provide different information, depending upon the query type that
     was originally selected.
  
     For all of the reasons listed above, it is essential that
     applications and end-users not make critical decisions based on
     the information provided by the LDAP-WHOIS service without having
     reason to believe the veracity of the information. Users should
     limit 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.
  
  
  12.     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
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 85]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
     in the generic TLDs and the root domain, and also includes
     administering the referenced LDAP servers.
  
  
  13.     Author's Addresses
  
     Eric A. Hall
     ehall@ehsco.com
  
     Andrew Newton
     anewton@research.netsol.com
  
  
  14.     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
  
            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
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 86]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
            RFC 2849 - The LDAP Data Interchange Format (LDIF) -
            Technical Specification
  
            [namedref] - <draft-zeilenga-ldap-namedref-04.txt> - Named
            Subordinate References in LDAP Directories
  
            [ir-dir-req] - <draft-newton-ir-dir-requirements-00.txt> -
            Internet Registry Directory Requirements
  
     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.
  
  
  15.     Changes from Previous Versions
  
     The following changes were made to the -00 version:
  
        *   The ôObjectivesö section has been removed. [ir-dir-req] is
            now being used as the guiding document for this service.
  
        *   Several typographical errors have been fixed.
  
        *   Some unnecessary text has been removed.
  
        *   Figures changed to show complete sets of object classes, to
            improve inheritance visibility.
  
        *   Clarified the handling of reverse-lookup domains (zones
            within the in-addr.arpa portion of the DNS hierarchy) in
            the inetDnsDomain object class reference text.
  
        *   Referrals now use regular LDAP URLs (multiple responses
            with explicit hostnames and port numbers). Prior editions
            of this specification used LDAP SRV resource records for
            all referrals.
  
        *   The delegation status codes used by the
            inetDnsDelegationStatus, inetIpv4DelegationStatus,
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 87]


  Internet Draft       draft-hall-ldap-whois-01.doc       February 2002
  
  
            inetIpv6DelegationStatus and inetAsnDelegationStatus
            attributes have been condensed to a more logical set.
  
        *   Added an inetDnsAuthServers attribute for publishing the
            authoritative DNS servers associated with a domain. NOTE
            THAT THIS IS A TEMPORARY ATTRIBUTE THAT WILL EVENTUALLY BE
            REPLACED BY GENERALIZED RESOURCE-RECORD ENTRIES AND
            ATTRIBUTES.
  
        *   Added an inetGeneralDisclaimer attribute for publishing
            generalized disclaimers.
  
        *   Added the inetAssociatedResources auxiliary object class
            for defining associated resources, and moved some of the IP
            addressing and ASN attributes to the new object class.
  
        *   Several attributes had their OIDs changed. NOTE THAT THIS
            IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO
            ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 88]
  

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/