INTERNET-DRAFT                                             Eric A. Hall
  Document: draft-ietf-crisp-firs-core-02.txt                   July draft-ietf-crisp-firs-core-03.txt                 August 2003
  Expires: February, March, 2004
  Category: Standards-Track

                  The Federated Internet Registry Service:
                                Core Elements

     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.

     Copyright Notice

     Copyright (C) The Internet Society (2003).  All Rights Reserved.

     Abstract

     This document describes the core technical elements of the
     Federated Internet Registry Service (FIRS), a distributed service
     for storing, locating and transferring information about Internet
     resources using LDAPv3.

     Table of Contents

     1.   Introduction...............................................3
     2.   Prerequisites and Terminology..............................3
     3.   The FIRS Namespace.........................................3
       3.1.  The domainComponent (dc=) Namespace Component...........4
       3.2.  The inetResources Namespace Component...................4
       3.3.  The Resource-Specific Namespace Component...............4 Component...............5
       3.4.  Referrals...............................................5
           3.4.1.  Attribute References....................................5
       3.5.  Referrals...............................................6
           3.5.1.  Referral source entries...........................6
           3.5.2.  Referral target data..............................7
           3.5.3.  Subordinate reference referrals...................7
           3.4.2. referrals..................11
           3.5.4.  Continuation reference referrals..................8 referrals.................12
     4.   Global FIRS Object Classes and Attributes..................8 Attributes.................12
       4.1.  The inetResources Object Class..........................9 Class.........................13
           4.1.1.  Naming syntax.....................................9 syntax....................................13
           4.1.2.  Schema definition.................................9 definition................................13
           4.1.3.  Example..........................................12  Example..........................................16
       4.2.  The inetAssociatedResources Object Class...............13 Class...............17
           4.2.1.  Naming syntax....................................13 syntax....................................17
           4.2.2.  Schema definition................................13 definition................................17
           4.2.3.  Example..........................................15  Example..........................................19
       4.3.  The referral Object Class..............................15 Class..............................19
     5.   Global Query Processing Rules.............................16 Rules.............................20
       5.1.  Query Pre-Processing...................................17 Pre-Processing...................................21
       5.2.  Query Bootstrap Models.................................18 Models.................................22
           5.2.1.  Targeted query processing........................19 processing........................23
           5.2.2.  Top-down processing..............................20 processing..............................24
           5.2.3.  Bottom-up processing.............................23 processing.............................27
           5.2.4.  SRV processing...................................26 processing...................................30
       5.3.  Query Processing.......................................27 Processing.......................................31
           5.3.1.  The firsVersion inetResourcesControl server control...................27 control..........31
           5.3.2.  Matching filters.................................28 filters.................................34
           5.3.3.  Query-volume restrictions........................30 restrictions........................36
           5.3.4.  Authentication restrictions......................30 restrictions......................37
           5.3.5.  Extended attribute ACLs..........................37
           5.3.6.  Protocol and schema version controls.............31 controls.............39
       5.4.  Referral Processing....................................32 Processing....................................40
     6.   Security Considerations...................................36 Considerations...................................42
     7.   IANA Considerations.......................................36 Considerations.......................................42
     8.   Normative References......................................36 References......................................42
     9.   Changes from Previous Versions............................38 Versions............................44
     10.  Author's Address..........................................40 Address..........................................47
     11.  Acknowledgments...........................................41  Acknowledgments...........................................47
     12.  Full Copyright Statement..................................41 Statement..................................48

  Hall                   I-D Expires: February March 2004              [page 2] 
  1.      Introduction

     This specification defines the core object classes, attributes,
     syntax rules, matching filters, and operational behaviors for the
     FIRS service as a whole. Refer to [FIRS-ARCH] for information on
     the FIRS architecture, and the resource-specific specifications
     for definitions and rules which govern each of the different
     resource-types.

     The definitions in this specification are intended to be used with
     FIRS. Their usage outside of FIRS is not prohibited, but any such
     usage is beyond this specification's scope of authority.

  2.      Prerequisites and Terminology

     The complete set of specifications in the FIRS collection
     cumulative define a structured and distributed information service
     using LDAPv3 [RFC3377] for the data-formatting and transport
     functions. This specification should be read in the context of
     that set, which currently includes [FIRS-ARCH], [FIRS-DNS], [FIRS-
     DNSRR], [FIRS-CONTCT], [FIRS-ASN], [FIRS-IPV4] and [FIRS-IPV6].

     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.      The FIRS Namespace

     The FIRS namespace acts as an index to the federated partition
     structure of the globally-distributed database of FIRS servers. database. There are
     three major components to this namespace, which are:

        *   The domainComponent entries. Each partition of the globally
            distributed
            globally-distributed FIRS directory database is uniquely represented
            by a sequence of domainComponent relative distinguished
            names. These sequences effectively identify the root scope
            of authority for each partition in the global directory
            database. Partitions MAY be replicated across one or more
            servers, but every instance of a specific partition MUST
            use the same sequence of domainComponent relative
            distinguished names.

        *   An inetResources entry. All of the FIRS-related resource-
            specific entries in the global database are required to be
            stored within a well-known "cn=inetResources" container

  Hall                   I-D Expires: March 2004              [page 3] 
            entry at the root of each directory partition. These well-
            known well-known
            entries act as application-specific access points within
            the globally distributed directory database.

  Hall                  I-D Expires: February 2004             [page 3] database, and also
            provide some information about the partition and the
            organization which manages that partition.

        *   The resource-specific entries. Each of the resource-
            specific entries within the inetResources container entries
            have their own unique naming rules, as defined in the
            governing specifications for those resources.

     These

     Note that an inetResources container or any of the resource-
     specific entries MAY exist as referral stub entries that redirect
     clients to other entries in the FIRS database.

     The naming rules associated with the different portions of the
     FIRS namespace are discussed in more detail below.

  3.1.    The domainComponent (dc=) Namespace Component

     The global FIRS directory database is divided into administrative
     partitions, each of which represent a scope-of-authority for a
     certain portion of the global database. The root of each partition
     is represented by a sequence of domainComponent relative
     distinguished names (RDNs), as defined in RFC 2247 [RFC2247]. In
     this model, the scope-of-authority for a FIRS partition is derived
     from a domain name in the global DNS directory, meaning that
     whoever has authority over any particular domain name effectively
     has authority over the related FIRS partition.

     Note that the domainComponent attribute is restricted to seven-bit
     character codes, and is therefore effectively limited to using
     character codes from US-ASCII [US-ASCII]. Due to this limitation,
     internationalized domain names MUST be converted into their ASCII-
     compatible forms using the "ToASCII" process defined in RFC 3490
     [RFC3490] before the domainComponent RDNs are used in the
     directory database or LDAP messages.

  3.2.    The inetResources Namespace Component

     The FIRS-specific directory entries are segregated from other
     application-specific entries by the use of a container entry with
     the MANDATORY name of "cn=inetResources". Any entry which

     Every FIRS-specific resource that is to be located through via the FIRS
     service MUST refer to this be stored within the inetResources container entry.

     Note that this rule specifically applies to entries which are to
     be located by FIRS clients. The

  Hall                   I-D Expires: March 2004              [page 4] 
     However, the entries themselves MAY be exist as referrals which reference point
     to entries in other locations LDAP partitions or namespace branches if this
     is necessary or desirable (see section 3.4), although it is important
     for administrators to recognize that the referral targets will not
     be locatable through FIRS. 3.5).

  3.3.    The Resource-Specific Namespace Component

     Every resource-specific entry also has a RDN relative distinguished name
     which identifies that resource within the context of the
     inetResources container of any
     given a FIRS partition. Examples of these resource-specific
     entries can

  Hall                  I-D Expires: February 2004             [page 4] be seen in Figure 1 of [FIRS-ARCH], and include
     "cn=example.com" which refers to the "example.com" DNS domain name
     resource, and "cn=admins@example.com" which refers to the
     "admins@example.com" contact resource.

     Each of the FIRS resource-types have their own specific naming
     rules which govern those resources. Refer to the resource-specific
     specifications for information on those rules.

     Note that

  3.4.    Attribute References

     Many of the rules specifically apply to entries which are core attributes provide pointers to be
     located by FIRS clients. The entries themselves MAY be referrals
     which reference entries in other locations if this is necessary or
     desirable (see section 3.4), although it is important for
     administrators to recognize that resources,
     thereby allowing the referral targets will not be
     locatable through FIRS.

  3.4.    Referrals

     FIRS allows entries in the namespace to refer to other entries, as
     necessary or desirable. This model allows certain entries client to be
     created as "placeholders" initiate follow-up queries for other canonical entries which
     contain the actual
     related data.

     FIRS allows two methods for generating and processing these
     referrals: subordinate reference referrals, and continuation
     reference referrals.

     Subordinate reference referrals indicate that the search base in
     the original query is For example, an alias entry for some other entry, and that the
     query a domain name resource has to be restarted with
     attributes for a new search base in order variety of contacts for the
     search operation domain name, and FIRS
     clients are able to be processed. Meanwhile, continuation
     reference referrals indicate that the search was successfully
     initiated extract and use that some data has been found, but that to generate
     additional queries for additional any of those contact resources.

     Pointers to resources that are required stored within the global FIRS
     database are generally provided as the identifier for the query target
     resource, using the syntax rules associated with the resource in
     question. For example, a pointer to the contact entry of
     "admins@example.com" will be
     completely exhausted.

     Subordinate and continuation reference referrals use provided as that resource name, using
     the ref
     attribute and referral object class defined syntax rules associated with contact names. Examples of this
     usage form can be seen in RFC 3296 [RFC3296].
     Each Figure 1 of these mechanisms use [FIRS-ARCH].

     Note that traditional LDAP URLs as defined in RFC 2255
     [RFC2255] models often use URIs or distinguished
     names to carry referral data, with some additional FIRS-
     specific restrictions.

     Among provide fully-qualified pointers to entries, although
     these restrictions:

        *   Referral source entries MUST comply with all of the
            applicable namespace syntaxes usually require detailed knowledge about the target
     resources or the servers for the target partition. However, FIRS
     is much more distributed than traditional LDAP usages, and schema rules. may
     require pointing to data in an opaque partition, or where the
     topology of the target partition is unknown. For these reasons,
     attribute references in FIRS typically use the short name of the
     target resource, with the expectation that the client will use the
     attribute value as the query seed for new FIRS queries.

  Hall                   I-D Expires: February March 2004              [page 5] 
        *   Referral targets MUST use the domainComponent ("dc=")
            naming syntax for their directory partitions. Although
            other naming syntaxes are implicitly allowed by [RFC3296],
            those syntaxes are only guaranteed to be resolvable if they
            use domainComponent sequences.

        *   Referral targets are encouraged 
     However, pointers to reside in an
            inetResources container entry, although this resource data that is not
            required. For example, a general-purpose administrative
            contact entry may need to refer likely to be stored
     outside the global FIRS database (such as a user-specific contact
            entry in another container if this is necessary, and this
            kind of usage web page) is allowed.

        *   Referral sources and targets MUST have generally
     provided as a URI so that any necessary application and/or
     protocol transfer services can be specified. For example, the same resource-
            specific
     inetResources object class defined (for example, the referral
            source and target provides an attribute for a DNS domain resource would both have the inetDnsDomain object class defined). This is
     organization which manages the resource, with a
            prerequisite secondary
     attribute for a URL associated with the proper handling of the search filters target organization, thus
     allowing additional (extra-directory) information to be specified in
     and retrieved where this document.

        *   Referral targets MAY exist as referrals to other entries,
            but recursive referrals are discouraged. Clients MAY
            discontinue referral processing after would be useful.

     In those cases where a reasonable amount
            of effort (eight referrals is URI provides an LDAP URL that references a suggested default value).

        *   At least one of the URLs
     resource in a referral MUST specify the
            LDAP service type. Furthermore, global FIRS clients MUST disregard
            all directory, the URL data SHOULD use the
     referral URLs that do not specify URL rules described in section 3.5.

  3.5.    Referrals

     Entries in the LDAP service
            type. Although general-purpose LDAP referrals are allowed namespace can refer to use any kind of protocol, other entries, as necessary
     or desirable. Specifically, FIRS clients have a
            fundamental obligation allows certain entries to automatically process referrals, be
     created as "placeholders" for other entries which precludes contain the use of ambiguous services
     canonical data, and their
            data formats.

        * also allows "stub" child entries to provide
     reference pointers to additional data.

     LDAP URLs MAY specify host identifiers provides several methods for conveying and port numbers,
            but neither of processing these elements are required.

        *   If a matching filter and/or assertion value needs to be
            specified in a referral, they MUST be specified in the
            filter element
     kinds of referrals, although FIRS only makes specific use of
     subordinate reference referrals and continuation reference
     referrals. Subordinate reference referrals indicate that the referral's LDAP URL. Matching filters
            and/or assertion values MUST NOT be specified unless
     search base in the
            referral source needs original query is an alias for some other
     entry, and that the query has to explicitly reference be restarted with a specific
            target entry new search
     base in a specific partition. This should only order for the search operation to be
            necessary in those cases where processed. Meanwhile,
     continuation reference referrals indicate that the referral target entry

  Hall                  I-D search was
     successfully initiated and that some data has been found, but that
     additional queries for additional resources are required for the
     query to be completely exhausted.

  3.5.1.  Referral source entries

     Referral entries can be used in FIRS in two distinct scenarios,
     with each scenario having different naming requirements for the
     referral sources.

     In the first instance, specific entries can be defined as
     referrals so that queries for the entry always generate a single
     referral. This may be necessary when an entire inetResources
     container entry needs to be redirected to another inetResources
     container entry in another tree, but can also be useful when
     entries only exist as placeholders for other entries.

  Hall                   I-D Expires: February March 2004              [page 6] 
            would not normally be located (most likely due 
     For example, a registrar can create referral entries for variant
     domain names whenever a canonical domain name is registered, with
     the variant entries only providing referrals to the canonical
     entry. Similarly, an entry for the host named "www.example.com"
     could exist as a
            radically different referral which pointed to the domain name entry name).

        *   The attribute, scope
     for "www-1.example.net". In these scenarios, users who generate
     queries for the alias domain name entries would always get
     referred to the canonical domain name entries.

     Most entries are expected to provide some kind of information, and extension elements
     in this kind of LDAP URLs situation, the canonical entry will have data, but
     will need to be ignored by able to generate referrals to one or more other
     entries where additional data about the client, and SHOULD NOT resource can be provided.

        *   LDAP URLs MUST use a URL-safe format. retrieved.
     For example, the IPv4
            and IPv6 network address syntaxes defined entries in this document
            make use of the forward-slash ("/") character to indicate partition for the "com" domain
     registry can provide basic information about a
            subnet prefix, and if this character needs to be provided
            in domain, but can
     also provide a URL, it must be provided in referral to the escaped form ("%2F" in
            this example). Similarly, some domain names and email
            addresses contain UTF-8 character data, and some of those
            character codes will need to be escaped in order registrar, while the
     registrar can provide another referral to be
            passed as URL data.

        *   Providers MUST NOT restrict values the domain operator.

     In these cases, each partition would need to verifiable entries
            from local partitions. Providers MAY validate have an entry for the referral
            targets
     resource in URLs, but a lack question, while child entries underneath each of knowledge regarding a target
            MUST NOT those
     entries would be treated as sufficient cause used to prevent generate the
            referral target from being specified.

     The rules for processing referral URLs are given in section 5.4.

     Note that necessary referrals. For
     example, the "superior reference referral" defined in RFC 2251
     [RFC2251] used "example.com" domain would likely exist as a "default referral" for out-of-scope searches
     is explicitly unsupported in FIRS; any superior reference
     referrals which are encountered as
     canonical entry within a part of this service are to
     be treated as errors.

     Each of registry's partition, with that entry
     providing information that the supported referral mechanisms are discussed in more
     detail below.

  3.4.1.  Subordinate reference referrals

     Subordinate reference referrals are defined in [RFC3296], and are
     returned whenever registry had about that domain
     name. Meanwhile, the search base specified in registry could have a query exists as child entry underneath
     the canonical entry which provided a referral to some other entry. This means that the query MUST be
     restarted, using the registrar's
     partition, and so forth.

     The relative distinguished name of a referral target as the new search base.

     Any entries MAY child entry is
     usually irrelevant, and can therefore be defined as subordinate reference referrals
     which point according to other entries.
     local policy rather than fixed rules. However, almost all of the search
     functions defined for use by this service operators SHOULD
     NOT use names that are likely to match against searches for other
     resources. In the inetResources
     container entry general case, using generalized relative
     distinguished names such as "cn=ref1" or the search base (the exceptions like would be the
     safest practice.

  3.5.2.  Referral target data

     Referral entries MUST use the ref attribute and referral object
     class, as defined in RFC 3296 [RFC3296].

     The referral target is provided to this rule the client with the ref
     attribute, which provides a URI as the destination pointer,
     although there are targeted searches for explicit entries), so subordinate
     reference referrals will most commonly be seen when an some additional FIRS-specific restrictions
     which are as follows:

  Hall                   I-D Expires: February March 2004              [page 7] 
     inetResources container entry has been redirected to an
     inetResources container 
        *   At least one of the URLs in another directory partition.

     Servers a referral MUST support the use of subordinate reference referrals
     for this purpose, be an LDAP URL
            as specified in RFC 2255 [RFC2255], and FIRS clients MUST be prepared to accept and
     process any subordinate reference referrals in answer sets.

     When subordinate reference
            ignore all non-LDAP URIs. Note that general-purpose LDAP
            referrals are used for allowed to use any protocol, but FIRS clients
            have a requirement to automatically process referrals, and
            this purpose, requirement precludes the use of ambiguous services
            and their data formats. As such, every FIRS referral source MUST be defined with the referral object
     class,
            specify at least one LDAP URL, and FIRS clients MUST also be defined with only
            use the appropriate object class LDAP URLs.

        *   Referral targets MUST use domainComponent ("dc=") naming
            syntax for that resource type. For example, a "cn=inetResources" entry
     which provided target partitions. If a subordinate reference referral would need needs to have
     both
            specify an exact partition or container for the referral and inetResources object classes defined, while
     a DNS domain resource such as "dc=example.com" would need
            target, the path to have
     both the referral and inetDnsDomain object classes defined (among target MUST be provided as
            the other object class definitions which were required for that
     entry). Referral targets need to use whatever object classes are
     appropriate for search base of the resource in question, LDAP URLs, and MAY also this data MUST be
     referrals to other entries.

  3.4.2.  Continuation reference referrals

     Continuation reference referrals are defined in RFC 2251
     [RFC2251], and are returned
            used by FIRS clients when a search operation has been
     successfully processed but the answer data also includes referrals
     to other entries. These referrals are often provided as
     supplemental subsequent query is built.

        *   The LDAP URL data MUST be escaped prior to an answer set, although this is not required
     (a continuation reference referral being sent. For
            example, domain names and contact names can contain UTF-8
            character data, and some of those character codes will need
            to be the only response, but
     it won't escaped in order to be passed as URL data. Similarly,
            the only response IPv4 and IPv6 network address syntaxes defined in the common case).

     Servers MUST support the this
            document make use of continuation reference referrals
     for this purpose, and clients MUST be prepared the forward-slash ("/") character to accept
            indicate a subnet prefix, and
     process any subordinate reference referrals in answer sets.

     When continuation reference referrals are used for if this purpose,
     entries MAY exist for character needs to be
            provided in a URL, it must be provided in the queried resource, but one or more
     entries MUST exist with escaped form
            ("%2F" in this example).

     In the referral object class defined, and
     which general sense, referrals SHOULD NOT provide LDAP URLs that point to other entries which have
     additional any more
     information about the referral target than absolutely necessary.
     For example, if a referral source for a domain name resource in question.

  4.      Global FIRS Object Classes needs
     to reference a referral target for another domain name resource,
     then only the resource type and Attributes

     Each of identifier SHOULD be provided
     (this will give the schema definitions client enough information to begin a new
     query), while data such as the target partition or LDAP server
     SHOULD NOT be provided in since the authoritative forms of this document include
     attribute definitions, naming rules,
     information will be detected as part of the subsequent query's
     bootstrapping process. With this in mind, the following
     recommendations apply to referral targets in the general sense,
     and other definitions which
     are designed SHOULD be followed:

        *   In those cases where a referral points to facilitate a FIRS resource
            of a known type and name (E.G., a domain name, or an IPv4
            address), the consistent storage referral URL MUST specify the matching filter
            and retrieval assertion value of
     information within the FIRS service. referral target. For example, a
            referral that points to a DNS domain resource MUST provide

  Hall                   I-D Expires: February March 2004              [page 8] 
  4.1.    The inetResources Object Class

     The inetResources object class is a structural object class which
     defines 
            the attributes associated with inetDnsDomainMatch matching filter and value in the "cn=inetResources"
     container entry, and which provides general information about
            filter element of the
     network resources associated with LDAP URL (such as providing
            "(1.3.6.1.4.1.7161.1.3.0.1:=example.com)" for a referral to
            the current directory partition.

  4.1.1.  Naming syntax

     This document requires "example.com" DNS domain). Clients MUST use this data
            to seed the presence resource type and assertion value of the
            subsequent query if it is provided.

        *   In those cases where a referral points to a FIRS resource
            in a particular partition, the referral URL MUST specify
            the search base element. For example, if an entry named
     "cn=inetResources" for the
            "example.com" domain name resource in the root of every directory partition which
     provides FIRS services.

  4.1.2.  Schema definition

     Every directory "com" partition which provides public FIRS data
            needs to specify the "example.com" domain name resource in
            the "registrar.com" partition, then the referral MUST
     have a "cn=inetResources" entry
            specify "dc=registrar,dc=com" in the root search base element of
            the directory
     partition. The inetResources entry LDAP URL. Clients MUST exist with use this data to seed the top and
     inetResources object classes defined. If boot
            partition of the entry exists as subsequent query if it is provided.

        *   In those cases where a referral source, the entry MUST also be defined with points to some other kind
            of entry, the referral
     object class, in addition target SHOULD specify as little
            information as possible, while still providing an adequate
            reference. For example, if a referral needs to point to the above requirements.

     The inetResources object class is a structural object class which
     is subordinate
            contact in an alternate container of a specific partition,
            the full path to the top abstract class, and which MUST referral target SHOULD be
     treated as a container class capable specified in
            the search base element of holding the URL. Clients MUST use the
            additional
     subordinate entries. The inetResources object class has one
     mandatory attribute which information if it is "cn" (the naming attribute), provided.

        *   In the general case, referral sources and also
     has several optional attributes. Each of targets SHOULD
            have the other same resource-specific object classes
     defined defined,
            although referral targets MAY specify other resource types
            if needed. For example, the referral source and target for use with FIRS are subordinate to
            a DNS domain resource should both have the inetResources inetDnsDomain
            object class defined, although a referral may point to an
            IPv4 host address if this is necessary. If a referral
            target is known to have a different object class than the
            referral source, a matching filter for the referral target
            MUST be provided in the filter element of the LDAP URLs,
            and inherit its attributes. this data MUST be used by FIRS clients when the
            subsequent query is built.

        *   LDAP URLs SHOULD NOT provide host identifiers or port
            numbers unless this is absolutely necessary, since the
            client will usually discover this information during the
            bootstrap process. If a referral provides this information,
            it MUST be used by FIRS clients when the subsequent query
            is built.

  Hall                   I-D Expires: February March 2004              [page 9] 
     The schema definition for the inetResources object class is as
     follows:

          inetResources
          ( 1.3.6.1.4.1.7161.1.1.1
            NAME 'inetResources'
            DESC 'The inetResources container for the 
        *   Attribute lists, scope filters, and URL extensions SHOULD
            NOT be provided, and these elements MUST be ignored by FIRS service'
            SUP top
            STRUCTURAL
            clients unless an applicable specification details explicit
            behavior for these elements.

        *   The operators of a partition MUST cn NOT restrict referral
            data to verifiable referral targets. Providers MAY validate
            the referral targets in URLs, but a lack of knowledge
            regarding a target MUST NOT be treated as sufficient cause
            to prevent the referral target from being specified.

        *   Referral targets MAY themselves be referrals to other
            entries, but recursive referrals are discouraged. Clients
            MAY discontinue referral processing after a reasonable
            amount of effort (eight referrals is a reasonable
            threshold, but the actual amount of processing is left to
            the discretion of the clients).

     An example referral is illustrated in Figure 1 of [FIRS-ARCH]. In
     that example, the referral data provides an inetDnsDomainMatch
     matching filter with the explicit assertion value of
     "www-1.example.net". This data would inform the client of the
     resource-type to be queried and the assertion value to use, which
     collectively would give the client everything needed to begin
     bootstrapping a new query.

     As another example, a referral to a specific entry could look like
     the following:

          ldap://cn=admins@example.com,cn=inetResources,
                dc=example,dc=com

     In that example, the referral is pointing to an explicit entry in
     an explicit container in an explicit partition. Although the
     client would not be able to tell what kind of resource was being
     queried for, it would be able to determine the resource-type once
     an answer was received, based on the object class values of
     resulting entry.

     The client-side rules for processing referral URLs are given in
     section 5.4.

     Note that the "superior reference referral" defined in RFC 2251
     [RFC2251] used as a "default referral" for out-of-scope searches
     is explicitly unsupported in FIRS. Superior reference referrals

  Hall                   I-D Expires: March 2004             [page 10] 
     which are encountered as a part of this service are to be treated
     as errors and silently ignored.

  3.5.3.  Subordinate reference referrals

     Subordinate reference referrals are defined in [RFC3296], and are
     returned whenever the search base specified in a query exists as a
     referral to some other entry. This means that the query MUST be
     restarted with the referral target.

     Specifically, subordinate reference referrals are defined in
     [RFC3296], and use the SearchResultDone response with a Referral
     result code as defined in [RFC2251]. Subordinate reference
     referrals use a subset of the labeledURI syntax as defined in
     [RFC2079], and use the syntax definitions from [RFC2255] when LDAP
     URLs in particular are provided, although section 3.5.2 of this
     document also defines additional restrictions on the allowable URL
     syntax. 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
     partition has been redirected to another directory partition.

     Almost all of the search functions used with FIRS 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 directory partition.

     Servers MUST support the use of subordinate reference referrals,
     and clients MUST be prepared to accept and process any subordinate
     reference referrals they receive.

     When subordinate reference referrals are used, 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.

  Hall                   I-D Expires: March 2004             [page 11] 
  3.5.4.  Continuation reference referrals

     Continuation reference referrals are defined in RFC 2251
     [RFC2251], and are returned when a search operation has been
     successfully processed but the answer data also includes referrals
     to other entries. These referrals are usually provided as
     supplemental data to an answer, although it's also possible for a
     continuation reference referral to be the only data in an answer.

     Specifically, continuation reference referrals use the
     SearchResultReference response, which is defined and described in
     section 4.5.3 of [RFC2251]. Continuation reference referrals use a
     subset of the labeledURI syntax as defined in [RFC2079], and use
     the syntax definitions from [RFC2255] when LDAP URLs in particular
     are to be provided, although section 3.5.2 of this document also
     defines additional restrictions on the allowable URL syntax. 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 directory partition, and
     can occur with any of the search operations described in this
     document.

     Servers MUST support the use of continuation reference referrals,
     and clients MUST be prepared to accept and process any subordinate
     reference referrals that they receive.

     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.

  4.      Global FIRS Object Classes and Attributes

     Each of the schema definitions provided in this document include
     attribute definitions, naming rules, and other definitions which
     are designed to facilitate the consistent storage and retrieval of
     information within the FIRS service.

  Hall                   I-D Expires: March 2004             [page 12] 
  4.1.    The inetResources Object Class

     The inetResources object class is a structural object class which
     defines the attributes associated with the "cn=inetResources"
     container entry, and which provides general information about the
     network resources associated with the current directory partition.

  4.1.1.  Naming syntax

     This document requires the presence of an entry named
     "cn=inetResources" in the root of every directory partition which
     provides FIRS services.

  4.1.2.  Schema definition

     Every directory partition which provides public FIRS data MUST
     have a "cn=inetResources" entry in the root of the directory
     partition. The inetResources entry MUST exist with the top and
     inetResources object classes defined. If the entry exists as a
     referral source, 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 for use with FIRS are subordinate to the inetResources
     object class and inherit its attributes.

  Hall                   I-D Expires: March 2004             [page 13] 
     The schema definition for the inetResources object class is as
     follows:

          inetResources
          ( inetPrivateIdentifier 1.3.6.1.4.1.7161.1.1.1
            NAME 'inetResources'
            DESC 'The inetResources container for the FIRS service'
            SUP top
            STRUCTURAL
            MUST cn
            MAY ( inetLocalIdentifier $ o $ ou $ description $
            inetResourceComments $ businessCategory $ telephoneNumber $
            facsimileTelephoneNumber $ labeledURI $
            preferredDeliveryMethod $ physicalDeliveryOfficeName $
            postOfficeBox $ postalAddress $ postalCode $ street $ l $
            st $ c $ inetAbuseContacts $ inetGeneralContacts $ $ inetGeneralContacts $
            inetSecurityContacts $ inetTechContacts $
            inetGeneralDisclaimer ) )

     The attributes from the inetResources object class are described
     below:

          businessCategory, see RFC 2256 [RFC2256], section 5.16

          c (country), see [RFC2256], section 5.7

          cn (commonName), see [RFC2256], section 5.4

          description, see [RFC2256], section 5.14

          facsimileTelephoneNumber, see [RFC2256], section 5.24

          l (locality), see [RFC2256], section 5.8

          labeledURI, see RFC 2079 [RFC2079]

          o (organization), see [RFC2256], section 5.11

          ou (organizational unit), see [RFC2256], section 5.12

          physicalDeliveryOfficeName, see [RFC2256], section 5.20

          postalAddress, see [RFC2256], section 5.17

  Hall                   I-D Expires: March 2004             [page 14] 
          postalCode, see [RFC2256], section 5.18

          postOfficeBox, see [RFC2256], section 5.19

          preferredDeliveryMethod, see [RFC2256], section 5.29

          st (stateOrProvinceName), see [RFC2256], section 5.9

          street (streetAddress), see [RFC2256], section 5.10

          telephoneNumber, see [RFC2256], section 5.21

          inetLocalIdentifier
          ( 1.3.6.1.4.1.7161.1.1.2
            NAME 'inetLocalIdentifier'
            DESC 'Provider name for this entry'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )

          inetResourceComments
          ( 1.3.6.1.4.1.7161.1.1.3
            NAME 'inetResourceComments'
            DESC 'General comments about this entry'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )

          inetGeneralDisclaimer
          ( 1.3.6.1.4.1.7161.1.1.4
            NAME 'inetGeneralDisclaimer'
            DESC 'General disclaimer text regarding this data'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )

          inetGeneralContacts
          ( 1.3.6.1.4.1.7161.1.1.5
            NAME 'inetGeneralContacts'
            DESC 'Contacts for general administrative issues.'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.7161.1.7.1 )

  Hall                   I-D Expires: March 2004             [page 15] 
          inetAbuseContacts
          ( 1.3.6.1.4.1.7161.1.1.6
            NAME 'inetAbuseContacts'
            DESC 'Contacts for reporting abusive behavior or
            acceptable-use policy violations.'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.7161.1.7.1 )

          inetSecurityContacts $ inetTechContacts $
            inetGeneralDisclaimer
          ( 1.3.6.1.4.1.7161.1.1.7
            NAME 'inetSecurityContacts'
            DESC 'Contacts for general security issues.'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.7161.1.7.1 )

          inetTechContacts
          ( 1.3.6.1.4.1.7161.1.1.8
            NAME 'inetTechContacts'
            DESC 'Contacts for general technical issues.'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.7161.1.7.1 )

  4.1.3.  Example

     An example of the inetResources object class in use is shown in
     Figure 1 below.

          cn=inetResources,dc=example,dc=com
          [top object class]
          [inetResources object class]
          |
          +-attribute: o
          | value: "Example Widgets' network resources"
          |
          +-attribute: inetGeneralContacts
          | value: "admins@example.com"
          |
          +-attribute: telephoneNumber
          | value: "1-800-555-1212"
          |
          +-attribute: inetResourceComments
            value: "Please don't send complaints to the
                    postmaster@example.com mailbox."

     Figure 1: The Example Widgets inetResources container entry.

  Hall                   I-D Expires: March 2004             [page 16] 
  4.2.    The inetAssociatedResources Object Class

     The inetAssociatedResources object class defines attributes which
     are useful for cross-referencing entries with other resources. For
     example, it allows inetOrgPerson entries to be associated with
     IPv4 networks or DNS domains, providing generic cross-reference
     pointer attributes (this information may be useful if a single
     organization has multiple DNS domains registered). In short, any
     resource can be associated with any other resource through the use
     of this object class.

  4.2.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 defined under the rules associated
     with the structural object class that defines the Internet
     resource in question. As such, the naming rules associated with
     that entry take precedence, and the inetAssociatedResources object
     class does not define an independent naming syntax.

  4.2.2.  Schema definition

     The attributes from inetAssociatedResources object class is an auxiliary object
     class which is subordinate to the top object class. The
     inetAssociatedResources object class has no mandatory attributes,
     and only has optional attributes.

     The inetAssociatedResources is intended to be used with the
     resource-specific structural object classes defined for use with
     FIRS. 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.

     The inetAssociatedResources object class MUST NOT be associated
     with an entry that only exists as a referral source.

     Each of the associated resource attributes provide multi-valued
     data, using the syntax notations which are described
     below:

          businessCategory, see RFC 2256 [RFC2256], section 5.16

          c (country), see [RFC2256], section 5.7

          cn (commonName), see [RFC2256], section 5.4

          description, see [RFC2256], section 5.14

          facsimileTelephoneNumber, see [RFC2256], section 5.24

          l (locality), see [RFC2256], section 5.8

          labeledURI, see RFC 2079 [RFC2079]

          o (organization), see [RFC2256], section 5.11

          ou (organizational unit), see [RFC2256], section 5.12

          physicalDeliveryOfficeName, see [RFC2256], section 5.20

          postalAddress, see [RFC2256], section 5.17 specific to the
     resource in question. For example, the inetAssociatedDnsDomain

  Hall                   I-D Expires: February March 2004             [page 10] 
          postalCode, see [RFC2256], section 5.18

          postOfficeBox, see [RFC2256], section 5.19

          preferredDeliveryMethod, see [RFC2256], section 5.29

          st (stateOrProvinceName), see [RFC2256], section 5.9

          street (streetAddress), see [RFC2256], section 5.10

          telephoneNumber, see [RFC2256], section 5.21

          inetPrivateIdentifier 17] 
     attribute provides multiple associated DNS domain name resources
     using a multi-valued array, with each domain name using the
     inetDnsDomainSyntax naming rules defined in [FIRS-DNS].

     The schema definition for the inetAssociatedResources object class
     is as follows:

          inetAssociatedResources
          ( 1.3.6.1.4.1.7161.1.1.2 1.3.6.1.4.1.7161.1.2.1
            NAME 'inetPrivateIdentifier' 'inetAssociatedResources'
            DESC 'Operator-specific identification tag for 'Internet resources associated with this entry'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} resource.'
            SUP top
            AUXILIARY
            MAY ( inetAssociatedContacts $ inetAssociatedDnsDomains $
             inetAssociatedIpv4Networks $ inetAssociatedIpv6Networks $
             inetAssociatedAsNumbers )

          inetResourceComments )

     The attributes from the inetAssociatedResources object class are
     described below:

          inetAssociatedAsNumbers
          ( 1.3.6.1.4.1.7161.1.1.3 1.3.6.1.4.1.7161.1.2.2
            NAME 'inetResourceComments' 'inetAssociatedAsNumbers'
            DESC 'General comments about 'Autonomous system numbers associated with this entry'
            Internet resource.'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} 1.3.6.1.4.1.7161.1.7.0 )

          inetGeneralDisclaimer

          inetAssociatedContacts
          ( 1.3.6.1.4.1.7161.1.1.4 1.3.6.1.4.1.7161.1.2.3
            NAME 'inetGeneralDisclaimer' 'inetAssociatedContacts'
            DESC 'General disclaimer text regarding 'Other contacts associated with this data' Internet
            resource.'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} 1.3.6.1.4.1.7161.1.4.0 )

          inetGeneralContacts

          inetAssociatedDnsDomains
          ( 1.3.6.1.4.1.7161.1.1.5 1.3.6.1.4.1.7161.1.2.4
            NAME 'inetGeneralContacts' 'inetAssociatedDnsDomains'
            DESC 'Contacts for general administrative issues.' 'DNS domains associated with this Internet resource.'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.7161.1.7.1 1.3.6.1.4.1.7161.1.3.0 )

  Hall                   I-D Expires: February March 2004             [page 11] 
          inetAbuseContacts
          ( 1.3.6.1.4.1.7161.1.1.6
            NAME 'inetAbuseContacts'
            DESC 'Contacts for reporting abusive behavior or
            acceptable-use policy violations.'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.7161.1.7.1 )

          inetSecurityContacts 18] 
          inetAssociatedIpv4Networks
          ( 1.3.6.1.4.1.7161.1.1.7 1.3.6.1.4.1.7161.1.2.5
            NAME 'inetSecurityContacts' 'inetAssociatedIpv4Networks'
            DESC 'Contacts for general security issues.' 'IPv4 networks associated with this Internet
            resource.'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.7161.1.7.1 1.3.6.1.4.1.7161.1.5.0 )

          inetTechContacts

          inetAssociatedIpv6Networks
          ( 1.3.6.1.4.1.7161.1.1.8 1.3.6.1.4.1.7161.1.2.6
            NAME 'inetTechContacts' 'inetAssociatedIpv6Networks'
            DESC 'Contacts for general technical issues.' 'IPv6 networks associated with this entry.'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.7161.1.7.1 1.3.6.1.4.1.7161.1.6.0 )

  4.1.3.

  4.2.3.  Example

     An example of the inetResources inetAssociatedResources object class in use is shown in
     Figure 1 2 below.

          cn=inetResources,dc=example,dc=com

          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: o
          | value: "Example Widgets' network resources"
          |
          +-attribute: inetGeneralContacts description
          | value: "admins@example.com" "The Example Widgets network"
          |
          +-attribute: telephoneNumber inetAssociatedAsNumbers
          | value: "1-800-555-1212" "65535"
          |
          +-attribute: inetResourceComments inetAssociatedDnsDomains
            value: "Please don't send complaints to the
                    postmaster@example.com mailbox." "2.0.192.in-addr.arpa"

     Figure 1: 2: The Example Widgets inetResources container inetAssociatedResources attributes associated with
     the 192.0.2.0/24 IPv4 network entry.

  Hall                  I-D Expires: February 2004            [page 12] 
  4.2.

  4.3.    The inetAssociatedResources referral Object Class

     The inetAssociatedResources

     Entries use the referral object class defines attributes which
     are useful for cross-referencing entries with other resources. For
     example, it allows inetOrgPerson to define subordinate
     reference referrals and continuation reference referrals, thereby
     facilitating the programmatic redirection of queries in support of
     the referral mechanisms defined in section 3.5.

  Hall                   I-D Expires: March 2004             [page 19] 
     Referral entries MUST conform to be associated with
     IPv4 networks or DNS domains, providing generic cross-reference
     pointer the schema specification defined
     in [RFC3296].

     Referral sources MUST NOT contain any user-definable attributes (this
     (other than the mandatory naming attribute), and MUST NOT have any
     subordinate child entries.

     Refer to section 3.5 for the rules that govern referral URLs in
     FIRS. Refer to section 5.4 for information may be useful if on processing referral
     URLs in FIRS.

  5.      Global Query Processing Rules

     Another critical aspect to FIRS is the query-processing behavior.
     These rules govern the ways in which a single
     organization has multiple DNS domains registered). In short, client parses a query,
     locates a server which is authoritative for the resource being
     queried, generates LDAPv3 queries, and processes any resulting
     referrals. More specifically:

        *   Query pre-processing. The first step is for the client to
            prepare the query. Portions of this process require the
            client to determine the type of resource can being queried for,
            and to determine the initial partition which should be associated with any other resource through used
            for the use
     of query. Since this object class.

  4.2.1.  Naming syntax

     The inetAssociatedResources object class process is an auxiliary object
     class, and not a structural object class. Entries different for each
            particular resource-type, the rules which use govern this
     object class definition
            behavior are defined under in each of the rules associated
     with resource-specific
            specifications.

        *   Bootstrap processing. Once a partition has been determined,
            the structural object class that defines client must locate the LDAP servers which are
            authoritative for the Internet resource in question. As such, the naming rules associated with Section 5.2
            defines three different bootstrap models that entry take precedence, and clients can
            use as part of this process, while each of the inetAssociatedResources object
     class does not resource-
            specific specifications define an independent naming syntax.

  4.2.2.  Schema definition

     The inetAssociatedResources object class is an auxiliary object
     class which is subordinate to of the top object class. The
     inetAssociatedResources object class has no mandatory attributes,
     and only has optional attributes.

     The inetAssociatedResources is intended models are to
            be used with the
     resource-specific structural object classes defined for use with
     FIRS. 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 each particular resource-type.

        *   Query processing. Once a server has been located, the
     other hand, it is reasonable for
            client must submit the inetAssociatedResources
     object class to be associated with an inetOrgPerson object class
     entry, particularly if LDAP query which was formed during
            the referenced person (or role) is
     responsible pre-preprocessing phase. Section 5.3 defines the global
            considerations for all FIRS queries, while the management resource-
            specific specifications also define additional parameters.

        *   Query post-processing. FIRS explicitly supports different
            types of multiple resources.

     The inetAssociatedResources object class MUST NOT be associated
     with an entry that only exists as a LDAP referral source.

     Each mechanisms, any of the associated resource attributes provide multi-valued
     data, using the syntax notations which are specific to the
     resource may result
            in question. For example, the inetAssociatedDnsDomain client application restarting the query or

  Hall                   I-D Expires: February March 2004             [page 13] 
     attribute provides multiple associated DNS 20] 
            initiating a brand-new query. These mechanisms and their
            behavioral rules are defined in section 5.4.

     Each of these phases are discussed in more detail below.

  5.1.    Query Pre-Processing

     Client input is generally limited to a single well-formed unit of
     data, such as a domain name resources
     using ("example.com") or an email address
     ("admins@example.com"), and this single piece of information must
     be used to subsequently build a multi-valued array, with fully-formed LDAPv3 query,
     including the assertion value, the search base, the matching
     filter, and so forth. All of these steps are part of the pre-
     processing phase.

     Although the exact sequence of steps will vary according to the
     resource-type being queried, there are some commonalities between
     each domain name using of them. Among these steps:

        *   Determine the resource type. Different kinds of resources
            have different processing steps, validation mechanisms, and
            so forth, each of which require that the resource-type be
            appropriately identified. Clients MAY use any mechanisms
            necessary to force this determination.

        *   Validate and normalize the
     inetDnsDomainSyntax naming data. In all cases, the input
            data MUST be validated and normalized according to the
            syntax rules defined in [FIRS-DNS].

     The schema definition for the inetAssociatedResources object class
     is as follows:

          inetAssociatedResources
          ( 1.3.6.1.4.1.7161.1.2.1
            NAME 'inetAssociatedResources'
            DESC 'Internet resources associated with this resource.'
            SUP top
            AUXILIARY
            MAY ( inetAssociatedContacts $ inetAssociatedDnsDomains $
             inetAssociatedIpv4Networks $ inetAssociatedIpv6Networks $
             inetAssociatedAsNumbers ) )

     The attributes from specification which governs the inetAssociatedResources object class are
     described below:

          inetAssociatedAsNumbers
          ( 1.3.6.1.4.1.7161.1.2.2
            NAME 'inetAssociatedAsNumbers'
            DESC 'Autonomous system numbers associated with this
            Internet resource.'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.7161.1.4.1 )

          inetAssociatedContacts
          ( 1.3.6.1.4.1.7161.1.2.3
            NAME 'inetAssociatedContacts'
            DESC 'Other contacts associated with this Internet
            resource.'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.7161.1.7.1 )

          inetAssociatedDnsDomains
          ( 1.3.6.1.4.1.7161.1.2.4
            NAME 'inetAssociatedDnsDomains'
            DESC 'DNS domains associated with this Internet resource.'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.7161.1.1.1 )

  Hall                  I-D Expires: February 2004            [page 14] 
          inetAssociatedIpv4Networks
          ( 1.3.6.1.4.1.7161.1.2.5
            NAME 'inetAssociatedIpv4Networks'
            DESC 'IPv4 networks associated with this Internet
            resource.'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.7161.1.2.1 )

          inetAssociatedIpv6Networks
          ( 1.3.6.1.4.1.7161.1.2.6
            NAME 'inetAssociatedIpv6Networks'
            DESC 'IPv6 networks associated with this entry.'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.7161.1.3.1 )

  4.2.3.  Example

     An
            resource-type. As an example of the inetAssociatedResources object class is shown in
     Figure 2 below.

          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 Widgets network"
          |
          +-attribute: inetAssociatedAsNumbers
          | value: "65535"
          |
          +-attribute: inetAssociatedDnsDomains
            value: "2.0.192.in-addr.arpa"

     Figure 2: The inetAssociatedResources attributes associated this step, queries for
            internationalized domain names must be validated and
            normalized into a canonical UTF-8 form before any other
            steps can be taken. Similarly, IPv6 addresses are required
            to conform to specific syntax rules, and input address may
            need to be expanded or compressed in order to comply with
            the 192.0.2.0/24 IPv4 network entry.

  4.3.    The referral Object Class

     Entries use syntax requirements.

        *   Determine the referral object class to define subordinate
     reference referrals and continuation reference referrals, thereby
     facilitating authoritative directory partition for the programmatic redirection
            named resource. In most cases, the authoritative partition
            will be a variation of queries in support the input query string, but this is
            not always the case. For example, the default partition for
            an email address will be extrapolated from the domain
            component of the referral mechanisms defined in section 3.4. email address itself, while the
            authoritative partition for an ASN uses a reserved
            (special-purpose) domain name. In some cases, the
            authoritative partition may change during the subsequent
            query-processing steps.

  Hall                   I-D Expires: February March 2004             [page 15] 
     Referral entries MUST conform to the schema specification defined
     in [RFC3296].

     Referral sources MUST NOT contain any user-definable attributes
     (other than 21] 
        *   Determine the mandatory naming attribute), and MUST NOT have any
     subordinate child entries.

     Refer to section 3.4 search base for the query. Each resource type
            has resource-specific query-processing rules that govern referral URLs in
     FIRS. Refer which will
            dictate how the authoritative partitions are mapped to section 5.4 for information on processing referral
     URLs the
            search base. In some cases, the cn=inetResources container
            entry in FIRS.

  5.      Global Query Processing Rules

     Another critical aspect to FIRS is the authoritative partition will be used "as-is",
            while in other cases, the cn=inetResources container entry
            in a delegation parent of the authoritative partition will
            be used instead. In some cases, the search base may change
            during subsequent query-processing behavior.
     These rules govern steps.

        *   Determine the ways in which a client parses a query,
     locates a server which is authoritative assertion value for the resource being
     queried, generates LDAPv3 queries, and processes any resulting
     referrals. More specifically:

        *   Query pre-processing. query. The first step is for assertion
            value will usually be the client to
            prepare normalized form of the input
            query. Portions of this process require In some cases, the
            client assertion value may change during
            subsequent query-processing steps.

        *   Determine the matching filter. Each resource-type has its
            own matching filter rules. For example, contact entries are
            matched with a simple equalityMatch comparison, while in
            other cases the matching filter will be an extensibleMatch
            which is peculiar to determine the type resource-type in use.

     Once all of resource being queried for,
            and to determine the initial partition pre-processing steps have been successfully
     completed, the client will have to locate an LDAPv3 server which should be used
     is authoritative for the search base before it can submit the
     query. Since this This process is different for each
            particular resource-type, the rules which govern this
            behavior are defined described in each of the resource-specific
            specifications.

        * section 5.2 below.

  5.2.    Query Bootstrap processing. Models

     Once a partition client has been determined, determined which partition should be queried for
     the client must locate specified resource, the client will need to determine which
     LDAP servers which are authoritative for the resource in question. Section 5.2
            defines that partition.

     The FIRS service supports three different bootstrap models that clients can
            use as part of for
     this process, while each of the resource-
            specific specifications define which of the although these models are to
            be used for each particular resource-type.

        *   Query processing. Once only differ in relatively
     minor ways; once a server has been located, the
            client must submit rest of the LDAP query which was formed during
     process follows the pre-preprocessing phase. Section 5.3 defines same basic path (issuing the global
            considerations LDAPv3 query,
     following referrals, and so forth).

     The three bootstrapping models defined for all FIRS queries, while use with this service
     are the resource-
            specific specifications also define additional parameters.

        *   Query post-processing. FIRS explicitly supports different
            types of LDAP referral mechanisms, any of "targeted" model which may result
            in the client application restarting is functionally identical to
     traditional lookups for LDAP servers, the query or

  Hall                  I-D Expires: February 2004            [page 16] 
            initiating "top-down" model which
     causes a brand-new query. These mechanisms and their
            behavioral rules are defined in section 5.4.

     Each of these phases are discussed in more detail below.

  5.1.    Query Pre-Processing

     Client input is generally limited client to submit a single well-formed unit query to the root of
     data, such as a domain name ("example.com") or an email address
     ("admins@example.com"), delegation
     hierarchy, and this single piece of information must
     be used to subsequently build a fully-formed LDAPv3 query,
     including the assertion value, the search base, the matching
     filter, and so forth. All of these steps are part of the pre-
     processing phase.

     Although the exact sequence of steps will vary according "bottom-up" model which causes a client to the
     resource-type being queried, there are some commonalities between
     each of them. Among these steps:

        *   Determine the resource type. Different kinds of resources
            have different work
     up through a delegation hierarchy until a server has been located.

  Hall                   I-D Expires: March 2004             [page 22] 
  5.2.1.  Targeted query processing steps, validation mechanisms, and
            so forth, each

     The "targeted" model is similar to the traditional model of which require LDAP
     lookups, in that a client queries a specified LDAP server for a
     particular resource under the resource-type be
            appropriately identified. Clients MAY use any mechanisms
            necessary to force this determination.

        *   Validate and normalize assumption that the data. In all cases, named resource
     exists on the input
            data MUST be validated and normalized according to named server. If the
            syntax rules defined in known resource or the specification known
     server do not exist or cannot be located (notwithstanding any
     referrals which governs may be returned), then the
            resource-type. As query process exits.

     The targeted model can be used when an example application-specific
     partition or resource has been specified, but can also be used if
     the client prefers to use a "default" server for all operations.
     The latter may occur when clients use proxy servers, caching
     servers, or other fixed servers, in lieu of this step, queries navigating the global
     directory database with every query.

     The targeted model is primarily suited for
            internationalized domain names must be validated locating Internet
     resources which are managed and
            normalized into delegated by a canonical UTF-8 form before any other
            steps can be taken. Similarly, central body, but
     which is not necessarily located in a directory partition under a
     top-level domain. For example, AS numbers, IPv4 address blocks,
     and IPv6 addresses address blocks are required
            to conform all managed under specific partitions
     which are not directly linked to a specific syntax rules, and input address may
            need top-level domain, so
     those queries have to be expanded started at specific partitions, and would
     not be efficiently served by partitions higher or compressed lower in order to comply with
            the syntax requirements.

        *   Determine the authoritative directory partition
     delegation hierarchy.

     The steps for processing targeted queries are described below:

        a.  Determine the
            named resource. In most cases, the authoritative partition
            will IP address and port number to be used (this
            information may be determined from user input, a variation of the input query string, but
            configuration file, a URL, or from any other source).

            1.   If a non-ASCII domain name has been specified for this is
            not always
                 purpose, convert the case. For example, domain name into its ASCII-
                 compatible form using the default partition for
            an email address will be extrapolated from "ToASCII" process defined in
                 [RFC3490] before performing any lookups.

            2.   Locate the domain
            component of LDAP servers associated with the email address itself, while domain
                 name through the
            authoritative partition SRV query steps provided in section
                 5.2.4. If this step fails, use DNS lookups for an ASN uses A
                 resource records instead. If no resource records are
                 available, report the error to the user and exit.

        b.  Once a reserved
            (special-purpose) domain name. In some cases, server has been determined, submit the
            authoritative partition may change during search
            operation. If the subsequent
            query-processing steps. search operation fails, report the error

  Hall                   I-D Expires: February March 2004             [page 17] 
        *   Determine the search base for 23] 
            to the query. Each resource type
            has resource-specific query-processing rules user and exit. Otherwise, display any answer data
            which will
            dictate how is returned.

        c.  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 authoritative partitions are mapped URLs
            according to the
            search base. In some cases, the cn=inetResources container
            entry in the authoritative partition will be used "as-is",
            while rules described in other cases, section 5.4 and restart
            the cn=inetResources container entry
            in a delegation parent of query process at step 5.2.1.a. For each continuation
            reference referral, display the authoritative partition will
            be used instead. In some cases, answer data received so
            far, process the search base may change
            during subsequent query-processing steps.

        *   Determine LDAP URLs according to the assertion value rules described
            in section 5.4 and start new query processes for each
            referral at step 5.2.1.a, appending the query. The assertion
            value will usually be the normalized form of the input
            query. In some cases, the assertion value may change during
            subsequent query-processing steps.

        *   Determine output from these
            searches to the matching filter. Each resource-type has its
            own matching filter rules. For example, contact entries current output.

            Any additional subordinate reference referrals or
            continuation reference referrals which are
            matched with a simple equalityMatch comparison, while in
            other cases the matching filter encountered from
            any subsequent searches will be an extensibleMatch
            which is peculiar need to the resource-type be processed in use.

     Once all of the pre-processing steps have been successfully
     completed,
            same manner as specified above, until no additional
            referrals are received.

        d.  Exit the client will have query operation.

  5.2.2.  Top-down processing

     The top-down model uses an input string to locate construct an LDAPv3 server which
     is authoritative for the LDAP
     assertion value and search base before it can submit base, with DNS queries being used to
     locate the
     query. This process is described in section 5.2 below.

  5.2.    Query Bootstrap Models LDAP servers associated with the appropriate top-level
     delegation entity. Once this process completes, a client has determined which partition should be queried for query is issued
     to the specified resource, the client will need servers. This query may be subsequently
     redirected to determine which
     LDAP other servers are authoritative for that partition. through the use of LDAP referrals.

     The FIRS service supports three different bootstrap models top-down model is primarily suited for
     this process, although these models only differ in relatively
     minor ways; once a server has been located, locating Internet
     resources which are centrally managed and delegated, and where
     information about the rest delegation is available from a delegation
     body with a top-level domain. The best example of this is
     resources under the query
     process follows top-level domains themselves, such as queries
     for domain delegations under the same basic path (issuing "com" zone.

     Note that the LDAPv3 query,
     following referrals, and so forth).

     The three bootstrapping models defined for top-down model does not use with this service
     are incrementally larger
     domain names for the "targeted" model which bootstrap process. Instead, it is functionally identical to
     traditional lookups for LDAP servers, assumed
     that the "top-down" model which
     causes a client root partition in the delegation tree will be able to submit
     provide any necessary redirection services. For example, if the
     domain name of "www.example.co.uk" is used in a query, the query
     will be sent to the root of a delegation
     hierarchy, and a "bottom-up" model "dc=uk" partition, which causes a client to work
     up through a delegation hierarchy until a server has been located. should provide a

  Hall                   I-D Expires: February March 2004             [page 18] 
  5.2.1.  Targeted query processing

     The "targeted" model is similar to 24] 
     referral for the traditional model of LDAP
     lookups, "dc=co,dc=uk" partition, which in that a client queries turn should
     provide a specified LDAP server referral for a
     particular resource under the assumption that the named resource
     exists on "dc=example,dc=co,dc=uk" partition.

     The steps for processing top-down queries are described below:

        a.  Determine the named server. If directory partition for the known resource or query.

            1.   Separate the known
     server do not exist or cannot input string into discrete elements where
                 this is possible. For a DNS domain name of
                 "www.example.com", this would be located (notwithstanding any
     referrals which may "www", "example" and
                 "com". For the IPv4 network number of "192.0.2.14",
                 this would be returned), then "192", "0", "2" and "14". AS numbers
                 only have a single value and require no separation. Do
                 not discard the original query process exits.

     The targeted model can be used when an application-specific
     partition or resource has been specified, but can also be used if string.

            2.   IP addresses and AS numbers require additional
                 conversion. For IPv4 addresses, strip off the client prefers to use prefix
                 and convert the input string into a "default" server for all operations.
     The latter may occur when clients use proxy servers, caching
     servers, or other fixed servers, in lieu reverse-lookup DNS
                 domain name by reversing the order of navigating the global
     directory database with every query.

     The targeted model 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 primarily suited for locating Internet
     resources which are managed and delegated represented by a central body, but
     which is not necessarily located in a directory partition under a
     top-level domain. single hexadecimal
                 character), and append "ip6.arpa". For example, AS numbers, IPv4 address blocks,
     and IPv6 address blocks are all managed under specific partitions
     which are not directly linked to a specific top-level domain, so
     those queries have to be started at specific partitions, and would
     not be efficiently served by partitions higher or lower in
                 append only the
     delegation hierarchy.

     The steps "arpa" domain name.

        b.  Form the LDAP search base for processing targeted queries are described below:

        a.  Determine the IP address and port number to be used (this
            information may be determined from user input, a
            configuration file, a URL, or from any other source). query.

            1.   If a the client application allows non-ASCII domain name has been specified for this
                 purpose, input,
                 convert the domain name formed in step 5.2.2.a above
                 into its ASCII-
                 compatible ASCII-compatible form using the "ToASCII"
                 process defined in RFC 3490.

            2.   Convert the right-most element from the domain name
                 formed in step 5.2.2.b.1 into a domainComponent DN
                 (such as "dc=com" or "dc=arpa"). This represents the
                 directory partition for the current query.

            3.   Append "cn=inetResources" to the front of the
                 domainComponent syntax ("cn=inetResources,dc=com").
                 This will form the fully-qualified search base for the
                 LDAP query.

        c.  Locate the LDAP servers associated with the resource by
            processing the domain name formed in step 5.2.2.a above
            through the SRV query steps provided in section 5.2.4.

  Hall                   I-D Expires: March 2004             [page 25] 
        d.  If the SRV lookup succeeds:

            1.   Choose the best LDAP server, using the "ToASCII" process defined weighting
                 formula described in
                 [RFC3490] before performing any lookups. RFC 2782 [RFC2782].

            2.   Locate   Formulate the LDAP servers associated with search using the domain
                 name through search base and
                 search filter constructed earlier. For example, if the SRV
                 input query steps provided in section
                 5.2.4. If this step fails, use DNS lookups string was for A
                 resource records instead. If no resource records are
                 available, report "www.example.com", then the error to
                 client would begin the user process by submitting an
                 inetDnsDomainMatch extensibleMatch search with the
                 assertion value of "www.example.com", and exit.

        b.  Once with a server has been determined, submit
                 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
            operation. If with the
                 assertion value of "192.0.2.14/32", and with the
                 search base of "cn=inetResources,dc=arpa".

            3.   Submit the search operation to the chosen server and
                 port number. If the operation fails, report the error

  Hall                  I-D Expires: February 2004            [page 19]
                 failure to the user and exit. Otherwise, display any
                 answer data which is returned.

        c.

            4.   If the answer data contains a subordinate reference
                 referral or a continuation reference referral, new
                 query processes MUST be spawned.

                 For subordinate reference referrals, process the URLs
                 according to the rules described in section 5.4 and
                 restart the query process at step 5.2.1.a. 5.2.2.b. For each
                 continuation reference referral, display the answer
                 data received so far, process the LDAP URLs according
                 to the rules described in section 5.4 and start new
                 query processes for each referral at step 5.2.1.a, 5.2.2.b,
                 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.

        d.

  Hall                   I-D Expires: March 2004             [page 26] 
        e.  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.

        f.  Exit the query operation.

  5.2.2.  Top-down

  5.2.3.  Bottom-up processing

     The top-down 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 associated with the appropriate top-level
     delegation entity. Once this process completes, a query is issued
     to the specified servers. This query may be subsequently
     redirected to other servers through the use of LDAP referrals.

     The top-down model is primarily suited for locating Internet
     resources used to
     locate the LDAP servers which are centrally managed and delegated, and where
     information about associated with the delegation management
     entity that is directly responsible for the resource in question.
     If no servers are available from a for that partition, the parent
     partition in the delegation
     body hierarchy is used instead, with this
     process repeating until a top-level domain. server has been located.

     The bottom-up model is best example of this used when a leaf-node partition needs
     to be queried directly, either because there is
     resources under the top-level domains themselves, such as queries
     for domain delegations under the "com" zone.

     Note that the top-down model does not use incrementally larger
     domain names no direct
     delegation path for the bootstrap process. Instead, it is assumed
     that resource in question, or because the root user-
     managed partition in is preferable to the centralized delegation tree will be able to
     provide any necessary redirection services.
     information. For example, if the
     domain name of "www.example.co.uk" there is no global delegation body which
     assigns and manages contact identifiers, so these identifiers need
     to be directed towards the leaf-node partitions directly. The
     bottom-up model can also be used for other kinds of resources if
     desirable, although in a query, most cases the query bottom-down model will be sent to the "dc=uk" partition, which should provide a

  Hall                  I-D Expires: February 2004            [page 20] 
     referral for the "dc=co,dc=uk" partition, which in turn should
     provide a referral
     more useful for the "dc=example,dc=co,dc=uk" partition. those resources.

     The steps for processing top-down bottom-up queries are described below:

        a.  Determine the directory partition input type (DNS Domain, IPv4 Address, etc.)

        b.  Determine the authoritative DNS domain for the query. 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",
                 this would be "192", "0", "2" and "14". AS numbers
                 only have a single value and require no separation. Do not discard
                 the original query string.

            2.   IP addresses and AS numbers require additional conversion. For IPv4
                 addresses, strip off the prefix and convert the input
                 string into a reverse-lookup DNS domain name by
                 reversing the order of the octets and appending
                 "in-addr.arpa" to the right of the domain
                 name. resulting sequence.
                 For IPv6 addresses, strip off the prefix and reverse

  Hall                   I-D Expires: March 2004             [page 27] 
                 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 "ip6.arpa" to the "arpa" domain name.

        b. right of the resulting
                 sequence.

        c.  Form the LDAP search base for the query.

            1.   If the client application allows non-ASCII input,
                 convert the domain name formed in step 5.2.2.a 5.2.3.b above
                 into its ASCII-compatible form using the "ToASCII"
                 process defined in RFC 3490.

            2.   Convert the right-most element from the domain name
                 formed in step 5.2.2.b.1 into a domainComponent DN
                 (such as "dc=com" or "dc=arpa"). This represents the
                 directory partition for the current query.

            3.   Append "cn=inetResources" to the front of the
                 domainComponent syntax ("cn=inetResources,dc=com").
                 This will form the fully-qualified search base for the
                 LDAP query.

        c.  Locate the LDAP servers associated with the resource by
            processing the domain name formed in step 5.2.2.a above
            through the SRV query steps provided in section 5.2.4.

  Hall                  I-D Expires: February 2004            [page 21] 
        d.  If the SRV lookup succeeds:

            1.   Choose the best LDAP server, using the weighting
                 formula described in RFC 2782 [RFC2782].

            2.   Formulate the LDAP search using the search base and
                 search filter constructed earlier. 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".

            3.   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.

            4.   If the answer data contains in step 5.2.3.c.1 above
                 into a subordinate reference
                 referral domainComponent DN (such as
                 "dc=www,dc=example,dc=com" or a continuation reference referral, new
                 query processes MUST be spawned.

                 For subordinate reference referrals, process "dc=0,dc=2,dc=0,dc=192,
                 dc=in-addr,dc=arpa"). This represents the URLs
                 according directory
                 partition for the current query.

            3.   Append the "cn=inetResources" RDN to the rules described left of the
                 domainComponent syntax (perhaps resulting in section 5.4 and
                 restart
                 "cn=inetResources,dc=www,dc=example,dc=com"). This
                 will become the query process at step 5.2.2.b. For each
                 continuation reference referral, display search base for the answer
                 data received so far, process LDAP query.

        d.  Locate the LDAP URLs according
                 to servers associated with the rules described resource by
            processing the domain name formed in section 5.4 and start new
                 query processes for each referral at step 5.2.2.b,
                 appending the output from these searches to 5.2.3.b above
            through the
                 current output.

                 Any additional subordinate reference referrals or
                 continuation reference referrals which are encountered
                 from any subsequent searches will need to be processed SRV query steps provided in the same manner as specified above, until no
                 additional referrals are received.

  Hall                  I-D Expires: February 2004            [page 22] section 5.2.4.

        e.  If the SRV lookup fails (where failure is defined as any
            DNS response message other than with an answer), report NXDOMAIN response code (as
            described in RFC 2308 [RFC2308]), then the
            failure to domain name used
            for the user SRV lookup does not exist, and exit the current search operation.

        f.  Exit the query operation.

  5.2.3.  Bottom-up processing

     The bottom-up model uses an input string to construct an a substitute LDAP
     assertion value
            server and search base, with DNS queries being base must be used to
     locate the LDAP servers which are associated with instead. This process
            involves determining the management
     entity that is directly responsible parent zone for the resource domain name in question.
     If no servers are available
            question, issuing an SRV lookup for that partition, zone, and using
            the parent
     partition in domain name of the delegation hierarchy is used instead, zone as the new LDAP search base,
            with this process repeating until a server has been located.

     The bottom-up model is best used when a leaf-node partition needs
     to search base can be queried directly, either because there is no direct
     delegation path for
            located, or until a critical failure forces an exit.

            1.   Remove the resource left-most label from the domain name formed
                 in question, step 5.2.3.b.

            2.   If this process has already resulted in a query domain
                 name at a top-level domain such as "com" or because "arpa",
                 convert the user-
     managed partition is preferable query domain name to "." (to signify the centralized delegation
     information. For example, there
                 root domain).

  Hall                   I-D Expires: March 2004             [page 28] 
            3.   If the queried domain name is no global delegation body which
     assigns and manages contact identifiers, so these identifiers need already set to be directed towards ".", the leaf-node partitions directly. The
     bottom-up model
                 query can also be used for other kinds of resources if
     desirable, although in go no higher (this most cases likely indicates a
                 malformed DNS configuration, a connectivity problem,
                 or a typo in the bottom-down model will be
     more useful for those resources.

     The steps for processing bottom-up queries are described below:

        a.  Determine query). Exit and report the input type (DNS Domain, IPv4 Address, etc.)

        b.  Determine failure
                 to the authoritative DNS domain for user.

            4.   Restart the process at step 5.2.2.b, using the resource.

            1.   Separate domain
                 name formed above. Repeat until a server is located or
                 a critical failure forces an exit.

                 For example, if the original input string into discrete elements where
                 this is possible. For a DNS domain name of
                 "www.example.com", this
                 "www.example.com" resulted in a failed SRV lookup for
                 "_ldap._tcp.www.example.com", then the first fallback
                 SRV query would be "www", "example" for "_ldap._tcp.example.com", and
                 "com". For
                 the IPv4 network number of "192.0.2.14",
                 this next fallback query would be "192", "0", "2" for "_ldap._tcp.com",
                 possibly being followed by "_ldap._tcp.", and "14". Do not discard possibly
                 resulting in failure after that.

        f.  If the original query string. SRV lookup succeeds:

            1.   Choose the best LDAP server, using the weighting
                 formula described in [RFC2782].

            2.   IP addresses require additional conversion. For IPv4
                 addresses, strip off   Formulate the prefix LDAP search using the search base and convert
                 search filter constructed above. For example, if the
                 input query string into a reverse-lookup DNS domain name was for "www.example.com", then the
                 client would begin the process by
                 reversing submitting an
                 inetDnsDomainMatch extensibleMatch search with the order
                 assertion value of "www.example.com", with the search
                 base of "cn=inetResources,dc=www,dc=example,dc=com".
                 If the SRV lookups had failed (resulting in "com"
                 being used as the authoritative directory partition),
                 then the search base for the query would also be
                 trimmed accordingly ("cn=inetResources,dc=com").

            3.   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.

            4.   If the answer data contains a subordinate reference
                 referral or a continuation reference referral, new
                 query processes MUST be spawned.

                 For subordinate reference referrals, process the octets and appending
                 "in-addr.arpa" URLs
                 according to the right of the resulting sequence.
                 For IPv6 addresses, strip off the prefix rules described in section 5.4 and reverse

  Hall                   I-D Expires: February March 2004             [page 23] 29] 
                 restart the nibble order of query process at step 5.2.3.d. For each
                 continuation reference referral, display the address (where answer
                 data received so far, process the LDAP URLs according
                 to the rules described in section 5.4 and start new
                 query processes for each nibble is
                 represented by referral at step 5.2.3.d,
                 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 single hexadecimal character), and
                 append "ip6.arpa" fatal DNS error condition occurs, report the error to
            the right 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).

        h.  Exit the resulting
                 sequence.

        c.  Form query operation.

  5.2.4.  SRV processing

     The bootstrapping models described in this document make use of
     DNS SRV resource records to locate the LDAP search base servers associated
     with the resource provided in the query input.

     The procedure for constructing this SRV lookup is as follows:

        a.  Construct an SRV-specific label pair for the query.

            1. service type.
            For LDAP queries, this will be "_ldap._tcp".

        b.  If the client application allows non-ASCII characters to be input, then
            convert the domain name formed in step 5.2.3.b above input into its ASCII-compatible
            form by using the "ToASCII" process defined in RFC 3490.

            2.   Convert the domain name formed described in step 5.2.3.c.1 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 directory
                 partition for the current query.

            3. [RFC3490].

        c.  Append the "cn=inetResources" RDN SRV label pair 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 input domain
            name formed in from step 5.2.3.b above
            through the SRV query steps provided in section 5.2.4.

        e.  If the SRV lookup fails with an NXDOMAIN response code (as
            described in RFC 2308 [RFC2308]), then the domain name used
            for 5.2.4.b. In the SRV lookup does not exist, and case of a substitute LDAP
            server and search base must be used instead. This process
            involves determining the parent zone query for the domain name
            "example.com" domain, this would result in
            question, issuing an SRV lookup for that zone, and using
            the SRV-specific
            domain name of the zone as the new LDAP search base,
            with this process repeating until a search base can be
            located, or until "_ldap._tcp.example.com".

        d.  Issue a critical failure forces an exit.

            1.   Remove DNS query for the left-most label from SRV resource records associated
            with the domain name formed in step 5.2.3.b.

            2.   If this process has already resulted in a query domain
                 name at a top-level domain such as "com" or "arpa",
                 convert the query domain name to "." (to signify the
                 root domain). 5.2.4.b.

  Hall                   I-D Expires: February March 2004             [page 24] 
            3.   If 30] 
     Multiple SRV resource records may be returned in response to a
     query. Each resource record identifies a different connection
     target, including the queried domain name is already set to ".", the
                 query can go no higher (this most likely indicates a
                 malformed DNS configuration, of a connectivity problem,
                 or server, and a typo port number
     for that server. The port number specified in the query). Exit a SRV resource
     record MUST be used for any subsequent bind and report the failure search operations.

     SRV resource records provide "priority" and "weight" values which
     MUST be used to determine the user.

            4.   Restart the process at step 5.2.2.b, using the domain
                 name formed above. Repeat until preferred server. If a server is located
     unavailable or unreachable, a critical failure forces an exit.

                 For example, if connection attempt must be made to
     the original input string of
                 "www.example.com" resulted next-best server in the answer set.

     Refer to [RFC2782] for a failed detailed explanation of SRV lookup resource
     records and their handling.

     If a preferred connection target is listed with multiple IP
     addresses, clients should cycle through the IP addresses before
     using the next-preferred connection target.

  5.3.    Query Processing

     Once an authoritative server for
                 "_ldap._tcp.www.example.com", then the first fallback
                 SRV partition in question has
     been located, the LDAP query would can be submitted. In order to ensure
     interoperability, this specification defines several behavioral
     rules which clients and servers SHOULD conform with. These
     guidelines are discussed in the following sections.

  5.3.1.  The inetResourcesControl server control

     The inetResourcesControl server control is the master control
     object for "_ldap._tcp.example.com", the FIRS service, and provides the next fallback query would be version of each
     object class that is available for "_ldap._tcp.com",
                 possibly being followed by "_ldap._tcp.", use on the current server, and possibly
                 resulting in failure after that.

        f.  If
     also lists the SRV lookup succeeds:

            1.   Choose matching filters that the best LDAP server, using server is willing to use
     for each of the weighting
                 formula described listed object classes.

     The OID for inetResourcesControl is 1.3.6.1.4.1.7161.1.0.0. This
     value MUST be provided in [RFC2782].

            2.   Formulate the LDAP search using OID field of the search base and
                 search filter constructed above. For example, if control.

     The value section of the
                 input query string was inetResourcesControl contains nested
     sequences of data. The first element in each sequence identifies
     an object class, while first nested element identifies a matching
     filter which may be used for "www.example.com", then that object class, while the
                 client would begin next set
     of nested elements identify the process by submitting an
                 inetDnsDomainMatch extensibleMatch search attributes that may be used with the
                 assertion value
     each matching filter.

  Hall                   I-D Expires: March 2004             [page 31] 
     The structure of "www.example.com", with the search
                 base value section of "cn=inetResources,dc=www,dc=example,dc=com".
                 If inetResourcesControl is
     illustrated by the SRV lookups had failed (resulting in "com"
                 being used following ASN.1 definition:

          inetResourcesControlValue ::= SEQUENCE {
            objectClass           LDAPOID,
            matchingFilters       SEQUENCE OF matchingFilter,
            attributes            SEQUENCE OF attribute }

          matchingFilter ::= LDAPSTRING

          attribute ::= LDAPOID

     Each object class, matching filter, and attribute MUST be
     presented as a string. Object classes MUST be listed as OIDs so
     that clients can determine the authoritative directory partition),
                 then the search base supported object classes according
     to their version. Matching filters MUST also be provided as OIDs,
     except for the query would also "stock" matching filter operators defined in
     [RFC2251], which MUST be
                 trimmed accordingly ("cn=inetResources,dc=com").

            3.   Submit presented with the textual identifiers
     shown therein. Attributes MUST be listed with their textual
     identifiers.

     At a minimum, servers MUST support the equalityMatch and
     extensibleMatch filters from [RFC2251] for every object class
     listed, and SHOULD always declare these filters. Furthermore,
     servers MUST support the search operation "cn" attribute for every matching filter,
     and SHOULD declare these attributes. The Asterisk character ("*")
     MAY be provided as a wildcard to indicate that the chosen server and
                 port number. If the operation fails, report will
     accept any matching filter for the
                 failure associated object class, or to
     indicate that the user and exit. Otherwise, display server will accept any
                 answer data which is returned.

            4.   If attribute for the answer data contains a subordinate reference
                 referral or a continuation reference referral, new
                 query processes
     associated matching filter. Servers MUST be spawned.

                 For subordinate reference referrals, process the URLs
                 according allow any supported
     matching filter to the rules described in section 5.4 be used as part of an extensibleMatch
     operation, and clients MAY assume that any allowed operation will
     be acceptable as part of an extensibleMatch.

  Hall                   I-D Expires: February March 2004             [page 25] 
                 restart the query process at step 5.2.3.d. For each
                 continuation reference referral, display the answer
                 data received so far, process the LDAP URLs according
                 to 32] 
     An example of an inetResourcesControl server control is shown
     below for illustration purposes:

          { 1.3.6.1.4.1.7161.1.0.0, FALSE, {
                  1.3.6.1.4.1.7161.1.1.1 {
                          equalityMatch {*},
                          extensibleMatch {*} } }, {
                  1.3.6.1.4.1.7161.1.3.1 {
                          1.3.6.1.4.1.7161.1.3.0.1 {*},
                          equalityMatch {*},
                          substringMatch {cn},
                          extensibleMatch {*} } } }

     Figure 3: An example inetResourcesControl server control.

     In the rules described example shown in section 5.4 and start new
                 query processes for each referral at step 5.2.3.d,
                 appending Figure 3, the output from these searches to inetResourcesControl type is
     identified by 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 OID of 1.3.6.1.4.1.7161.1.0.0, while the same manner
     criticality field is set to FALSE, as specified above, until no
                 additional referrals are received.

        g.  If a fatal DNS error condition occurs, report per the error to requirements in
     [RFC2251]. The contents of the user and stop processing control value identify the current query. A fatal DNS
            error is any response message
     OID for the inetResources object class along with an RCODE the [RFC2251]
     textual identifiers 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).

        h.  Exit the query operation.

  5.2.4.  SRV processing

     The bootstrapping models described in this document make use equalityMatch and extensibleMatch
     operators, each of
     DNS SRV resource records to locate which will accept any attributes. Figure 3 also
     identifies the LDAP servers associated OID for the inetDnsDomain object class along with
     the resource provided in OID for the query input.

     The procedure inetDnsDomainMatch and the [RFC2251] textual
     identifiers for constructing this SRV lookup the equalityMatch, substringMatch and
     extensibleMatch operators, although the substringMatch filter is
     only advertised for use with the "cn" attribute.

     FIRS-compliant servers SHOULD return the inetResourcesControl
     server control as follows:

        a.  Construct an SRV-specific label pair unsolicited response to a successful bind
     request. Clients MUST use the OID of the inetResourcesControl for
     the service type.
            For LDAP queries, this will be "_ldap._tcp".

        b.  If purpose of validating the client allows non-ASCII characters to be input, then
            convert contents of the domain name input into its ASCII-compatible
            form by using control, and MUST
     use the "ToASCII" process described in [RFC3490].

        c.  Append OIDs of the SRV label pair listed object classes to discover schema
     versioning information.

     Servers MAY restrict the left contents of the input domain
            name from step 5.2.4.b. In inetResourcesControl
     value according to the case authenticated identity of the client. For
     example, servers can choose to enable computationally-intense
     searches for authorized users while refusing to provide the same
     searches for anonymous users.

     If a client does not receive a query for the
            "example.com" domain, this would result in an SRV-specific
            domain name usable inetResourcesControl control
     as part of "_ldap._tcp.example.com".

        d.  Issue the bind response, the client SHOULD issue a DNS query request
     for the SRV resource records associated
            with control before proceeding. If a client is still unable to
     obtain a usable inetResourcesControl server control, the domain name formed in step 5.2.4.b. client

  Hall                   I-D Expires: February March 2004             [page 26] 
     Multiple SRV resource records may be returned in response to a
     query. Each resource record identifies 33] 
     MAY choose a different connection
     target, including the domain name of a server, and a port number server for the partition, or MAY choose to
     assume that server. The port number specified in a SRV resource
     record MUST the equalityMatch matching filter will be used supported
     for any subsequent bind and search operations.

     SRV resource records provide "priority" and "weight" values which
     MUST be used of the known types, or MAY choose to determine undergo any other
     recovery efforts. In any event, clients SHOULD NOT use the preferred server. If a server is
     unavailable absence
     or unreachable, contents of the control to completely abort query processing
     unless all of the servers for a connection attempt must be made partition have refused to provide
     service to the client.

     For example, if the server advertises support for the
     inetDnsDomain object class but does not advertise support for the
     inetDnsDomainMatch matching filter, the client MAY issue discrete
     equality searches for each of the specific domain name resources
     (note that this kind of query can fail to produce referrals in
     some cases, but will usually produce at least some answers).

     In all cases, if any given server advertises support for a
     particular object class or matching filter, the client MUST make
     use of the next-best server server-provided service.

  5.3.2.  Matching filters

     LDAP search filters are fairly flexible, in the answer set.

     Refer to [RFC2782] that they allow for a detailed explanation
     wide variety of SRV resource
     records and their handling.

     If a preferred connection target is listed with multiple IP
     addresses, clients should cycle through the IP addresses before
     using the next-preferred connection target.

  5.3.    Query Processing

     Once an authoritative server for configurable elements, such as the partition in question has
     been located, maximum number
     of entries which are returned, the LDAP query can type of comparison operation
     that needs to be submitted. performed, and other details. In order to ensure
     interoperability, this specification default values are defined here for many of
     these elements.

     [RFC2251] defines several behavioral
     rules which 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
     FIRS clients and servers SHOULD conform with. These
     guidelines are discussed in servers, this document defines some recommended
     and mandatory values for searches within the following sections.

  5.3.1.  The firsVersion server control

     When a client successfully binds FIRS service.

            NOTE: These rules ONLY apply to a FIRS-compatible server, the
     server FIRS search operations
            in particular. Any queries for other resources SHOULD return the "firsVersion" server control described
     below.

     The firsVersion control has an OID of 1.3.6.1.4.1.7161.1.0.0. The
     value field of the control MUST provide the OIDs of the FIRS-
     specific object classes NOT
            impose these restrictions. Also note that other documents
            which define additional resource types can also define
            different restrictions, and those definitions will take
            precedence over the server supports, with each global defaults.

     Servers MUST be prepared to enforce these rules independently of
     the OIDs being separated by Dollar Sign characters ("$"). At client settings, and clients MUST be prepared to receive
     truncated search results accordingly.

  Hall                   I-D Expires: March 2004             [page 34] 
     The default values of an LDAPv3 search filter in FIRS are:

        *   Search base. The directory partition to be used in a
     minimum, this field SHOULD contain search
            will vary for each query operation. The methodology for
            determining the OID current search base for a query is defined
            by the inetResources
     object class query-processing protocols described in section 4.1, but MAY contain 5.1,
            although FIRS searches are normally constrained to the OID for
     any
            "cn=inetResources" container of the resource-specific object classes (such as inetDnsDomain
     or inetIpv4Network).

     The OID values a particular directory
            partition.

        *   Scope. In order to successfully locate referral stub child
            entries, clients MUST use a sub-tree scope for FIRS
            searches. Servers MUST NOT be provided unless arbitrarily limit the server fully
     supports all scope of
            search operations.

        *   Dereference aliases. Although the schema definitions associated with that object
     class, specifically including any attributes, syntaxes and
     matching filters defined for use with that resource type. For

  Hall                  I-D Expires: February 2004            [page 27] 
     example, if a server "supports" the inetDnsDomain object class but FIRS service does not support the inetDnsDomainSyntax naming syntax or does
            make direct use of alias entries, they are not
     support the inetDnsDomainMatch matching filter, then that server
     MUST NOT return prohibited.
            Clients SHOULD set the OID Dereference Aliases option to
            "Always" for FIRS searches. Servers SHOULD dereference any
            aliases which are encountered, where this is feasible (in
            particular, where the inetDnsDomain object class.

     Clients MAY use alias refers to another directory
            partition on the same server).

        *   Size limit. The size limit field specifies the absence or contents maximum
            number of entries that a server should return. For the firsVersion control FIRS
            service, this setting SHOULD be set to choose a different server, but SHOULD NOT use value between 25
            and 100. This range ensures that the absence or
     contents client is capable of this control alone
            receiving a sufficient number of entries and continuation
            references in a single response, but also works to abort processing. E.G., 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 if none
     of the servers provide client specifies a larger value.

        *   Time limit. The time limit field specifies the firsVersion control, then maximum
            number of seconds that a server should process the client
     can search.
            For the FIRS service, this setting SHOULD be said set to have run out of servers, a value
            between 10 and MAY abort the current
     query process.

     Clients MAY also use 60 seconds. This range ensures that the absence or contents
            server is able to process a sufficient number of the firsVersion
     control entries,
            but also works to perform local prevent runaway queries that match
            everything. Servers MAY stop processing which would otherwise usually
     be performed by queries after the server. For example,
            time limit if the server does client specifies a larger value.

        *   Types-only. The types-only setting is a Boolean flag which
            controls whether or not
     advertise support for the inetDnsDomain object class, attribute values are returned in

  Hall                   I-D Expires: March 2004             [page 35] 
            the client 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 discrete searches for resources, instead of relying on the server for these functions. However, if necessary subsequent queries.

        *   Filter. The search operation will depend on the server does
     advertise support for a particular resource type, type of
            data being queried. For FIRS queries, the client filter MUST
     make use of
            the server-provided services.

  5.3.2.  Matching filters

     LDAP search filters are fairly flexible, in that they allow matching rules defined for a
     wide variety of configurable elements, such as the maximum number relevant resource type.

        *   Attribute list. Clients MAY restrict the list of entries attributes
            which are returned, the type of comparison operation
     that needs to be performed, and other details. In order to ensure
     interoperability, default values returned in searches, but are defined here for many of
     these elements.

     [RFC2251] defines the LDAP search request specification, discouraged from
            doing so without cause.

  5.3.3.  Query-volume restrictions

     The restrictions listed in section 5.3.2 represent suggested
     defaults, although
     it does not provide guidelines server operators MAY impose any kinds of usage
     limits they deem necessary or recommended values for desirable.

     Specifically, server operators MAY restrict the
     filter settings. In an effort amount of
     information provided to promote interoperability among
     FIRS specific clients and servers, this document defines some recommended
     and mandatory values for searches and/or users over a given
     amount of time, within the FIRS service.

            NOTE: These rules ONLY apply reason. For example, servers MAY restrict
     clients to an arbitrary number of queries per-hour or per-day, or
     may impose mandatory time intervals between queries, and so forth.
     Similarly, servers MAY restrict clients to an arbitrary number of
     answers over a given time period, such as limiting clients to 100
     answers regardless of the FIRS search operations
            in particular. Any number of queries for other resources SHOULD NOT
            impose these restrictions. Also note that other documents which define additional resource types can also define
            different restrictions, and were used to
     generate those definitions will take
            precedence over the global defaults. answers.

     Servers MUST be prepared which refuse to enforce these rules independently of process a query due to volume policy
     SHOULD use the client settings, and clients MUST be prepared "unwillingToPerform" response code ("53") to receive
     truncated search results accordingly.

  Hall                  I-D Expires: February 2004            [page 28] 
     The default values inform
     the client of an LDAPv3 search filter these restrictions, and SHOULD provide explanatory
     text in FIRS are:

        *   Search base. The directory partition to the error message. These errors SHOULD be used in a search
            will vary for each query operation. The methodology for
            determining generated when
     the current search base for a query session is defined first established, if at all possible.

     In the worst cases, servers MAY deny all service to abusive
     clients. This can be implemented by rejecting the query-processing protocols described TCP connection
     outright, or by providing an explanatory error early in section 5.1,
            although FIRS searches are normally constrained the
     session, or at any other point.

     Clients MUST be prepared for connection requests and queries to be
     denied for any reason, and MUST treat these conditions as non-
     permanent failures. Clients MAY retry the
            "cn=inetResources" container of operations if a particular directory
            partition.

        *   Scope. In order known
     error condition is corrected (such as authentication errors), but
     SHOULD NOT automatically generate retry attempts.

  Hall                   I-D Expires: March 2004             [page 36] 
  5.3.4.  Authentication restrictions

     Servers operators SHOULD allow anonymous authentication for read-
     only access to support continuation reference referrals
            (which are defined as referral entries beneath a resource-
            specific entry), clients MUST public delegation data. Clients SHOULD use
     anonymous authentication by default.

     Wherever a sub-tree scope server operator requires or desires clients to
     authenticate for FIRS
            searches. Servers access, servers MUST NOT arbitrarily limit support the scope of
            search operations.

        *   Dereference aliases. Although simple
     authentication mechanism defined in RFC 2222 [RFC2222], although
     server operators MAY require the FIRS service does not
            make direct use of alias entries, they are not prohibited.
            Clients SHOULD set the Dereference Aliases option to
            "Always" for FIRS searches. Servers SHOULD dereference any
            aliases which are encountered, where this is feasible (in
            particular, where the alias refers authentication
     mechanisms in addition to another directory
            partition on the same server).

        *   Size limit. The size limit field specifies the maximum
            number or instead of entries that a server should return. For the FIRS
            service, this setting SHOULD be set to a value between 25
            and 100. This range ensures that simple mechanism.

     Server operators MAY define any access controls on 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 data, as searches
     necessary for
            "com", which can match every inetDnsDomain entry in the
            "cn=inetResources,dc=com" container). Servers policy considerations. Server operators SHOULD NOT
     impose unreasonable requirements for proprietary authentication
     mechanisms for routine purposes.

     Server operators MAY truncate
            answer sets to 100 responses if withhold privileged information from non-
     privileged clients or users, as necessary.

     Clients MUST NOT equate the client specifies a
            larger value.

        *   Time limit. The time limit field specifies absence of any attributes with the maximum
            number
     absence of seconds data, and SHOULD assume that a server should process the search.
            For the FIRS service, this setting SHOULD be set authenticated user is
     not authorized to view any data which has not been provided.

     If a value
            between 10 and 60 seconds. This range ensures that client specifically requests an entry or an attribute which
     the server is able unwilling to process a sufficient number of entries,
            but also works provide due to prevent runaway queries that match
            everything. Servers MAY stop processing queries after 60
            seconds ACL settings, the server
     MUST use the appropriate LDAPv3 error message. For example, if the client specifies a larger value.

  Hall                  I-D Expires: February 2004            [page 29] 
        *   Types-only. The types-only setting
     user is a Boolean flag which
            controls whether unable to view an entry or a requested attribute because
     it has not yet provided sufficient authentication credentials, the
     server MUST return the "invalidCredentials" error. Similarly, if
     the client has requested an entry or attribute values are returned in which the answer sets. Since excessive queries are likely to be
            more burdensome than larger answer sets, this setting
            SHOULD be set server is
     unwilling to FALSE. Resource-constrained clients (such
            as PDAs) MAY set this value provide due to TRUE, but these clients policy reasons, the server MUST return
     the unwillingToPerform error to the client.

     See section 5.3.5 for mechanisms that can be used to determine
     and/or describe usage restrictions on specific attribute values.

  5.3.5.  Extended attribute ACLs

     In normal operations, attributes and values that the client is not
     authorized to view would not be prepared returned in response to issue the necessary subsequent queries.

        *   Filter. The search operation will depend on queries
     for that data, with the type client equating a lack of data being queried. For FIRS queries, the filter MUST use
            the matching rules defined in a
     particular attribute with "no data that you are authorized to
     view". However, [CRISP-REQ] defines additional response types for
     conveying explicit restrictions on data (such as reporting that

  Hall                   I-D Expires: March 2004             [page 37] 
     the relevant resource type.

        *   Attribute list. Clients MAY restrict data is restricted due to privacy considerations), and which
     requires more comprehensive reporting than simply omitting data
     that the list user is not authorized to view.

     This extended data is provided through the use of attributes
            which are returned in searches, but are discouraged from
            doing so without cause.

  5.3.3.  Query-volume restrictions

     The restrictions listed LDAP attribute
     options, as described in section 5.3.2 represent suggested
     defaults, although server operators MAY impose any kinds 4.1.5 of usage
     limits they deem necessary or desirable.

     Specifically, server operators MAY restrict [RFC2251] (this is the amount of
     information provided to specific clients and/or users over a given
     amount
     same mechanism as used with language tags), using "inetExtAcl-" as
     the option prefix.

     The current-valid list of time, within reason. For example, servers MAY restrict
     clients attribute options are:

        *   InetExtAcl-S0 -- Security Restricted. Some attribute values
            have not been returned due to an arbitrary number of queries per hour, per day, and
     so forth. Servers security requirements which refuse to process a query
            have not been met.

        *   InetExtAcl-P0 -- Privacy Restricted. Some attribute values
            have not been returned due to volume
     policy SHOULD reject privacy requirements which
            have not been met.

        *   InetExtAcl-S1 -- Security Cleared. The security
            requirements on the associated attribute values have been
            met and the user has been granted access to the connection and/or query using data.

        *   InetExtAcl-P1 -- Privacy Cleared. The privacy requirements
            on the
     "unwillingToPerform" response code ("53").

     Clients MUST be prepared for connection requests associated attribute values have been met and queries the
            user has been granted access to the data.

        *   InetExtAcl-R0 -- Do Not Distribute. The associated
            attribute values are not to be
     denied for any reason, and reused outside this session.

     Each attribute instance MUST treat these conditions as non-
     permanent failures. Clients MAY retry have one of the operations if a known
     error condition is corrected (such as authentication errors), above attribute
     options, but
     SHOULD MUST NOT automatically generate retry attempts.

  5.3.4.  Authentication restrictions

     Servers operators SHOULD allow anonymous authentication for read-
     only access have more than one option. Multiple
     instances of the attribute option MAY be assigned to public delegation data. Clients an attribute,
     although the instances SHOULD use
     anonymous authentication by default.

     Wherever NOT have conflicting meanings.

     As a server operator requires or desires clients simple example, "mail;inetExtAcl-S1:admins@example.com" would
     indicate that this instance of the "mail" attribute had an ACL
     protecting it from normal use, but that the user was authorized to
     authenticate for access, servers MUST support
     view the simple
     authentication mechanism defined in RFC 2222 [RFC2222], although attribute data. Meanwhile, the attribute instance of
     "mail;inetExtAcl-S1;inetExt-R0:admins@example.com" would indicate
     that the user had been granted access to the data, but that the
     user must not distribute the data.

  Hall                   I-D Expires: February March 2004             [page 30] 
     server operators MAY require the use 38] 
     Multiple and varying instances of any authentication
     mechanisms an attribute can co-exist in addition to or instead of an
     entry simultaneously if necessary. For example, the simple mechanism.

     Server operators SHOULD NOT impose unreasonable requirements following
     entries can all co-exist within a single entry.

          mail:admins@example.com
          mail;inetExtAcl-S1:postmaster@example.com
          mail;inetExtAcl-P1:jack@example.com
          mail;inetExtAcl-P1:inetExtAcl-R0:jill@example.com

     In that example, searches for
     proprietary authentication mechanisms the "mail" attribute would produce
     the public information, while searches for routine purposes.

     Server operators MAY withhold privileged information from non-
     privileged clients or users, as necessary.

     Clients MUST NOT equate the absence of any attributes with other attribute
     instances would produce the
     absence alternate data.

     Each instance of data, and SHOULD assume that the user is not authorized
     to view any data which has not been provided.

     If a client specifically requests an entry or an attribute which can have its own ACLs in the server is unable or unwilling
     directory, thereby allowing specific instances of an attribute to provide due
     be restricted to policy
     constraints, the server MUST use the appropriate LDAPv3 error
     message. certain users. For example, if ACLs on the user is unable to view
     inetExtAcl-S1 instance of an attribute can be defined so that the
     entry or a
     requested owner can view the data, while the inetExtAcl-S0 instance
     can be set such that help-desk operators are able to see that
     there are hidden attribute because it has values (but without exposing the values
     to those users), but with both instances being hidden from
     anonymous users so that the general public does not yet provided sufficient
     authentication credentials, know that
     there are any extended attribute options.

     Each instance of the server MUST return attributes can be requested through normal
     query processes, although the
     "invalidCredentials" error. Similarly, if inetExtAcl-S0 and inetExtAcl-P0
     attributes will always be empty (the presence of the attribute
     option implies that the related data could not be returned), and
     thus those instances will never be returned.

     In order to simplify these requests and responses, an
     inetExtAclControl client has control is provided that specifically
     allows for the request
     an entry or of all extended ACL attribute which options. The
     OID for the server inetExtAclControl control is unwilling to 1.3.6.1.4.1.7161.1.0.1.
     Clients MUST provide due this control as part of the search request,
     and servers which support this control MUST return all of the
     regular and extended ACL attributes that are defined for an entry
     (according to policy reasons, the server MUST return the unwillingToPerform
     error to ACLs appropriate for the client.

  5.3.5. current user).

  5.3.6.  Protocol and schema version controls

     The FIRS collection of specifications are explicitly bound to the
     LDAPv3 protocol, as defined by [RFC3377] and its subordinate
     specifications. If a new version of the LDAP protocol emerges, it
     is expected that some type of mechanism will be included for end-

  Hall                   I-D Expires: March 2004             [page 39] 
     points to use when negotiating over the version in use. Lacking
     such a mechanism, FIRS is explicitly restricted to LDAPv3.

     LDAP attributes, object classes, syntaxes and matching filters
     have OIDs which uniquely identify the format of the data they
     provide, and which act as simple schema-version identifiers in the
     generic case. [RFC2251] defines standardized mechanisms for
     retrieving and reading the OIDs associated with object classes and
     attributes (among other resource types). These mechanisms MAY be
     used whenever a FIRS client reads an entry, and MUST be used
     whenever a FIRS client modifies or creates an entry (even though
     FIRS does not define mechanisms for updating entries, it is
     assumed that some clients will allow this behavior).

     The firsVersion server control described in section 5.3.1 provides
     a mechanism for clients to detect which resource-types are

  Hall                  I-D Expires: February 2004            [page 31] 
     supported by the server, although that mechanism MUST NOT be used
     for any purposes other than defined herein.

     Modifications to existing schema definitions MUST be accompanied
     by OID changes.

  5.4.    Referral Processing

     As was discussed in section 3.4, FIRS supports two types of
     referrals, which are subordinate reference referrals and
     continuation reference referrals. Both referral types use URLs for
     the purpose of providing referral targets, using the rules
     described in section 3.4 of this document.

     Non-compliance with the requirements provided in section 3.4
     amounts to an error, and is sufficient cause for a client to stop
     processing a query.

     As was discussed in section 3.4, subordinate reference referrals
     are defined in [RFC3296], and use the SearchResultDone response
     with a Referral result code as defined in [RFC2251]. Subordinate
     reference referrals use a subset of the labeledURI syntax as
     defined in [RFC2079], and use the syntax definitions from
     [RFC2255] when LDAP URLs in particular are provided, although
     section 3.4 of this document also defines additional restrictions
     on the allowable URL syntax. This condition means that the current
     search operation cannot proceed past this point, reads an entry, and the search MUST be restarted. This will most often occur when the
     inetResources used
     whenever a FIRS client modifies or creates an entry (even though
     FIRS does not define mechanisms for a partition has been redirected to another
     directory partition.

     Continuation reference referrals use the SearchResultReference
     response, which updating entries, it is defined and
     assumed that some clients will allow this behavior).

     The inetResourcesControl server control described in section 4.5.3 of
     [RFC2251]. Continuation reference referrals use 5.3.1
     provides a subset of the
     labeledURI syntax as defined in [RFC2079], and mechanism that clients can use the syntax
     definitions from [RFC2255] when LDAP URLs in particular are to be
     provided, although section 3.4 of this document also defines
     additional restrictions on the allowable URL syntax. This
     condition means that determine the current search operation has partially
     succeeded, but that additional searches SHOULD be started in order
     for all version
     of an object class or matching filter that the answer data server supports.

     Any modifications to any existing schema definitions MUST be retrieved (in many cases, no
     answer data will be provided, and in those situations,
     accompanied by new queries
     will be required OID assignments for any data to be retrieved). This will occur
     whenever the assertion value affected elements.

  5.4.    Referral Processing

     As was discussed in section 3.5, FIRS supports two types of a search has matched a resource
     entry LDAP
     referrals, which is being managed by another directory partition, are subordinate reference referrals and

  Hall                  I-D Expires: February 2004            [page 32] 
     can occur with any
     continuation reference referrals. Both referral types use URLs for
     the purpose of providing referral targets, using the search operations rules
     described in this
     document. section 3.5 of this document.

     Non-compliance with the URL formatting requirements provided in
     section 3.5.2 amounts to an error, and is sufficient cause for a
     client to stop processing a query.

     The procedure for processing referral URLs is as follows:

        a.  [RFC2251] 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.  Locate the LDAP URLs in the referral data, and discard any
            URLs which use any other service types. FIRS clients MUST
            support LDAP URLs. URLs with other service type identifiers
            SHOULD be ignored.

        c.  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 port
            number discovered through any subsequent SRV lookups (as
            described below), or as a last resort use the default port
            number associated with the protocol identifier.

        d.  Determine the authoritative partition and search base
            specified in the referral URL.

            1.   If no distinguished name element was provided, reuse
                 the existing authoritative partition and search base.

            2.   Otherwise, use the distinguished name element for the
                 search base of the subsequent search operation.

            3.   Extract the sequence of domainComponent distinguished
                 names from the search base, and use them as the
                 authoritative partition.

        e.  Determine the server address and port number specified in
            the referral URL.

            1.   If a host identifier was not provided, map the
                 domainComponent elements determined in step 5.4.d to a
                 DNS domain name and submit a DNS lookup for the SRV
                 resource records associated with that domain name. If

  Hall                  I-D Expires: February 2004            [page 33] failures,
            although this step fails, report is not required). Select one of the error URLs at
            random ("round-robin"), and continue to the user and exit next step in
            the query.

            2.   If process.

        b.  Locate the host identifier is an IP address, extract it LDAP URLs in the referral data, and skip to step 5.4.f.

            3.   If no discard any
            URLs which use any other service types. FIRS clients MUST

  Hall                   I-D Expires: March 2004             [page 40] 
            support LDAP URLs. URLs with other service type identifiers
            SHOULD be ignored.

        c.  Extract any port number was which may have been provided in with
            the URL, submit a
                 DNS lookup and set it aside for the SRV resource records associated possible use with the domain name, as described in section 5.2.4.
                 If this lookup succeeds, skip to step 5.4.f.

            4.   If
            subsequent connection attempt. Use the port number
            discovered through any subsequent SRV lookup from the previous step fails, lookups (as described
            below), or if
                 no as a last resort use the default port number was specified, submit a DNS lookup for
            associated with the A resource records.

        f. protocol identifier.

        d.  Determine the new assertion value and/or matching filter authoritative partition and search base
            specified in the referral URL.

            1.   If the URL's path no distinguished name element does not contain a filter
                 element, reuse was provided,
                 determine the current matching filter authoritative partition and
                 assertion value.

            2.   If the URL's path element contains a filter element,
                 use it to form search base
                 from the new matching filter and/or provided assertion value.

        g.  Discard the remainder of value, according to the URL.

        h.  Use
                 procedures for the discovered parameter values to start a new query.

     For example, imagine that a referral has been received with bootstrap model that is most
                 relevant to the
     URL value of "ldap:///cn=inetResources,dc=example,dc=com". The
     processing rules resource-type.

            2.   Otherwise, use the distinguished name element for this URL would be as follows:

        *   Use "cn=inetResources,dc=example,dc=com" as the new
                 search base for of the subsequent query.

        *   Use search operation.

            3.   Extract the domainComponent sequence of "dc=example,dc=com" domainComponent distinguished
                 names from the search base, and use them as the new
                 authoritative partition.

        *   No host identifier was

        e.  Determine the server address and port number specified in
            the URL, so referral URL.

            1.   If a host identifier was not provided, map the
            "dc=example,dc=com" partition must be used
                 domainComponent elements determined in step 5.4.d to seed a server
            identifier of "example.com".

  Hall                  I-D Expires: February 2004            [page 34] 
        *   Issue
                 DNS lookups domain name and submit a DNS lookup for the SRV
                 resource records associated with "_ldap._tcp.example.com" to determine the server and
            port number for that domain name. If
                 this step fails, report the subsequent query.

        *   Reuse error to the existing assertion value user and matching filter.

     As another example, imagine a referral with the URL value of
     "ldap://example.com/cn=inetResources,dc=example,dc=com". The
     processing rules for this URL would be as follows:

        *   Use "cn=inetResources,dc=example,dc=com" as the new search
            base for exit
                 the subsequent query.

        *   Use the domainComponent sequence of "dc=example,dc=com" as
            the new authoritative partition.

        *   Use

            2.   If the host identifier of "example.com" as specified is an IP address, extract it
                 and skip to step 5.4.f.

            3.   If no port number was provided in the URL.

        *   Issue URL, submit a
                 DNS lookups lookup for the SRV resource records associated
                 with "_ldap._tcp.example.com" the domain name, as described in section 5.2.4.
                 If this lookup succeeds, skip to determine step 5.4.f.

  Hall                   I-D Expires: March 2004             [page 41] 
            4.   If the server and SRV lookup from the previous step fails, or if
                 no port number was specified, submit a DNS lookup for
                 the subsequent query.

        *   Reuse A resource records.

        f.  Determine the existing new assertion value and and/or matching filter.

     As another example, imagine a filter
            specified in the referral with URL.

            1.   If the URL value of
     "ldap:////???(cn:dn:www.example.com). The processing rules for
     this URL would be as follows:

        *   Reuse URL's path element does not contain a filter
                 element, reuse the existing search base current matching filter and authoritative partition
            information.

        *   Reuse
                 assertion value.

            2.   If the existing server and port number.

        *   Use "(cn:dn:www.example.com)" as URL's path element contains a filter element,
                 use it to form the new matching filter
            and and/or
                 assertion value.

        g.  Discard the remainder of the URL.

        h.  Use the discovered parameter values to start a new query.

     Note that step 5.4.g requires the client to discard the remainder
     of the URL, although this step may be changed in subsequent
     versions of this specification. In particular, [CRISP-REQ]
     requires the ability to pass an inter-server "referral bag", and
     this mechanism may be implemented through the use of extensions in
     the LDAP URL.

  Hall                  I-D Expires: February 2004            [page 35]

  6.      Security Considerations

     Security considerations are discussed in [FIRS-ARCH].

  7.      IANA Considerations

     IANA considerations are discussed in [FIRS-ARCH].

  8.      Normative References

          [RFC1274]     Barker, P., and Kille, S. "The COSINE and
                         Internet X.500 Schema", RFC 1274, November
                         1991.

          [RFC2079]     Smith, M. "Definition of an X.500 Attribute
                         Type and an Object Class to Hold Uniform
                         Resource Identifiers (URIs)", RFC 2079,
                         January 1997.

          [RFC2222]     Myers, J. "Simple Authentication and Security
                         Layer (SASL)", RFC 2222, October 1997.

  Hall                   I-D Expires: March 2004             [page 42] 
          [RFC2247]     Kille, S., Wahl, M., Grimstad, A., Huber, R.,
                         and Sataluri, S. "Using Domains in LDAP/X.500
                         DNs", RFC 2247, January 1998.

          [RFC2251]     Wahl, M., Howes, T., and Kille, S.
                         "Lightweight Directory Access Protocol (v3)",
                         RFC 2251, December 1997.

          [RFC2252]     Wahl, M., Coulbeck, A., Howes, T., and Kille,
                         S. "Lightweight Directory Access Protocol
                         (v3): Attribute Syntax Definitions", RFC 2252,
                         December 1997.

          [RFC2253]     Wahl, M., Kille, S., and Howes, T.
                         "Lightweight Directory Access Protocol (v3):
                         UTF-8 String Representation of DNs", RFC 2253,
                         December 1997.

          [RFC2254]     Howes, T. "The String Representation of LDAP
                         Search Filters", RFC 2254, December 1997.

          [RFC2255]     Howes, T., and Smith, M. "The LDAP URL
                         Format", RFC 2255, December 1997.

          [RFC2256]     Wahl, M. "A Summary of the X.500(96) User
                         Schema for use with LDAPv3", RFC 2256,
                         December 1997.

  Hall                  I-D Expires: February 2004            [page 36]

          [RFC2277]     Alvestrand, H. "IETF Policy on Character Sets
                         and Languages", BCP 18, RFC 2277, January
                         1998.

          [RFC2308]     Andrews, M. "Negative Caching of DNS Queries
                         (DNS NCACHE)", RFC 2308, March 1998.

          [RFC2596]     Wahl, M., and Howes, T. "Use of Language Codes
                         in LDAP", RFC 2596, May 1999.

          [RFC2782]     Gulbrandsen, A., Vixie, P., and Esibov, L. "A
                         DNS RR for specifying the location of services
                         (DNS SRV)", RFC 2782, February 2000.

          [RFC2798]     Smith, M. "Definition of the inetOrgPerson
                         LDAP Object Class", RFC 2798, April 2000.

          [RFC3296]     Zeilenga, K. "Named Subordinate References in
                         Lightweight Directory Access Protocol (LDAP)
                         Directories", RFC 3296, July 2002.

  Hall                   I-D Expires: March 2004             [page 43] 
          [RFC3377]     Hodges, J., and Morgan, R. "Lightweight
                         Directory Access Protocol (v3): Technical
                         Specification", RFC 3377, September 2002.

          [RFC3490]     Falstrom, P., Hoffman, P., and Costello, A.
                         "Internationalizing Domain Names in
                         Applications (IDNA)", RFC 3490, March 2003.

          [FIRS-ARCH]   Hall, E. "The Federated Internet Registry
                         Service: Architecture and Implementation
                         Guide", draft-ietf-crisp-firs-arch-02, July draft-ietf-crisp-firs-arch-03, August
                         2003.

          [FIRS-ASN]    Hall, E. "Defining and Locating Autonomous
                         System Numbers in the Federated Internet
                         Registry Service", draft-ietf-crisp-firs-asn-
                         02, July
                         03, August 2003.

          [FIRS-CONTCT] Hall, E. "Defining and Locating Contact
                         Persons in the Federated Internet Registry
                         Service", draft-ietf-crisp-firs-contact-02,
                         July 2003.

          [FIRS-CORE]   Hall, E. "The Federated Internet Registry
                         Service: Core Elements", draft-ietf-crisp-
                         firs-core-02, July draft-ietf-crisp-firs-contact-03,
                         August 2003.

  Hall                  I-D Expires: February 2004            [page 37]

          [FIRS-DNS]    Hall, E. "Defining and Locating DNS Domains in
                         the Federated Internet Registry Service",
                         draft-ietf-crisp-firs-dns-02, July
                         draft-ietf-crisp-firs-dns-03, August 2003.

          [FIRS-DNSRR]  Hall, E. "Defining and Locating DNS Resource
                         Records in the Federated Internet Registry
                         Service", draft-ietf-crisp-firs-dnsrr-02, July
                         2003.

          [FIRS-IPV4]   Hall, E. "Defining and Locating IPv4 Address
                         Blocks in the Federated Internet Registry
                         Service", draft-ietf-crisp-firs-ipv4-02, July draft-ietf-crisp-firs-ipv4-03,
                         August 2003.

          [FIRS-IPV6]   Hall, E. "Defining and Locating IPv6 Address
                         Blocks in the Federated Internet Registry
                         Service", draft-ietf-crisp-firs-ipv6-02, July draft-ietf-crisp-firs-ipv6-03,
                         August 2003.

          [US-ASCII]    Cerf, V. "ASCII format for Network
                         Interchange", RFC 20, October 1969.

  9.      Changes from Previous Versions

     draft-ietf-crisp-firs-arch-02:

     draft-ietf-crisp-firs-core-03:

        *   Several clarifications and corrections have been made.

  Hall                   I-D Expires: March 2004             [page 44] 
        *   Added a discussion on attribute references.

        *   Added a discussion on referral source entry names.

        *   Clarified the rules for LDAP referral URLs.

        *   Temporarily removed the examples for referral processing,
            pending additional clarification text.

        *   Renamed the firsVersion control to inetResourcesControl and
            redefined its usage slightly.

        *   Renamed inetPrivateIdentifier to inetLocalIdentifier

        *   Added the inetExtAcl attribute option family, and defined
            the inetExtAcl client control.

     draft-ietf-crisp-firs-core-02:

        *   Several clarifications and corrections have been made.

        *   Changed the referral requirements so that servers are
            allowed to provide non-LDAP URLs but that FIRS clients are
            required to ignore non-LDAP URLs. This synchronizes
            referral mechanisms in the back-end data-stores, and moves
            the narrower requirement to the client.

        *   Added an inetPrivateIdentifier attribute for storing
            operator-specific labels (E.G., legacy NIC handles).

        *   Added the firsVersion server control (described in section
            5.3.1), control, which provides a
            limited amount of version- and feature-negotiation support
            to FIRS.

        *   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                  I-D Expires: February 2004            [page 38]

     draft-ietf-crisp-firs-core-01:

        *   Several clarifications and corrections have been made.

        *   Significant portions of text were moved to [FIRS-ARCH].

  Hall                   I-D Expires: March 2004             [page 45] 
     draft-ietf-crisp-firs-core-00:

        *   Restructured document set, separating the architectural
            discussion from the technical descriptions. Several
            sections were relocated to [FIRS-ARCH] as a result of this
            change.

        *   "Attribute references" have been eliminated from the
            specification. All referential attributes now provide
            actual data instead of URL pointers to data. Clients that
            wish to retrieve these values will need to start new
            queries using the data values instead of URLs.

        *   The various modified* operational attributes in the core
            schema have been eliminated as unnecessary.

        *   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.

     draft-ietf-crisp-lw-core-00:

        *   As a result of the formation of the CRISP working group,
            the original monolithic document has been broken into
            multiple documents, with draft-ietf-crisp-lw-core
            describing the core service, while related documents
            describe the per-resource schema and access mechanisms.

        *   References to the ldaps: URL scheme have been removed,
            since there is no standards-track specification for the
            ldaps: scheme.

        *   An acknowledgements section was added.

     draft-hall-ldap-whois-01:

        *   The "Objectives" section has been removed. [ir-dir-req] is
            now being used as the guiding document for this service.

  Hall                  I-D Expires: February 2004            [page 39]

        *   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.

  Hall                   I-D Expires: March 2004             [page 46] 
        *   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,
            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.

  10.     Author's Address

     Eric A. Hall
     ehall@ehsco.com

  Hall                  I-D Expires: February 2004            [page 40]

  11.     Acknowledgments

     Funding for the RFC editor function is currently provided by the
     Internet Society.

     Portions of this document were funded by VeriSign Labs.

     The first version of this specification was co-authored by Andrew
     Newton of VeriSign Labs, and subsequent versions continue to be

  Hall                   I-D Expires: March 2004             [page 47] 
     developed with his active participation. Edward Lewis and Peter
     Gietz also contributed significant feedback to this specification
     in the later stages of its developments.

  12.     Full Copyright Statement

     Copyright (C) The Internet Society (2003). All Rights Reserved.

     This document and translations of it may be copied and furnished
     to others, and derivative works that comment on or otherwise
     explain it or assist in its implementation may be prepared,
     copied, published and distributed, in whole or in part, without
     restriction of any kind, provided that the above copyright notice
     and this paragraph are included on all such copies and derivative
     works. However, this document itself may not be modified in any
     way, such as by removing the copyright notice or references to the
     Internet Society or other Internet organizations, except as needed
     for the purpose of developing Internet standards in which case the
     procedures for copyrights defined in the Internet Standards
     process must be followed, or as required to translate it into
     languages other than English.

     The limited permissions granted above are perpetual and will not
     be revoked by the Internet Society or its successors or assigns.

     This document and the information contained herein is provided on
     an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
     ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
     IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
     THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
     WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

  Hall                   I-D Expires: February March 2004             [page 41] 48]