draft-ietf-crisp-firs-core-00.txt   draft-ietf-crisp-firs-core-01.txt 
INTERNET-DRAFT Eric A. Hall INTERNET-DRAFT Eric A. Hall
Document: draft-ietf-crisp-firs-core-00.txt May 2003 Document: draft-ietf-crisp-firs-core-01.txt May 2003
Expires: December, 2003 Expires: December, 2003
Category: Standards-Track Category: Standards-Track
The Federated Internet Registry Service: The Federated Internet Registry Service:
Core Elements Core Elements
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
skipping to change at line 45 skipping to change at line 45
Abstract Abstract
This document describes the core technical elements of the This document describes the core technical elements of the
Federated Internet Registry Service (FIRS), a distributed service Federated Internet Registry Service (FIRS), a distributed service
for storing, locating and transferring information about Internet for storing, locating and transferring information about Internet
resources using LDAPv3. resources using LDAPv3.
Table of Contents Table of Contents
1. Introduction..............................................3 1. Introduction...............................................3
2. Prerequisites and Terminology.............................3 2. Prerequisites and Terminology..............................3
3. The FIRS Namespace........................................4 3. The FIRS Namespace.........................................4
3.1. The domainComponent (dc=) Namespace Component..........4 3.1. The domainComponent (dc=) Namespace Component...........4
3.2. The inetResources Namespace Component..................5 3.2. The inetResources Namespace Component...................5
3.3. The Resource-Specific Namespace Component..............6 3.3. The Resource-Specific Namespace Component...............5
3.4. Referrals..............................................6 3.4. Referrals...............................................6
3.4.1. Subordinate reference referrals..................9 3.4.1. Subordinate reference referrals...................8
3.4.2. Continuation reference referrals.................9 3.4.2. Continuation reference referrals..................9
3.5. Partition Replicas....................................10 4. Global FIRS Object Classes and Attributes..................9
4. Global FIRS Object Classes and Attributes................11 4.1. The inetResources Object Class..........................9
4.1. The inetResources Object Class........................11 4.1.1. Naming syntax.....................................9
4.1.1. Naming syntax...................................11 4.1.2. Schema definition................................10
4.1.2. Schema definition...............................11 4.1.3. Example..........................................12
4.1.3. Example.........................................14 4.2. The inetAssociatedResources Object Class...............12
4.2. The inetAssociatedResources Object Class..............15 4.2.1. Naming syntax....................................13
4.2.1. Naming syntax...................................15 4.2.2. Schema definition................................13
4.2.2. Schema definition...............................16 4.2.3. Example..........................................14
4.2.3. Example.........................................17 4.3. The referral Object Class..............................15
4.3. The referral Object Class.............................18 5. Global Query Processing Rules.............................15
5. Global Query Processing Rules............................18 5.1. Query Pre-Processing...................................16
5.1. Query Pre-Processing..................................19 5.2. Query Bootstrap Models.................................18
5.2. Query Bootstrap Models................................20 5.2.1. Targeted query processing........................18
5.2.1. Targeted Query Processing.......................21 5.2.2. Top-down processing..............................19
5.2.2. Top-Down Processing.............................22 5.2.3. Bottom-up processing.............................22
5.2.3. Bottom-Up Processing............................25 5.2.4. SRV processing...................................25
5.2.4. SRV processing..................................28 5.3. Query Processing.......................................26
5.3. Query Processing......................................29 5.3.1. Matching filters.................................26
5.3.1. Search Filters..................................29 5.3.2. Query-volume restrictions........................28
5.3.2. Authentication and access controls..............31 5.3.3. Authentication restrictions......................29
5.3.3. Protocol and schema version controls............32 5.3.4. Protocol and schema version controls.............29
5.4. Post-Query Processing.................................32 5.4. Referral Processing....................................30
6. Security Considerations..................................35 6. Security Considerations...................................33
7. IANA Considerations......................................35 7. IANA Considerations.......................................33
8. Author's Addresses.......................................35 8. Author's Addresses........................................34
9. Normative References.....................................35 9. Normative References......................................34
10. Acknowledgments..........................................37 10. Acknowledgments...........................................36
11. Changes from Previous Versions...........................37 11. Changes from Previous Versions............................36
12. Full Copyright Statement.................................39 12. Full Copyright Statement..................................38
Hall I-D Expires: December 2003 [page 2] Hall I-D Expires: December 2003 [page 2]
1. Introduction 1. Introduction
This specification defines the core object classes, attributes, This specification defines the core object classes, attributes,
syntax rules, extensibleMatch filters, and operational behaviors syntax rules, matching filters, and operational behaviors for the
for the FIRS service as a whole. Refer to [FIRS-ARCH] for FIRS service as a whole. Refer to [FIRS-ARCH] for information on
information on the FIRS architecture, and the resource-specific the FIRS architecture, and the resource-specific specifications
specifications for definitions and rules which govern each of the for definitions and rules which govern each of the different
different resource-types. resource-types.
The definitions in this specification are intended to be used with The definitions in this specification are intended to be used with
FIRS. Their usage outside of FIRS is not prohibited, but any such FIRS. Their usage outside of FIRS is not prohibited, but any such
usage is beyond this specification's scope of authority. usage is beyond this specification's scope of authority.
2. Prerequisites and Terminology 2. Prerequisites and Terminology
The complete set of specifications in the FIRS collection The complete set of specifications in the FIRS collection
cumulative define a structured and distributed information service cumulative define a structured and distributed information service
using LDAPv3 for the data-formatting and transport functions. This using LDAPv3 for the data-formatting and transport functions. This
specification should be read in the context of the complete set of specification should be read in the context of the complete set of
specifications, which currently include the following: specifications, which currently include the following:
draft-ietf-crisp-firs-arch-00, "The Federated Internet draft-ietf-crisp-firs-arch-01, "The Federated Internet
Registry Service: Architecture and Implementation" Registry Service: Architecture and Implementation"
[FIRS-ARCH] [FIRS-ARCH]
draft-ietf-crisp-firs-core-00, "The Federated Internet draft-ietf-crisp-firs-core-01, "The Federated Internet
Registry Service: Core Elements" (this document) Registry Service: Core Elements" (this document)
[FIRS-CORE] [FIRS-CORE]
draft-ietf-crisp-firs-dns-00, "Defining and Locating DNS draft-ietf-crisp-firs-dns-01, "Defining and Locating DNS
Domains in the Federated Internet Registry Service" Domains in the Federated Internet Registry Service"
[FIRS-DNS] [FIRS-DNS]
draft-ietf-crisp-firs-dnsrr-00, "Defining and Locating DNS draft-ietf-crisp-firs-dnsrr-01, "Defining and Locating DNS
Resource Records in the Federated Internet Registry Resource Records in the Federated Internet Registry
Service" [FIRS-DNSRR] Service" [FIRS-DNSRR]
draft-ietf-crisp-firs-contact-00, "Defining and Locating draft-ietf-crisp-firs-contact-01, "Defining and Locating
Contact Persons in the Federated Internet Registry Service" Contact Persons in the Federated Internet Registry Service"
[FIRS-CONTCT] [FIRS-CONTCT]
draft-ietf-crisp-firs-asn-00, "Defining and Locating draft-ietf-crisp-firs-asn-01, "Defining and Locating
Autonomous System Numbers in the Federated Internet Autonomous System Numbers in the Federated Internet
Registry Service" [FIRS-ASN] Registry Service" [FIRS-ASN]
Hall I-D Expires: December 2003 [page 3] Hall I-D Expires: December 2003 [page 3]
draft-ietf-crisp-firs-ipv4-00, "Defining and Locating IPv4 draft-ietf-crisp-firs-ipv4-01, "Defining and Locating IPv4
Address Blocks in the Federated Internet Registry Service" Address Blocks in the Federated Internet Registry Service"
[FIRS-IPV4] [FIRS-IPV4]
draft-ietf-crisp-firs-ipv6-00, "Defining and Locating IPv6 draft-ietf-crisp-firs-ipv6-01, "Defining and Locating IPv6
Address Blocks in the Federated Internet Registry Service" Address Blocks in the Federated Internet Registry Service"
[FIRS-IPV6] [FIRS-IPV6]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119. in this document are to be interpreted as described in RFC 2119.
3. The FIRS Namespace 3. The FIRS Namespace
The FIRS namespace acts as an index to the federated partition The FIRS namespace acts as an index to the federated partition
structure of the globally-distributed database of FIRS servers. structure of the globally-distributed database of FIRS servers.
There are three major components to this namespace, which are: There are three major components to this namespace, which are:
* The domainComponent entries. Each partition of the globally * The domainComponent entries. Each partition of the globally
distributed FIRS directory database is represented by a distributed FIRS directory database is represented by a
sequence of domainComponent distinguished names. These sequence of domainComponent distinguished names. These
sequences effectively identify the root scope of authority sequences effectively identify the root scope of authority
for each partition in the global directory database. for each partition in the global directory database.
skipping to change at line 168 skipping to change at line 171
within the globally distributed directory database. within the globally distributed directory database.
* The resource-specific entries. Each of the resource- * The resource-specific entries. Each of the resource-
specific entries within the inetResources container entries specific entries within the inetResources container entries
have their own unique naming rules, as defined in the have their own unique naming rules, as defined in the
governing specifications for those resources. governing specifications for those resources.
These naming rules are discussed in more detail below. These naming rules are discussed in more detail below.
3.1. The domainComponent (dc=) Namespace Component 3.1. The domainComponent (dc=) Namespace Component
The global FIRS directory database is divided into administrative The global FIRS directory database is divided into administrative
partitions, each of which represent a scope-of-authority for a partitions, each of which represent a scope-of-authority for a
certain portion of the global database. The root of these certain portion of the global database. The root of each partition
partitions is formally defined as a sequence of domainComponent is represented by a sequence of domainComponent relative
relative distinguished names (RDNs), as defined in [RFC2247]. distinguished names (RDNs), as defined in RFC 2247 [RFC2247]. In
this model, the scope-of-authority for a FIRS partition is derived
Hall I-D Expires: December 2003 [page 4] Hall I-D Expires: December 2003 [page 4]
In this model, a sequence of domainComponent RDNs map to a from a domain name in the global DNS directory, meaning that
sequence of domain names in the global DNS hierarchy, with the whoever has authority over any particular domain name effectively
FIRS partitions mapping to the zones which are managed by the has authority over the related FIRS partition.
governing organization. As such, the DNS namespace delegations act
as FIRS partition delegation, providing natural scopes of
administrative control in the global FIRS namespace. Furthermore,
the SRV resource records associated with those DNS domains also
provide a useful mechanism for locating the authoritative LDAP
servers associated with any particular resource in the global FIRS
directory database.
Since the partition roots determine the scope of control over a
set of resources, partitions which overlap also have overlapping
scopes of control. For example, the "dc=com" and
"dc=example,dc=com" partitions can both provide information about
the "www.example.com" domain name resource. In order to reduce the
amount of ambiguity which is naturally present in this kind of
model, FIRS defines multiple bootstrapping models and also defines
the default model which should be used for any given resource. For
example, queries for centrally-delegated resources are supposed to
ask the top-level partition for information about those resources,
while queries for user-managed resources are supposed to ask the
leaf-node partition for information about those resources.
Note that the domainComponent attribute is restricted to seven-bit Note that the domainComponent attribute is restricted to seven-bit
character codes, and is therefore effectively limited to using character codes, and is therefore effectively limited to using
character codes from US-ASCII [US-ASCII]. Due to this limitation, character codes from US-ASCII [US-ASCII]. Due to this limitation,
internationalized domain names MUST be converted into their ASCII- internationalized domain names MUST be converted into their ASCII-
compatible forms using the "ToASCII" process defined in RFC 3490 compatible forms using the "ToASCII" process defined in RFC 3490
[RFC3490] before the domainComponent RDNs are stored in the [RFC3490] before the domainComponent RDNs are used in the
directory database, and before any searches which reference those directory database or LDAP messages.
partitions are formed.
3.2. The inetResources Namespace Component 3.2. The inetResources Namespace Component
The FIRS directory database is further separated from the
directory partition structure by the use of a well-known container
entry with the MANDATORY name of "cn=inetResources". Any entry
which is to be located and retrieved through FIRS MUST refer to
this container entry.
Note that these rules specifically apply to entries which are to The FIRS-specific directory entries are segregated from other
be locatable by FIRS clients. The entries themselves MAY use application-specific entries by the use of a container entry with
referrals to reference entries in other namespace locations if the MANDATORY name of "cn=inetResources". Any entry which is to be
this is necessary or desirable (see section 3.4), although it is located through FIRS MUST refer to this container entry.
Hall I-D Expires: December 2003 [page 5] Note that this rule specifically applies to entries which are to
important for administrators to recognize that those referral be located by FIRS clients. The entries themselves MAY be
targets will not be locatable through FIRS. 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 the referral targets will not
be locatable through FIRS.
3.3. The Resource-Specific Namespace Component 3.3. The Resource-Specific Namespace Component
Every resource-specific entry also has a RDN which identifies that Every resource-specific entry also has a RDN which identifies that
resource within the context of the inetResources container of any resource within the context of the inetResources container of any
given partition. Examples of these resource-specific entries can given partition. Examples of these resource-specific entries can
be seen in Figure 1 of [FIRS-ARCH], and include "cn=example.com" be seen in Figure 1 of [FIRS-ARCH], and include "cn=example.com"
which refers to the "example.com" DNS domain name resource, and which refers to the "example.com" DNS domain name resource, and
"cn=admins@example.com" which refers to the "admins@example.com" "cn=admins@example.com" which refers to the "admins@example.com"
contact resource. contact resource.
Each of the FIRS resource-types have their own specific naming Each of the FIRS resource-types have their own specific naming
rules which govern those resources. Refer to the resource-specific rules which govern those resources. Refer to the resource-specific
skipping to change at line 237 skipping to change at line 220
given partition. Examples of these resource-specific entries can given partition. Examples of these resource-specific entries can
be seen in Figure 1 of [FIRS-ARCH], and include "cn=example.com" be seen in Figure 1 of [FIRS-ARCH], and include "cn=example.com"
which refers to the "example.com" DNS domain name resource, and which refers to the "example.com" DNS domain name resource, and
"cn=admins@example.com" which refers to the "admins@example.com" "cn=admins@example.com" which refers to the "admins@example.com"
contact resource. contact resource.
Each of the FIRS resource-types have their own specific naming Each of the FIRS resource-types have their own specific naming
rules which govern those resources. Refer to the resource-specific rules which govern those resources. Refer to the resource-specific
specifications for information on those rules. specifications for information on those rules.
Note that these rules specifically apply to entries which are to Note that the rules specifically apply to entries which are to be
be locatable by FIRS clients. The entries themselves MAY use located by FIRS clients. The entries themselves MAY be referrals
referrals to reference entries in other namespace locations if which reference entries in other locations if this is necessary or
this is necessary or desirable (see section 3.4), although it is desirable (see section 3.4), although it is important for
important for administrators to recognize that those referral administrators to recognize that the referral targets will not be
targets will not be locatable through FIRS. locatable through FIRS.
Hall I-D Expires: December 2003 [page 5]
3.4. Referrals 3.4. Referrals
FIRS allows entries in the namespace to refer to other entries, as FIRS allows entries in the namespace to refer to other entries, as
necessary or desirable. This model allows certain entries to be necessary or desirable. This model allows certain entries to be
created as "placeholders" for other canonical entries which created as "placeholders" for other canonical entries which
contain the actual data. In turn, this allows organizations to contain the actual data.
collectively publish shared entries as discrete objects (such as
allowing a user's leaf-node directory partition to publish an
entry for an ISP's web server as if it were their own entry),
allows partitions to reuse common data, and provides numerous
other benefits.
FIRS allows two methods for generating and processing these FIRS allows two methods for generating and processing these
referrals: subordinate reference referrals, and continuation referrals: subordinate reference referrals, and continuation
reference referrals, both of which are defined in RFC 3296 reference referrals.
[RFC3296]. 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; any superior reference
referrals which are encountered as a part of this service are to
be treated as errors.
Hall I-D Expires: December 2003 [page 6] Subordinate reference referrals indicate that the search base in
Subordinate reference referrals indicate that the queried entry is the original query is an alias for some other entry, and that the
an alias for some other entry, and that the query has to be query has to be restarted with a new search base in order for the
restarted in order for the current operation to be completed. search operation to be processed. Meanwhile, continuation
Meanwhile, continuation references indicate that the search was reference referrals indicate that the search was successfully
successfully initiated and that some data has been found, but that initiated and that some data has been found, but that additional
additional queries are required for the original query to be queries for additional resources are required for the query to be
completely exhausted. completely exhausted.
Subordinate references and continuation references use the ref Subordinate and continuation reference referrals use the ref
attribute and referral object class defined in RFC 3296 [RFC3296]. attribute and referral object class defined in RFC 3296 [RFC3296].
Each of these mechanisms use LDAP URLs as defined in RFC 2255 Each of these mechanisms use LDAP URLs as defined in RFC 2255
[RFC2255], with additional FIRS-specific restrictions. [RFC2255] to carry referral data, with some additional FIRS-
specific restrictions.
Among these restrictions: Among these restrictions:
* Referral source entries MUST comply with all of the * Referral source entries MUST comply with all of the
applicable namespace and schema rules. applicable namespace and schema rules.
* Referral targets MUST use the domainComponent ("dc=") * Referral targets MUST use the domainComponent ("dc=")
naming syntax for their directory partitions. Although naming syntax for their directory partitions. Although
other naming syntaxes are implicitly allowed by [RFC3296], other naming syntaxes are implicitly allowed by [RFC3296],
those syntaxes are only guaranteed to be resolvable if they those syntaxes are only guaranteed to be resolvable if they
use domainComponent sequences. use domainComponent sequences.
* Referral targets are encouraged to reside in an * Referral targets are encouraged to reside in an
inetResources container entry, although this is not inetResources container entry, although this is not
required. For example, a general-purpose administrative required. For example, a general-purpose administrative
contact entry may need to refer to a user-specific contact contact entry may need to refer to a user-specific contact
entry in another container if this is necessary, and this entry in another container if this is necessary, and this
kind of usage is allowed. kind of usage is allowed.
Hall I-D Expires: December 2003 [page 6]
* Referral sources and targets MUST have the same resource- * Referral sources and targets MUST have the same resource-
specific object class defined (for example, the referral specific object class defined (for example, the referral
source and target for a DNS domain resource would both have source and target for a DNS domain resource would both have
the inetDnsDomain object class defined). This is a the inetDnsDomain object class defined). This is a
prerequisite for the proper handling of the search filters prerequisite for the proper handling of the search filters
specified in this document. specified in this document.
* Referral targets MAY exist as referrals to other entries, * Referral targets MAY exist as referrals to other entries,
but recursive referrals are discouraged. Clients MAY but recursive referrals are discouraged. Clients MAY
discontinue referral processing after a reasonable amount discontinue referral processing after a reasonable amount
of effort (eight referrals is a suggested default value). of effort (eight referrals is a suggested default value).
* The protocol identifier of a URL MUST specify the LDAP * The protocol identifier of a URL MUST specify the LDAP
service type. Although general-purpose LDAP referrals are service type. Although general-purpose LDAP referrals are
allowed to specify any kind of protocol, FIRS referrals are allowed to specify any kind of protocol, FIRS referrals are
Hall I-D Expires: December 2003 [page 7]
intended to be used for automated queries, and the use of intended to be used for automated queries, and the use of
other protocols is forbidden in the default case. other protocols is forbidden in the default case.
* URLs MAY specify host identifiers and port numbers, but * URLs MAY specify host identifiers and port numbers, but
none of these elements are required. none of these elements are required.
* The distinguished name element of an LDAP URL MUST specify
the search base of the referral target.
* If a matching filter and/or assertion value needs to be * If a matching filter and/or assertion value needs to be
specified, they MUST be specified in the filter element of specified in the referral, they MUST be specified in the
an LDAP URL. New matching filters and/or assertion values filter element of the referral's LDAP URL. Matching filters
MUST NOT be specified unless the referral source needs to and/or assertion values MUST NOT be specified unless the
explicitly refer to a specific target entry in a specific referral source needs to explicitly reference a specific
partition. This should only be necessary in those cases target entry in a specific partition. This should only be
where the referral target entry is a leaf-node with no necessary in those cases where the referral target entry
additional referrals, and where the target is substantially would not normally be located (most likely due to a
and significantly different from the referral source. radically different entry name).
* The attribute, scope and extension elements of LDAP URLs * The attribute, scope and extension elements of LDAP URLs
will be ignored by the client, and SHOULD NOT be provided. will be ignored by the client, and SHOULD NOT be provided.
* URLs MUST be provided and stored in a URL-safe format. For * URLs MUST use a URL-safe format. For example, the IPv4 and
example, the IPv4 and IPv6 network address syntaxes defined IPv6 network address syntaxes defined in this document make
in this document make use of the forward-slash ("/") use of the forward-slash ("/") character to indicate a
character to indicate a subnet prefix, and if this subnet prefix, and if this character needs to be provided
character needs to be provided in a URL, it must be in a URL, it must be provided in the escaped form ("%2F" in
provided in the escaped form ("%2F" in this example). this example). Similarly, some domain names and email
Furthermore, some of the matching rules described in this addresses contain UTF-8 character data, and some of those
document require that the URLs also be stored in this character codes will need to be escaped in order to be
format in order for the searches to succeed. passed as URL data.
* Implementations MUST NOT restrict URL values to verifiable * Implementations MUST NOT restrict URL values to verifiable
entries from local partitions. Implementations MAY validate entries from local partitions. Implementations MAY validate
Hall I-D Expires: December 2003 [page 7]
referral targets in URLs, but a lack of knowledge regarding referral targets in URLs, but a lack of knowledge regarding
a target MUST NOT be treated as sufficient cause to prevent a target MUST NOT be treated as sufficient cause to prevent
the referral target from being specified. the referral target from being specified.
Clients MAY implement additional support for non-LDAP URLs which The rules for processing referral URLs are given in section 5.4.
are provided in conflict with the requirements above. However,
clients MUST NOT violate any other mandates in this document while
doing so (in particular, clients MUST NOT break the query-
processing procedures defined in section 5.1 of this document).
Each of the supported redirection mechanisms are discussed in more 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; any superior reference
referrals which are encountered as a part of this service are to
be treated as errors.
Each of the supported referral mechanisms are discussed in more
detail below. detail below.
Hall I-D Expires: December 2003 [page 8]
3.4.1. Subordinate reference referrals 3.4.1. Subordinate reference referrals
Subordinate reference referrals are returned when the search base
specified in a query exists as a referral to some other entry. Subordinate reference referrals are defined in [RFC3296], and are
This means that the entire query MUST be restarted, using the returned whenever the search base specified in a query exists as a
referral target as the new search base. referral to some other entry. This means that the query MUST be
restarted, using the referral target as the new search base.
Any entries MAY be defined as subordinate reference referrals Any entries MAY be defined as subordinate reference referrals
which point to other entries. However, almost all of the search which point to other entries. However, almost all of the search
functions defined for use by this service use the inetResources functions defined for use by this service use the inetResources
container entry as the search base (the exceptions to this rule container entry as the search base (the exceptions to this rule
are targeted searches for explicit entries), so subordinate are targeted searches for explicit entries), so subordinate
reference referrals will most commonly be seen when an reference referrals will most commonly be seen when an
inetResources container entry has been redirected to an inetResources container entry has been redirected to an
inetResources container in another directory branch. inetResources container in another directory partition.
Servers MUST support the use of subordinate reference referrals Servers MUST support the use of subordinate reference referrals
for this purpose, and clients MUST be prepared to accept and for this purpose, and clients MUST be prepared to accept and
process any subordinate reference referrals in answer sets. process any subordinate reference referrals in answer sets.
When subordinate reference referrals are used for this purpose, When subordinate reference referrals are used for this purpose,
the referral source MUST be defined with the referral object the referral source MUST be defined with the referral object
class, and MUST also be defined with the appropriate object class class, and MUST also be defined with the appropriate object class
for that resource type. For example, a "cn=inetResources" entry for that resource type. For example, a "cn=inetResources" entry
which provided a subordinate reference referral would need to have which provided a subordinate reference referral would need to have
both the referral and inetResources object classes defined, while both the referral and inetResources object classes defined, while
a DNS domain resource such as "dc=example.com" would need to have a DNS domain resource such as "dc=example.com" would need to have
both the referral and inetDnsDomain object classes defined (among both the referral and inetDnsDomain object classes defined (among
the other object class definitions which were required for that the other object class definitions which were required for that
entry). Referral targets need to use whatever object classes are entry). Referral targets need to use whatever object classes are
Hall I-D Expires: December 2003 [page 8]
appropriate for the resource in question, and MAY also be appropriate for the resource in question, and MAY also be
referrals to other entries. referrals to other entries.
Client rules for processing subordinate reference referrals are
given in section 5.2.3.h.
3.4.2. Continuation reference referrals 3.4.2. Continuation reference referrals
Continuation reference referrals are returned when a search
operation has been successfully processed by the queried server,
but the answer data also includes referrals to other entries.
These referrals are often provided as supplemental data to an
answer set, although this is not required (a continuation
Hall I-D Expires: December 2003 [page 9] Continuation reference referrals are defined in RFC 2251
reference referral can be the only response, but it won't be the [RFC2251], and are returned when a search operation has been
only response in the common case). successfully processed but the answer data also includes referrals
to other entries. These referrals are often provided as
supplemental data to an answer set, although this is not required
(a continuation reference referral can be the only response, but
it won't be the only response in the common case).
Servers MUST support the use of continuation reference referrals Servers MUST support the use of continuation reference referrals
for this purpose, and clients MUST be prepared to accept and for this purpose, and clients MUST be prepared to accept and
process any subordinate reference referrals in answer sets. process any subordinate reference referrals in answer sets.
When continuation reference referrals are used for this purpose, When continuation reference referrals are used for this purpose,
entries MAY exist for the queried resource, but one or more entries MAY exist for the queried resource, but one or more
entries MUST exist with the referral object class defined, and entries MUST exist with the referral object class defined, and
which provide LDAP URLs that point to other entries which have which provide LDAP URLs that point to other entries which have
additional information about the resource in question. additional information about the resource in question.
Continuation reference referrals are returned in response to
specific extensible match queries, and have specific naming
requirements which are necessary for the matching functions to
work properly. These considerations are described in Error!
Reference source not found..
Client rules for processing continuation reference referrals are
also given in section Error! Reference source not found..
3.5. Partition Replicas
All directory partitions which provide data for global Internet
resources SHOULD be replicated across two or more servers. Each of
the authoritative LDAP servers for the managed resource MUST be
specified with a unique DNS SRV resource record for the domain
name associated with the top-level resource assignment space.
Directory partitions which serve multiple organizations SHOULD
also be replicated. For example, an ISP which provides FIRS
services for their customers SHOULD also follow these same rules,
since outages of those servers will affect multiple parties. Leaf-
node directory partitions associated with an user-managed resource
MAY be replicated, and are encouraged to do so.
Similarly, any referrals which present URLs as answer data SHOULD
provide multiple URLs, each of which reference different hosts on
different networks. For leaf-node referrals, attribute references,
and labeledURI references, this behavior MAY be relaxed, although
it is still encouraged.
Note that the most effective replication strategy will be for
entities to replicate their directory partitions with the
delegation parents, as this will allow queries for those resources
Hall I-D Expires: December 2003 [page 10]
to be processed by the parent servers (thereby eliminating the
need for referral queries). In many cases, this will not be
feasible (the servers for the "dc=com" directory partition cannot
be expected to host replicas of every subordinate directory
partition), but it is encouraged where practical.
It is also expected that certain servers will be configured to
serve as multi-replica masters, effectively acting as large-scale
caching servers for many different resources. When used in
conjunction with the targeted bootstrap model described in section
5.2.1, this will allow clients to retrieve a significant amount of
information without having to pursue a large number of referrals
or redirects. This usage is expected and endorsed.
Finally, it is also important to note that neither this
specification nor the LDAP protocol currently provide cache timers
or any other mechanisms which can indicate how accurate or timely
any replicas may be.
4. Global FIRS Object Classes and Attributes 4. Global FIRS Object Classes and Attributes
Each of the schema definitions provided in this document include Each of the schema definitions provided in this document include
attribute definitions, naming rules, and other definitions which attribute definitions, naming rules, and other definitions which
are designed to facilitate the consistent storage and retrieval of are designed to facilitate the consistent storage and retrieval of
information within the FIRS service. information within the FIRS service.
4.1. The inetResources Object Class 4.1. The inetResources Object Class
The inetResources object class is a structural object class which The inetResources object class is a structural object class which
defines the attributes associated with the "cn=inetResources" defines the attributes associated with the "cn=inetResources"
container entry, and which provides general information about the container entry, and which provides general information about the
network resources associated with the current directory partition. network resources associated with the current directory partition.
4.1.1. Naming syntax 4.1.1. Naming syntax
This document requires the presence of an entry named This document requires the presence of an entry named
"cn=inetResources" in the root of every directory partition which "cn=inetResources" in the root of every directory partition which
provides FIRS services. provides FIRS services.
Hall I-D Expires: December 2003 [page 9]
4.1.2. Schema definition 4.1.2. Schema definition
Every directory partition which provides public FIRS data MUST Every directory partition which provides public FIRS data MUST
have a "cn=inetResources" entry in the root of the directory have a "cn=inetResources" entry in the root of the directory
Hall I-D Expires: December 2003 [page 11]
partition. The inetResources entry MUST exist with the top and partition. The inetResources entry MUST exist with the top and
inetResources object classes defined. If the entry exists as a inetResources object classes defined. If the entry exists as a
referral source, the entry MUST also be defined with the referral referral source, the entry MUST also be defined with the referral
object class, in addition to the above requirements. object class, in addition to the above requirements.
The inetResources object class is a structural object class which The inetResources object class is a structural object class which
is subordinate to the top abstract class, and which MUST be is subordinate to the top abstract class, and which MUST be
treated as a container class capable of holding additional treated as a container class capable of holding additional
subordinate entries. The inetResources object class has one subordinate entries. The inetResources object class has one
mandatory attribute which is "cn" (the naming attribute), and also mandatory attribute which is "cn" (the naming attribute), and also
has several optional attributes. Each of the other object classes has several optional attributes. Each of the other object classes
defined by this document are subordinate to the inetResources defined for use with FIRS are subordinate to the inetResources
object class and inherit the attributes defined for the object class and inherit its attributes.
inetResources object class.
The inetResources object class is intended to provide summary
information about a collection of resources under the control of a
single organization or management body. Since this object class is
also inherited by the resource-specific object classes, these
attributes can be defined at each of the subordinate entries if a
global set of attribute values is undesirable or unfeasible.
Since multiple directory partitions can use subordinate reference
referrals to share a single common inetResources entry, it is
important for the data to be applicable to all of the entries
which refer to it. For example, it would be effective for a small
private company to use a shared set of inetResources attributes
for their DNS domain names and IP network blocks, but it would
probably be counter-productive for a global ISP to share contact
data across all of their hosted domains and routed networks. If
separate contacts are required for each resource, the contact data
should be specified within each entry, rather than being linked to
the inetResources entry.
The inetResources object class provides several multi-valued
contact-related attributes for a variety of well-known
administrative roles. This model allows the inetResources entry
and each of the subordinate managed resources to share a common
set of administrative roles, or to have unique roles for each
resource, as seen fit by the managing entity. Each of the contact-
related attributes use the inetContactSyntax syntax rules defined
in [FIRS-CONTACT] for their values.
The schema definition for the inetResources object class is as The schema definition for the inetResources object class is as
follows: follows:
Hall I-D Expires: December 2003 [page 12]
inetResources inetResources
( 1.3.6.1.4.1.7161.1.0.0 NAME 'inetResources' DESC 'The ( 1.3.6.1.4.1.7161.1.0.0 NAME 'inetResources' DESC 'The
inetResources container for the FIRS service' SUP top inetResources container for the FIRS service' SUP top
STRUCTURAL MUST cn MAY ( o $ ou $ description $ STRUCTURAL MUST cn MAY ( o $ ou $ description $
inetResourceComments $ businessCategory $ telephoneNumber $ inetResourceComments $ businessCategory $ telephoneNumber $
facsimileTelephoneNumber $ labeledURI $ facsimileTelephoneNumber $ labeledURI $
preferredDeliveryMethod $ physicalDeliveryOfficeName $ preferredDeliveryMethod $ physicalDeliveryOfficeName $
postOfficeBox $ postalAddress $ postalCode $ street $ l $ postOfficeBox $ postalAddress $ postalCode $ street $ l $
st $ c $ inetAbuseContacts $ inetGeneralContacts $ st $ c $ inetAbuseContacts $ inetGeneralContacts $
inetSecurityContacts $ inetTechContacts $ inetSecurityContacts $ inetTechContacts $
skipping to change at line 562 skipping to change at line 456
below: below:
businessCategory, see RFC 2256 [RFC2256], section 5.16 businessCategory, see RFC 2256 [RFC2256], section 5.16
c (country), see [RFC2256], section 5.7 c (country), see [RFC2256], section 5.7
cn (commonName), see [RFC2256], section 5.4 cn (commonName), see [RFC2256], section 5.4
description, see [RFC2256], section 5.14 description, see [RFC2256], section 5.14
Hall I-D Expires: December 2003 [page 10]
facsimileTelephoneNumber, see [RFC2256], section 5.24 facsimileTelephoneNumber, see [RFC2256], section 5.24
inetAbuseContacts inetAbuseContacts
( 1.3.6.1.4.1.7161.1.0.2 NAME 'inetAbuseContacts' DESC ( 1.3.6.1.4.1.7161.1.0.2 NAME 'inetAbuseContacts' DESC
'Contacts for reporting abusive behavior or acceptable-use 'Contacts for reporting abusive behavior or acceptable-use
policy violations.' EQUALITY caseIgnoreMatch SYNTAX policy violations.' EQUALITY caseIgnoreMatch SYNTAX
inetContactSyntax ) inetContactSyntax )
inetGeneralContacts inetGeneralContacts
( 1.3.6.1.4.1.7161.1.0.3 NAME 'inetGeneralContacts' DESC ( 1.3.6.1.4.1.7161.1.0.3 NAME 'inetGeneralContacts' DESC
skipping to change at line 585 skipping to change at line 480
inetGeneralDisclaimer inetGeneralDisclaimer
( 1.3.6.1.4.1.7161.1.0.4 NAME 'inetResourceComments' DESC ( 1.3.6.1.4.1.7161.1.0.4 NAME 'inetResourceComments' DESC
'General disclaimer text regarding this data' EQUALITY 'General disclaimer text regarding this data' EQUALITY
caseIgnoreMatch SYNTAX DirectoryString{1024} ) caseIgnoreMatch SYNTAX DirectoryString{1024} )
inetResourceComments inetResourceComments
( 1.3.6.1.4.1.7161.1.0.5 NAME 'inetResourceComments' DESC ( 1.3.6.1.4.1.7161.1.0.5 NAME 'inetResourceComments' DESC
'General comments about this entry' EQUALITY 'General comments about this entry' EQUALITY
caseIgnoreMatch SYNTAX DirectoryString{1024} ) caseIgnoreMatch SYNTAX DirectoryString{1024} )
Hall I-D Expires: December 2003 [page 13]
inetSecurityContacts inetSecurityContacts
( 1.3.6.1.4.1.7161.1.0.6 NAME 'inetSecurityContacts' DESC ( 1.3.6.1.4.1.7161.1.0.6 NAME 'inetSecurityContacts' DESC
'Contacts for general security issues.' EQUALITY 'Contacts for general security issues.' EQUALITY
caseIgnoreMatch SYNTAX inetContactSyntax ) caseIgnoreMatch SYNTAX inetContactSyntax )
inetTechContacts inetTechContacts
( 1.3.6.1.4.1.7161.1.0.7 NAME 'inetTechContacts' DESC ( 1.3.6.1.4.1.7161.1.0.7 NAME 'inetTechContacts' DESC
'Contacts for general technical issues.' EQUALITY 'Contacts for general technical issues.' EQUALITY
caseIgnoreMatch SYNTAX inetContactSyntax ) caseIgnoreMatch SYNTAX inetContactSyntax )
skipping to change at line 608 skipping to change at line 502
labeledURI, see RFC 2079 [RFC2079] labeledURI, see RFC 2079 [RFC2079]
o (organization), see [RFC2256], section 5.11 o (organization), see [RFC2256], section 5.11
ou (organizational unit), see [RFC2256], section 5.12 ou (organizational unit), see [RFC2256], section 5.12
physicalDeliveryOfficeName, see [RFC2256], section 5.20 physicalDeliveryOfficeName, see [RFC2256], section 5.20
postalAddress, see [RFC2256], section 5.17 postalAddress, see [RFC2256], section 5.17
Hall I-D Expires: December 2003 [page 11]
postalCode, see [RFC2256], section 5.18 postalCode, see [RFC2256], section 5.18
postOfficeBox, see [RFC2256], section 5.19 postOfficeBox, see [RFC2256], section 5.19
preferredDeliveryMethod, see [RFC2256], section 5.29 preferredDeliveryMethod, see [RFC2256], section 5.29
st (stateOrProvinceName), see [RFC2256], section 5.9 st (stateOrProvinceName), see [RFC2256], section 5.9
street (streetAddress), see [RFC2256], section 5.10 street (streetAddress), see [RFC2256], section 5.10
skipping to change at line 621 skipping to change at line 516
preferredDeliveryMethod, see [RFC2256], section 5.29 preferredDeliveryMethod, see [RFC2256], section 5.29
st (stateOrProvinceName), see [RFC2256], section 5.9 st (stateOrProvinceName), see [RFC2256], section 5.9
street (streetAddress), see [RFC2256], section 5.10 street (streetAddress), see [RFC2256], section 5.10
telephoneNumber, see [RFC2256], section 5.21 telephoneNumber, see [RFC2256], section 5.21
4.1.3. Example 4.1.3. Example
An example of the inetResources object class in use is shown in An example of the inetResources object class in use is shown in
Figure 1 below. Figure 1 below.
Hall I-D Expires: December 2003 [page 14]
cn=inetResources,dc=example,dc=com cn=inetResources,dc=example,dc=com
[top object class] [top object class]
[inetResources object class] [inetResources object class]
| |
+-attribute: o +-attribute: o
| value: "Example Widgets' network resources" | value: "Example Widgets' network resources"
| |
+-attribute: inetGeneralContacts +-attribute: inetGeneralContacts
| value: "admins@example.com" | value: "admins@example.com"
| |
skipping to change at line 645 skipping to change at line 540
+-attribute: telephoneNumber +-attribute: telephoneNumber
| value: "1-800-555-1212" | value: "1-800-555-1212"
| |
+-attribute: inetResourceComments +-attribute: inetResourceComments
value: "Please don't send complaints to the value: "Please don't send complaints to the
postmaster@example.com mailbox." postmaster@example.com mailbox."
Figure 1: The Example Widgets inetResources container entry. Figure 1: The Example Widgets inetResources container entry.
4.2. The inetAssociatedResources Object Class 4.2. The inetAssociatedResources Object Class
The inetAssociatedResources object class defines attributes which The inetAssociatedResources object class defines attributes which
are useful for cross-referencing entries with other resources. For are useful for cross-referencing entries with other resources. For
example, it allows inetOrgPerson entries to be associated with example, it allows inetOrgPerson entries to be associated with
IPv4 networks or DNS domains, providing generic cross-reference IPv4 networks or DNS domains, providing generic cross-reference
pointer attributes (this information may be useful if a single pointer attributes (this information may be useful if a single
organization has multiple DNS domains registered). In short, any organization has multiple DNS domains registered). In short, any
resource can be associated with any other resource through the use resource can be associated with any other resource through the use
of this object class. of this object class.
The inetAssociatedResources object class MUST NOT be associated Hall I-D Expires: December 2003 [page 12]
with an entry that only exists as a referral source.
4.2.1. Naming syntax 4.2.1. Naming syntax
The inetAssociatedResources object class is an auxiliary object The inetAssociatedResources object class is an auxiliary object
class, and not a structural object class. Entries which use this class, and not a structural object class. Entries which use this
object class definition are defined under the rules associated object class definition are defined under the rules associated
with the structural object class that defines the Internet with the structural object class that defines the Internet
resource in question. As such, the naming rules associated with resource in question. As such, the naming rules associated with
that entry take precedence, and the inetAssociatedResources object that entry take precedence, and the inetAssociatedResources object
class does not define an independent naming syntax. class does not define an independent naming syntax.
Hall I-D Expires: December 2003 [page 15]
4.2.2. Schema definition 4.2.2. Schema definition
The inetAssociatedResources object class is an auxiliary object The inetAssociatedResources object class is an auxiliary object
class which is subordinate to the top object class. The class which is subordinate to the top object class. The
inetAssociatedResources object class has no mandatory attributes, inetAssociatedResources object class has no mandatory attributes,
and only has optional attributes. and only has optional attributes.
Although the inetAssociatedResources object class is subordinate Although the inetAssociatedResources object class is subordinate
to the top object class, it is intended to be used with the to the top object class, it is intended to be used with the
resource-specific structural object classes defined for use with resource-specific structural object classes defined for use with
FIRS. The inetAssociatedResources object class is not likely to FIRS. The inetAssociatedResources object class is not likely to
provide much value when it is associated with the inetResources provide much value when it is associated with the inetResources
skipping to change at line 686 skipping to change at line 581
FIRS. The inetAssociatedResources object class is not likely to FIRS. The inetAssociatedResources object class is not likely to
provide much value when it is associated with the inetResources provide much value when it is associated with the inetResources
object class, since the inetResources object class does not object class, since the inetResources object class does not
specifically define any resources (and since it does not define specifically define any resources (and since it does not define
resources, it cannot define any associated resources). On the resources, it cannot define any associated resources). On the
other hand, it is reasonable for the inetAssociatedResources other hand, it is reasonable for the inetAssociatedResources
object class to be associated with an inetOrgPerson object class object class to be associated with an inetOrgPerson object class
entry, particularly if the referenced person (or role) is entry, particularly if the referenced person (or role) is
responsible for the management of multiple resources. 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 Each of the associated resource attributes provide multi-valued
data, using the syntax notations which are specific to the data, using the syntax notations which are specific to the
resource in question. For example, the inetAssociatedDnsDomain resource in question. For example, the inetAssociatedDnsDomain
attribute provides multiple associated DNS domain name resources attribute provides multiple associated DNS domain name resources
using a multi-valued array, with each domain name using the using a multi-valued array, with each domain name using the
inetDnsDomainSyntax naming rules defined in [FIRS-DNS]. inetDnsDomainSyntax naming rules defined in [FIRS-DNS].
The schema definition for the inetAssociatedResources object class The schema definition for the inetAssociatedResources object class
is as follows: is as follows:
Hall I-D Expires: December 2003 [page 13]
inetAssociatedResources inetAssociatedResources
( 1.3.6.1.4.1.7161.1.5.0 NAME 'inetAssociatedResources' DESC ( 1.3.6.1.4.1.7161.1.5.0 NAME 'inetAssociatedResources' DESC
'Internet resources associated with this resource.' SUP top 'Internet resources associated with this resource.' SUP top
AUXILIARY MAY ( inetAssociatedContacts $ AUXILIARY MAY ( inetAssociatedContacts $
inetAssociatedDnsDomains $ inetAssociatedIpv4Networks $ inetAssociatedDnsDomains $ inetAssociatedIpv4Networks $
inetAssociatedIpv6Networks $ inetAssociatedAsNumbers ) ) inetAssociatedIpv6Networks $ inetAssociatedAsNumbers ) )
The attributes from the inetAssociatedResources object class are The attributes from the inetAssociatedResources object class are
described below: described below:
inetAssociatedAsNumbers inetAssociatedAsNumbers
( 1.3.6.1.4.1.7161.1.5.2 NAME 'inetAssociatedAsNumbers' DESC ( 1.3.6.1.4.1.7161.1.5.2 NAME 'inetAssociatedAsNumbers' DESC
'Autonomous system numbers associated with this Internet 'Autonomous system numbers associated with this Internet
resource.' EQUALITY caseIgnoreMatch SYNTAX resource.' EQUALITY caseIgnoreMatch SYNTAX
inetAsNumberSyntax ) inetAsNumberSyntax )
Hall I-D Expires: December 2003 [page 16]
inetAssociatedContacts inetAssociatedContacts
( 1.3.6.1.4.1.7161.1.5.3 NAME 'inetAssociatedContacts' DESC ( 1.3.6.1.4.1.7161.1.5.3 NAME 'inetAssociatedContacts' DESC
'Other contacts associated with this Internet resource.' 'Other contacts associated with this Internet resource.'
EQUALITY caseIgnoreMatch SYNTAX inetContactSyntax ) EQUALITY caseIgnoreMatch SYNTAX inetContactSyntax )
inetAssociatedDnsDomains inetAssociatedDnsDomains
( 1.3.6.1.4.1.7161.1.5.4 NAME 'inetAssociatedDnsDomains' DESC ( 1.3.6.1.4.1.7161.1.5.4 NAME 'inetAssociatedDnsDomains' DESC
'DNS domains associated with this Internet resource.' 'DNS domains associated with this Internet resource.'
EQUALITY caseIgnoreMatch SYNTAX inetDnsDomainSyntax ) EQUALITY caseIgnoreMatch SYNTAX inetDnsDomainSyntax )
skipping to change at line 735 skipping to change at line 633
DESC 'IPv4 networks associated with this Internet DESC 'IPv4 networks associated with this Internet
resource.' EQUALITY caseIgnoreMatch SYNTAX resource.' EQUALITY caseIgnoreMatch SYNTAX
inetIpv4NetworkSyntax ) inetIpv4NetworkSyntax )
inetAssociatedIpv6Networks inetAssociatedIpv6Networks
( 1.3.6.1.4.1.7161.1.5.6 NAME 'inetAssociatedIpv6Networks' ( 1.3.6.1.4.1.7161.1.5.6 NAME 'inetAssociatedIpv6Networks'
DESC 'IPv6 networks associated with this entry.' EQUALITY DESC 'IPv6 networks associated with this entry.' EQUALITY
caseIgnoreMatch SYNTAX inetIpv6NetworkSyntax ) caseIgnoreMatch SYNTAX inetIpv6NetworkSyntax )
4.2.3. Example 4.2.3. Example
An example of the inetAssociatedResources object class is shown in An example of the inetAssociatedResources object class is shown in
Figure 2 below. Figure 2 below.
Hall I-D Expires: December 2003 [page 14]
cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com
[top object class] [top object class]
[inetResources object class] [inetResources object class]
[inetIpv4Network object class] [inetIpv4Network object class]
[inetAssociatedResources object class] [inetAssociatedResources object class]
| |
+-attribute: description +-attribute: description
| value: "The example.com network" | value: "The Example Widgets network"
| |
+-attribute: inetAssociatedAsNumbers +-attribute: inetAssociatedAsNumbers
| value: "65535" | value: "65535"
| |
+-attribute: inetAssociatedDnsDomains +-attribute: inetAssociatedDnsDomains
value: "example.com" value: "2.0.192.in-addr.arpa"
Figure 2: The inetAssociatedResources attributes associated with Figure 2: The inetAssociatedResources attributes associated with
the 192.0.2.0/24 IPv4 network entry. the 192.0.2.0/24 IPv4 network entry.
Hall I-D Expires: December 2003 [page 17]
4.3. The referral Object Class 4.3. The referral Object Class
This document allows the inetResources container entries and the
subordinate resource-specific entries to use the referral object Entries use the referral object class to define subordinate
class to define subordinate reference referrals and continuation reference referrals and continuation reference referrals, thereby
reference referrals. facilitating the programmatic redirection of queries in support of
the referral mechanisms defined in section 3.4.
Referral entries MUST conform to the schema specification defined Referral entries MUST conform to the schema specification defined
in [RFC3296]. In particular, referral entries MUST NOT contain any in [RFC3296].
user-definable attributes (other than the mandatory naming
attribute). Referral entries MUST be leaf nodes, and MUST NOT have
any subordinate entries defined at the referral source.
In order to facilitate programmatic access to this data, LDAP URLs Referral sources MUST NOT contain any user-definable attributes
provided in ref attributes MUST refer to entries which use the (other than the mandatory naming attribute), and MUST NOT have any
same object classes as the source entry, MUST refer to an entry in subordinate child entries.
a directory partition which uses the domainComponent object class
syntax ("dc="), and MUST specify the LDAP protocol-type.
Refer to section 3.4 for more information on the use of referrals Refer to section 3.4 for the rules that govern referral URLs in
in FIRS. FIRS. Refer to section 5.4 for information on processing referral
URLs in FIRS.
5. Global Query Processing Rules 5. Global Query Processing Rules
Another critical aspect to FIRS is the query-processing behavior. Another critical aspect to FIRS is the query-processing behavior.
These rules govern the ways in which a client parses a query, These rules govern the ways in which a client parses a query,
locates a server which is authoritative for the resource being locates a server which is authoritative for the resource being
queried, generates LDAPv3 queries, and processes any resulting queried, generates LDAPv3 queries, and processes any resulting
referrals. More specifically: referrals. More specifically:
* Query pre-processing. The first step is for the client to * Query pre-processing. The first step is for the client to
prepare the query. Portions of this process require the prepare the query. Portions of this process require the
Hall I-D Expires: December 2003 [page 15]
client to determine the type of resource being queried for, client to determine the type of resource being queried for,
and to determine the initial partition which should be used and to determine the initial partition which should be used
for the query. Since this process is different for each for the query. Since this process is different for each
particular resource-type, the rules which govern this particular resource-type, the rules which govern this
behavior are defined in each of the resource-specific behavior are defined in each of the resource-specific
specifications. specifications.
* Bootstrap processing. Once a partition has been determined, * Bootstrap processing. Once a partition has been determined,
the client must locate the LDAP servers which are the client must locate the LDAP servers which are
authoritative for the resource in question. Section 5.2 authoritative for the resource in question. Section 0
defines three different bootstrap models that clients can defines three different bootstrap models that clients can
use as part of this process, while each of the resource- use as part of this process, while each of the resource-
specific specifications define which of the models are to specific specifications define which of the models are to
be used for each particular resource-type. be used for each particular resource-type.
Hall I-D Expires: December 2003 [page 18]
* Query processing. Once a server has been located, the * Query processing. Once a server has been located, the
client must submit the LDAP query which was formed during client must submit the LDAP query which was formed during
the pre-preprocessing phase. Section 5.3 defines the global the pre-preprocessing phase. Section 5.3 defines the global
considerations for all FIRS queries, while the resource- considerations for all FIRS queries, while the resource-
specific specifications also define additional parameters. specific specifications also define additional parameters.
* Query post-processing. FIRS explicitly supports different * Query post-processing. FIRS explicitly supports different
types of LDAP referral mechanisms, any of which may result types of LDAP referral mechanisms, any of which may result
in the client application restarting the query or in the client application restarting the query or
initiating a brand-new query. These mechanisms and their initiating a brand-new query. These mechanisms and their
behavioral rules are defined in section 5.4. behavioral rules are defined in section 5.4.
Each of these phases are discussed in more detail below. Each of these phases are discussed in more detail below.
5.1. Query Pre-Processing 5.1. Query Pre-Processing
Client input is generally provided as a single well-formed unit of
Client input is generally limited to a single well-formed unit of
data, such as a domain name ("example.com") or an email address data, such as a domain name ("example.com") or an email address
("admins@example.com"). Since this information is typically all ("admins@example.com"), and this single piece of information must
that's provided, it must be used to subsequently build a fully- be used to subsequently build a fully-formed LDAPv3 query,
formed LDAPv3 query, including the assertion value, the search including the assertion value, the search base, the matching
base, the matching filter, and so forth. All of these steps are filter, and so forth. All of these steps are part of the pre-
part of the pre-processing phase. processing phase.
Although the exact sequence of steps will vary according to the Although the exact sequence of steps will vary according to the
resource-type being queried, there are some commonalities between resource-type being queried, there are some commonalities between
each of them. Among these steps: each of them. Among these steps:
* Determine the resource type. Different kinds of resources * Determine the resource type. Different kinds of resources
have different processing steps, validation mechanisms, and have different processing steps, validation mechanisms, and
so forth, each of which require that the resource-type be so forth, each of which require that the resource-type be
Hall I-D Expires: December 2003 [page 16]
appropriately identified. Clients MAY use any mechanisms appropriately identified. Clients MAY use any mechanisms
necessary to force this determination. necessary to force this determination.
* Validate and normalize the data. In all cases, the input * Validate and normalize the data. In all cases, the input
data MUST be validated and normalized according to the data MUST be validated and normalized according to the
syntax rules defined in the specification which governs the syntax rules defined in the specification which governs the
resource-type. As an example of this step, queries for resource-type. As an example of this step, queries for
internationalized domain names must be normalized into a internationalized domain names must be validated and
UTF-8 form before any other steps can be taken, with the normalized into a canonical UTF-8 form before any other
domain name being validated as part of the normalization steps can be taken. Similarly, IPv6 addresses are required
process. Similarly, IPv6 addresses are required to conform to conform to specific syntax rules, and input address may
to specific syntax rules, and input address may need to be need to be expanded or compressed in order to comply with
expanded or compressed in order to comply these syntax the syntax requirements.
requirements.
Hall I-D Expires: December 2003 [page 19] * Determine the authoritative directory partition for the
* Determine the appropriate directory partition for the named resource. In most cases, the authoritative partition
query. Different kinds of resources have different default will be a variation of the input query string, but this is
choices. In most cases, the appropriate partition will be a not always the case. For example, the default partition for
variation of the input query string, but this is not always an email address will be extrapolated from the domain
the case. For example, the default partition for an email component of the email address itself, while the
address will be the domain component of the email address authoritative partition for an ASN uses a reserved
itself, while the default partition for an ASN is a (special-purpose) domain name. In some cases, the
reserved (special-purpose) domain name. In some cases, the authoritative partition may change during the subsequent
selected partition may change as a result of errors or query-processing steps.
referrals encountered during later phases of the process.
* Determine the search base for the query. In most cases, the * Determine the search base for the query. Each resource type
search base will refer to the inetResources container entry has resource-specific query-processing rules which will
within the partition which was determined in the prior dictate how the authoritative partitions are mapped to the
step, with these elements being combined into an FQDN. In search base. In some cases, the cn=inetResources container
some cases, the search base may need to be changed as a entry in the authoritative partition will be used "as-is",
result of referrals encountered during later phases of the while in other cases, the cn=inetResources container entry
process. in a delegation parent of the authoritative partition will
be used instead. In some cases, the search base may change
during subsequent query-processing steps.
* Determine the assertion value for the query. The assertion * Determine the assertion value for the query. The assertion
value will usually be the normalized form of the input value will usually be the normalized form of the input
query. In some cases, the assertion value may need to be query. In some cases, the assertion value may change during
changed as a result of referrals encountered during later subsequent query-processing steps.
phases of the process.
* Determine the matching filter. Each resource-type has its * Determine the matching filter. Each resource-type has its
own matching filter rules. In some cases, the matching own matching filter rules. For example, contact entries are
filter will be a simple equalityMatch comparison, while in matched with a simple equalityMatch comparison, while in
other cases the matching filter will be an extensibleMatch other cases the matching filter will be an extensibleMatch
which is peculiar to the resource-type in use. which is peculiar to the resource-type in use.
Hall I-D Expires: December 2003 [page 17]
Once all of the pre-processing steps have been successfully Once all of the pre-processing steps have been successfully
completed, the client must attempt to locate an LDAPv3 server completed, the client will have to locate an LDAPv3 server which
which is authoritative for that resource. This process is is authoritative for the search base before it can submit the
described in section 5.2 below. query. This process is described in section 5.2 below.
5.2. Query Bootstrap Models 5.2. Query Bootstrap Models
Once a client has determined which partition should be queried for Once a client has determined which partition should be queried for
the specified resource, the client must determine which LDAP the specified resource, the client must determine which LDAP
servers are authoritative for that partition. servers are authoritative for that partition.
The FIRS service supports three different bootstrap models for The FIRS service supports three different bootstrap models for
this process, although these models only differ in relatively this process, although these models only differ in relatively
minor ways. Once a server has been located, the rest of the query minor ways; once a server has been located, the rest of the query
process follows the same basic path (issuing the LDAPv3 query,
Hall I-D Expires: December 2003 [page 20] following referrals, and so forth).
process follows the same common path (issuing the LDAPv3 query,
following any referrals which may be returned, and so forth).
The three bootstrapping models defined for use with this service The three bootstrapping models defined for use with this service
are the "targeted " model which is functionally identical to are the "targeted " model which is functionally identical to
traditional lookups for LDAP servers, the "top-down" model which traditional lookups for LDAP servers, the "top-down" model which
causes a client to submit a query to the root of a delegation causes a client to submit a query to the root of a delegation
hierarchy, and a "bottom-up" model which causes a client to work hierarchy, and a "bottom-up" model which causes a client to work
up through a delegation hierarchy until a server has been located. up through a delegation hierarchy until a server has been located.
5.2.1. Targeted Query Processing 5.2.1. Targeted query processing
The "targeted" model is similar to the traditional model of LDAP The "targeted" model is similar to the traditional model of LDAP
lookups, in that a client queries a previously specified LDAP lookups, in that a client queries a previously specified LDAP
server for a particular resource under the assumption that the server for a particular resource under the assumption that the
resource exists on that server. If the server or resource does not resource exists on that server. If the server or resource does not
exist (notwithstanding any referrals which may be returned), the exist (notwithstanding any referrals which may be returned), the
entire query fails. entire query fails.
The targeted model can be used when a fixed resource has been The targeted model can be used when a fixed resource has been
specified (such as may occur with a URL), but can also be used if specified (such as may occur with a URL), but can also be used if
the client prefers to use a "default" server for all operations. the client prefers to use a "default" server for all operations.
skipping to change at line 927 skipping to change at line 828
servers, or other fixed servers, in lieu of navigating the global servers, or other fixed servers, in lieu of navigating the global
directory database with every query. In all of these cases, directory database with every query. In all of these cases,
however, failed lookups are considered to be fatal. however, failed lookups are considered to be fatal.
The steps for processing targeted queries are described below: The steps for processing targeted queries are described below:
a. Determine the IP address and port number to be used (this a. Determine the IP address and port number to be used (this
information may be determined from user input, a information may be determined from user input, a
configuration file, a URL, or from any other source). configuration file, a URL, or from any other source).
Hall I-D Expires: December 2003 [page 18]
1. If a non-ASCII domain name has been specified for this 1. If a non-ASCII domain name has been specified for this
purpose, convert the domain name into its ASCII- purpose, convert the domain name into its ASCII-
compatible form using the "ToASCII" process defined in compatible form using the "ToASCII" process defined in
[RFC3490] before performing any lookups. [RFC3490] before performing any lookups.
2. Locate the LDAP servers associated with the domain 2. Locate the LDAP servers associated with the domain
name through the SRV query steps provided in section name through the SRV query steps provided in section
5.2.4. If this step fails, use DNS lookups for A 5.2.4. If this step fails, use DNS lookups for A
resource records instead. If no resource records are resource records instead. If no resource records are
available, report the error to the user and exit. available, report the error to the user and exit.
b. Once a server has been determined, submit the search b. Once a server has been determined, submit the search
operation. If the search operation fails, report the error operation. If the search operation fails, report the error
Hall I-D Expires: December 2003 [page 21]
to the user and exit. Otherwise, display any answer data to the user and exit. Otherwise, display any answer data
which is returned. which is returned.
c. If the answer data contains a subordinate reference c. If the answer data contains a subordinate reference
referral or a continuation reference referral, new query referral or a continuation reference referral, new query
processes MUST be spawned. processes MUST be spawned.
For subordinate reference referrals, process the URLs For subordinate reference referrals, process the URLs
according to the rules described in section Error! according to the rules described in section 5.4 and restart
Reference source not found. and restart the query process the query process at step 5.2.1.a. For each continuation
at step 5.2.1.a. For each continuation reference referral, reference referral, display the answer data received so
display the answer data received so far, process the LDAP far, process the LDAP URLs according to the rules described
URLs according to the rules described in section Error! in section 5.4 and start new query processes for each
Reference source not found. and start new query processes referral at step 5.2.1.a, appending the output from these
for each referral at step 5.2.1.a, appending the output searches to the current output.
from these searches to the current output.
Any additional subordinate reference referrals or Any additional subordinate reference referrals or
continuation reference referrals which are encountered from continuation reference referrals which are encountered from
any subsequent searches will need to be processed in the any subsequent searches will need to be processed in the
same manner as specified above, until no additional same manner as specified above, until no additional
referrals are received. referrals are received.
d. Exit the query operation. d. Exit the query operation.
5.2.2. Top-Down Processing 5.2.2. Top-down processing
The top-down model uses an input string to construct an LDAP The top-down model uses an input string to construct an LDAP
assertion value and search base, with DNS queries being used to assertion value and search base, with DNS queries being used to
locate the LDAP servers associated with the appropriate top-level locate the LDAP servers associated with the appropriate top-level
delegation entity. Once this process completes, a query is issued delegation entity. Once this process completes, a query is issued
to the specified servers. This query may be subsequently to the specified servers. This query may be subsequently
redirected to other servers through the use of LDAP referrals. redirected to other servers through the use of LDAP referrals.
Hall I-D Expires: December 2003 [page 19]
The top-down model is primarily suited for locating Internet The top-down model is primarily suited for locating Internet
resources which are centrally managed and delegated, and where resources which are centrally managed and delegated, and where
information about the delegation is desired. In particular, this information about the delegation is desired. In particular, this
includes resources such as DNS domain names, IP address blocks, includes resources such as DNS domain names, IP address blocks,
and AS numbers. and AS numbers.
Note that the top-down model does not use incrementally larger Note that the top-down model does not use incrementally larger
domain names for the bootstrap process. Instead, it is assumed domain names for the bootstrap process. Instead, it is assumed
that the root partition in the delegation tree will be able to that the root partition in the delegation tree will be able to
provide any necessary redirection services. For example, if the provide any necessary redirection services. For example, if the
domain name of "www.example.co.uk" is used in a query, the query domain name of "www.example.co.uk" is used in a query, the query
will be sent to the "dc=uk" partition, which should provide a will be sent to the "dc=uk" partition, which should provide a
Hall I-D Expires: December 2003 [page 22]
referral for the "dc=co,dc=uk" partition, which in turn should referral for the "dc=co,dc=uk" partition, which in turn should
provide a referral for the "dc=example,dc=co,dc=uk" partition. provide a referral for the "dc=example,dc=co,dc=uk" partition.
The steps for processing top-down queries are described below: The steps for processing top-down queries are described below:
a. Determine the directory partition for the query. a. Determine the directory partition for the query.
1. Separate the input string into discrete elements where 1. Separate the input string into discrete elements where
this is possible. For a DNS domain name of this is possible. For a DNS domain name of
"www.example.com", this would be "www", "example" and "www.example.com", this would be "www", "example" and
skipping to change at line 1022 skipping to change at line 921
character), and append "ip6.arpa". For AS numbers, character), and append "ip6.arpa". For AS numbers,
append only the "arpa" domain name. append only the "arpa" domain name.
b. Form the LDAP search base for the query. b. Form the LDAP search base for the query.
1. If the client application allows non-ASCII input, 1. If the client application allows non-ASCII input,
convert the domain name formed in step 5.2.2.a above convert the domain name formed in step 5.2.2.a above
into its ASCII-compatible form using the "ToASCII" into its ASCII-compatible form using the "ToASCII"
process defined in RFC 3490. process defined in RFC 3490.
Hall I-D Expires: December 2003 [page 20]
2. Convert the right-most element from the domain name 2. Convert the right-most element from the domain name
formed in step 5.2.2.b.1 into a domainComponent DN formed in step 5.2.2.b.1 into a domainComponent DN
(such as "dc=com" or "dc=arpa"). This represents the (such as "dc=com" or "dc=arpa"). This represents the
directory partition for the current query. directory partition for the current query.
3. Append "cn=inetResources" to the front of the 3. Append "cn=inetResources" to the front of the
domainComponent syntax ("cn=inetResources,dc=com"). domainComponent syntax ("cn=inetResources,dc=com").
This will form the fully-qualified search base for the This will form the fully-qualified search base for the
LDAP query. LDAP query.
c. Locate the LDAP servers associated with the resource by c. Locate the LDAP servers associated with the resource by
processing the domain name formed in step 5.2.2.a above processing the domain name formed in step 5.2.2.a above
through the SRV query steps provided in section 5.2.4. through the SRV query steps provided in section 5.2.4.
Hall I-D Expires: December 2003 [page 23]
d. If the SRV lookup succeeds: d. If the SRV lookup succeeds:
1. Choose the best LDAP server, using the weighting 1. Choose the best LDAP server, using the weighting
formula described in [RFC2782]. formula described in [RFC2782].
2. Formulate the LDAP search using the search base and 2. Formulate the LDAP search using the search base and
search filter constructed earlier. For example, if the search filter constructed earlier. For example, if the
input query string was for "www.example.com", then the input query string was for "www.example.com", then the
client would begin the process by submitting an client would begin the process by submitting an
inetDnsDomainMatch extensibleMatch search with the inetDnsDomainMatch extensibleMatch search with the
skipping to change at line 1065 skipping to change at line 964
3. Submit the search operation to the chosen server and 3. Submit the search operation to the chosen server and
port number. If the operation fails, report the port number. If the operation fails, report the
failure to the user and exit. Otherwise, display any failure to the user and exit. Otherwise, display any
answer data which is returned. answer data which is returned.
4. If the answer data contains a subordinate reference 4. If the answer data contains a subordinate reference
referral or a continuation reference referral, new referral or a continuation reference referral, new
query processes MUST be spawned. query processes MUST be spawned.
For subordinate reference referrals, process the URLs For subordinate reference referrals, process the URLs
according to the rules described in section Error! according to the rules described in section 5.4 and
Reference source not found. and restart the query restart the query process at step 5.2.2.b. For each
process at step 5.2.2.b. For each continuation continuation reference referral, display the answer
reference referral, display the answer data received data received so far, process the LDAP URLs according
so far, process the LDAP URLs according to the rules
described in section Error! Reference source not Hall I-D Expires: December 2003 [page 21]
found. and start new query processes for each referral to the rules described in section 5.4 and start new
at step 5.2.2.b, appending the output from these query processes for each referral at step 5.2.2.b,
searches to the current output. appending the output from these searches to the
current output.
Any additional subordinate reference referrals or Any additional subordinate reference referrals or
continuation reference referrals which are encountered continuation reference referrals which are encountered
from any subsequent searches will need to be processed from any subsequent searches will need to be processed
in the same manner as specified above, until no in the same manner as specified above, until no
additional referrals are received. additional referrals are received.
Hall I-D Expires: December 2003 [page 24]
e. If the SRV lookup fails (where failure is defined as any e. If the SRV lookup fails (where failure is defined as any
DNS response message other than an answer), report the DNS response message other than an answer), report the
failure to the user and exit the current search operation. failure to the user and exit the current search operation.
f. Exit the query operation. f. Exit the query operation.
5.2.3. Bottom-Up Processing 5.2.3. Bottom-up processing
The bottom-up model uses an input string to construct an LDAP The bottom-up model uses an input string to construct an LDAP
assertion value and search base, with DNS queries being used to assertion value and search base, with DNS queries being used to
locate the LDAP servers which are associated with the management locate the LDAP servers which are associated with the management
entity that is directly responsible for the resource in question. entity that is directly responsible for the resource in question.
If no servers are available for that partition, the parent If no servers are available for that partition, the parent
partition in the delegation hierarchy is used instead, with this partition in the delegation hierarchy is used instead, with this
process repeating until a server has been located. process repeating until a server has been located.
The bottom-up model is best used when a leaf-node partition needs The bottom-up model is best used when a leaf-node partition needs
to be queried directly, either because there is no direct to be queried directly, either because there is no direct
skipping to change at line 1116 skipping to change at line 1016
more useful for those resources. more useful for those resources.
The steps for processing bottom-up queries are described below: The steps for processing bottom-up queries are described below:
a. Determine the input type (DNS Domain, IPv4 Address, etc.) a. Determine the input type (DNS Domain, IPv4 Address, etc.)
b. Determine the authoritative DNS domain for the resource. b. Determine the authoritative DNS domain for the resource.
1. Separate the input string into discrete elements where 1. Separate the input string into discrete elements where
this is possible. For a DNS domain name of this is possible. For a DNS domain name of
Hall I-D Expires: December 2003 [page 22]
"www.example.com", this would be "www", "example" and "www.example.com", this would be "www", "example" and
"com". For the IPv4 network number of "192.0.2.14", "com". For the IPv4 network number of "192.0.2.14",
this would be "192", "0", "2" and "14". Do not discard this would be "192", "0", "2" and "14". Do not discard
the original query string. the original query string.
2. IP addresses require additional conversion. For IPv4 2. IP addresses require additional conversion. For IPv4
addresses, strip off the prefix and convert the input addresses, strip off the prefix and convert the input
string into a reverse-lookup DNS domain name by string into a reverse-lookup DNS domain name by
reversing the order of the octets and appending reversing the order of the octets and appending
"in-addr.arpa" to the right of the resulting sequence. "in-addr.arpa" to the right of the resulting sequence.
For IPv6 addresses, strip off the prefix and reverse For IPv6 addresses, strip off the prefix and reverse
Hall I-D Expires: December 2003 [page 25]
the nibble order of the address (where each nibble is the nibble order of the address (where each nibble is
represented by a single hexadecimal character), and represented by a single hexadecimal character), and
append "ip6.arpa" to the right of the resulting append "ip6.arpa" to the right of the resulting
sequence. sequence.
c. Form the LDAP search base for the query. c. Form the LDAP search base for the query.
1. If the client application allows non-ASCII input, 1. If the client application allows non-ASCII input,
convert the domain name formed in step 5.2.3.b above convert the domain name formed in step 5.2.3.b above
into its ASCII-compatible form using the "ToASCII" into its ASCII-compatible form using the "ToASCII"
skipping to change at line 1163 skipping to change at line 1063
processing the domain name formed in step 5.2.3.b above processing the domain name formed in step 5.2.3.b above
through the SRV query steps provided in section 5.2.4. through the SRV query steps provided in section 5.2.4.
e. If the SRV lookup fails with an NXDOMAIN response code (as e. If the SRV lookup fails with an NXDOMAIN response code (as
described in RFC 2308), then the domain name used for the described in RFC 2308), then the domain name used for the
SRV lookup does not exist, and a substitute LDAP server and SRV lookup does not exist, and a substitute LDAP server and
search base must be used instead. This process involves search base must be used instead. This process involves
determining the parent zone for the domain name in determining the parent zone for the domain name in
question, issuing an SRV lookup for that zone, and using question, issuing an SRV lookup for that zone, and using
the domain name of the zone as the new LDAP search base, the domain name of the zone as the new LDAP search base,
Hall I-D Expires: December 2003 [page 23]
with this process repeating until a search base can be with this process repeating until a search base can be
located, or until a critical failure forces an exit. located, or until a critical failure forces an exit.
1. Remove the left-most label from the domain name formed 1. Remove the left-most label from the domain name formed
in step 5.2.3.b. in step 5.2.3.b.
2. If this process has already resulted in a query domain 2. If this process has already resulted in a query domain
name at a top-level domain such as "com" or "arpa", name at a top-level domain such as "com" or "arpa",
convert the query domain name to "." (to signify the convert the query domain name to "." (to signify the
root domain). root domain).
Hall I-D Expires: December 2003 [page 26]
3. If the queried domain name is already set to ".", the 3. If the queried domain name is already set to ".", the
query can go no higher (this most likely indicates a query can go no higher (this most likely indicates a
malformed DNS configuration, a connectivity problem, malformed DNS configuration, a connectivity problem,
or a typo in the query). Exit and report the failure or a typo in the query). Exit and report the failure
to the user. to the user.
4. Restart the process at step 5.2.2.b, using the domain 4. Restart the process at step 5.2.2.b, using the domain
name formed above. Repeat until a server is located or name formed above. Repeat until a server is located or
a critical failure forces an exit. a critical failure forces an exit.
skipping to change at line 1210 skipping to change at line 1111
input query string was for "www.example.com", then the input query string was for "www.example.com", then the
client would begin the process by submitting an client would begin the process by submitting an
inetDnsDomainMatch extensibleMatch search with the inetDnsDomainMatch extensibleMatch search with the
assertion value of "www.example.com", with the search assertion value of "www.example.com", with the search
base of "cn=inetResources,dc=www,dc=example,dc=com". base of "cn=inetResources,dc=www,dc=example,dc=com".
If the SRV lookups had failed (resulting in "com" If the SRV lookups had failed (resulting in "com"
being used as the authoritative directory partition), being used as the authoritative directory partition),
then the search base for the query would also be then the search base for the query would also be
trimmed accordingly ("cn=inetResources,dc=com"). trimmed accordingly ("cn=inetResources,dc=com").
Hall I-D Expires: December 2003 [page 24]
3. Submit the search operation to the chosen server and 3. Submit the search operation to the chosen server and
port number. If the operation fails, report the port number. If the operation fails, report the
failure to the user and exit. Otherwise, display any failure to the user and exit. Otherwise, display any
answer data which is returned. answer data which is returned.
4. If the answer data contains a subordinate reference 4. If the answer data contains a subordinate reference
referral or a continuation reference referral, new referral or a continuation reference referral, new
query processes MUST be spawned. query processes MUST be spawned.
For subordinate reference referrals, process the URLs For subordinate reference referrals, process the URLs
according to the rules described in section Error! according to the rules described in section 5.4 and
restart the query process at step 5.2.3.d. For each
Hall I-D Expires: December 2003 [page 27] continuation reference referral, display the answer
Reference source not found. and restart the query data received so far, process the LDAP URLs according
process at step 5.2.3.d. For each continuation to the rules described in section 5.4 and start new
reference referral, display the answer data received query processes for each referral at step 5.2.3.d,
so far, process the LDAP URLs according to the rules appending the output from these searches to the
described in section Error! Reference source not current output.
found. and start new query processes for each referral
at step 5.2.3.d, appending the output from these
searches to the current output.
Any additional subordinate reference referrals or Any additional subordinate reference referrals or
continuation reference referrals which are encountered continuation reference referrals which are encountered
from any subsequent queries will need to be processed from any subsequent queries will need to be processed
in the same manner as specified above, until no in the same manner as specified above, until no
additional referrals are received. additional referrals are received.
g. If a fatal DNS error condition occurs, report the error to g. If a fatal DNS error condition occurs, report the error to
the user and stop processing the current query. A fatal DNS the user and stop processing the current query. A fatal DNS
error is any response message with an RCODE of FORMERR, error is any response message with an RCODE of FORMERR,
skipping to change at line 1249 skipping to change at line 1148
the user and stop processing the current query. A fatal DNS the user and stop processing the current query. A fatal DNS
error is any response message with an RCODE of FORMERR, error is any response message with an RCODE of FORMERR,
SERVFAIL, NOTIMPL, or REFUSED, or where a query results in SERVFAIL, NOTIMPL, or REFUSED, or where a query results in
NODATA (implying that an "_ldap._tcp" domain name exists NODATA (implying that an "_ldap._tcp" domain name exists
but it doesn't have an SRV resource record associated with but it doesn't have an SRV resource record associated with
it, which is most likely a configuration error). it, which is most likely a configuration error).
h. Exit the query operation. h. Exit the query operation.
5.2.4. SRV processing 5.2.4. SRV processing
The bootstrapping models described in this document make use of The bootstrapping models described in this document make use of
DNS SRV resource records to locate the LDAP servers associated DNS SRV resource records to locate the LDAP servers associated
with the resource provided in the query input. with the resource provided in the query input.
The procedure for constructing this SRV lookup is as follows: The procedure for constructing this SRV lookup is as follows:
a. Construct an SRV-specific label pair for the service type. a. Construct an SRV-specific label pair for the service type.
For LDAP queries, this will be "_ldap._tcp". For LDAP queries, this will be "_ldap._tcp".
Hall I-D Expires: December 2003 [page 25]
b. If the client allows non-ASCII characters to be input, then b. If the client allows non-ASCII characters to be input, then
convert the domain name input into its ASCII-compatible convert the domain name input into its ASCII-compatible
form by using the "ToASCII" process described in [RFC3490]. form by using the "ToASCII" process described in [RFC3490].
c. Append the SRV label pair to the left of the input domain c. Append the SRV label pair to the left of the input domain
name from step 5.2.4.b. In the case of a query for the name from step 5.2.4.b. In the case of a query for the
"example.com" domain, this would result in an SRV-specific "example.com" domain, this would result in an SRV-specific
domain name of "_ldap._tcp.example.com". domain name of "_ldap._tcp.example.com".
Hall I-D Expires: December 2003 [page 28]
d. Issue a DNS query for the SRV resource records associated d. Issue a DNS query for the SRV resource records associated
with the domain name formed in step 5.2.4.b. with the domain name formed in step 5.2.4.b.
Multiple SRV resource records may be returned in response to a Multiple SRV resource records may be returned in response to a
query. Each resource record identifies a different connection query. Each resource record identifies a different connection
target, including the domain name of a server, and a port number target, including the domain name of a server, and a port number
for that server. The port number specified in a SRV resource for that server. The port number specified in a SRV resource
record MUST be used for any subsequent bind and search operations. record MUST be used for any subsequent bind and search operations.
SRV resource records provide "priority" and "weight" values which SRV resource records provide "priority" and "weight" values which
skipping to change at line 1286 skipping to change at line 1186
SRV resource records provide "priority" and "weight" values which SRV resource records provide "priority" and "weight" values which
MUST be used to determine the preferred server. If a server is MUST be used to determine the preferred server. If a server is
unavailable or unreachable, a connection attempt must be made to unavailable or unreachable, a connection attempt must be made to
the next-best server in the answer set. the next-best server in the answer set.
Refer to [RFC2782] for a detailed explanation of SRV resource Refer to [RFC2782] for a detailed explanation of SRV resource
records and their handling. records and their handling.
5.3. Query Processing 5.3. Query Processing
Once an authoritative server for the partition in question has Once an authoritative server for the partition in question has
been located, the LDAP query can be submitted. In order to ensure been located, the LDAP query can be submitted. In order to ensure
interoperability, this specification defines several behavioral interoperability, this specification defines several behavioral
rules which clients and servers are encouraged to conform with. rules which clients and servers are encouraged to conform with.
These guidelines are discussed in the following sections. These guidelines are discussed in the following sections.
5.3.1. Search Filters 5.3.1. Matching filters
LDAP search filters are fairly flexible, in that they allow for a LDAP search filters are fairly flexible, in that they allow for a
wide variety of configurable elements, such as the maximum number wide variety of configurable elements, such as the maximum number
of entries which are returned, the type of comparison operation of entries which are returned, the type of comparison operation
that needs to be performed, and other details. In order to ensure that needs to be performed, and other details. In order to ensure
interoperability, default values are defined here for many of interoperability, default values are defined here for many of
these elements. these elements.
Section 4.5.1 of [RFC2251] defines the LDAP search request [RFC2251] defines the LDAP search request specification, although
specification, although it does not provide guidelines or it does not provide guidelines or recommended values for the
recommended values for the filter settings. In an effort to filter settings. In an effort to promote interoperability among
promote interoperability among FIRS clients and servers, this
document defines some recommended and mandatory values for Hall I-D Expires: December 2003 [page 26]
searches within the FIRS service. FIRS clients and servers, this document defines some recommended
and mandatory values for searches within the FIRS service.
NOTE: These rules ONLY apply to the FIRS search operations NOTE: These rules ONLY apply to the FIRS search operations
in particular. Any queries for other resources (such as in particular. Any queries for other resources SHOULD NOT
requests for inetOrgPerson contact entries) SHOULD NOT
impose these restrictions. Also note that other documents impose these restrictions. Also note that other documents
Hall I-D Expires: December 2003 [page 29]
which define additional resource types can also define which define additional resource types can also define
different restrictions, and those definitions will take different restrictions, and those definitions will take
precedence over the global defaults. precedence over the global defaults.
Servers MUST be prepared to enforce these rules independently of Servers MUST be prepared to enforce these rules independently of
the client settings, and clients MUST be prepared to receive the client settings, and clients MUST be prepared to receive
truncated search results accordingly. truncated search results accordingly.
The default values of an LDAPv3 search filter in FIRS are: The default values of an LDAPv3 search filter in FIRS are:
skipping to change at line 1353 skipping to change at line 1253
partition on the same server). partition on the same server).
* Size limit. The size limit field specifies the maximum * Size limit. The size limit field specifies the maximum
number of entries that a server should return. For the FIRS number of entries that a server should return. For the FIRS
service, this setting SHOULD be set to a value between 25 service, this setting SHOULD be set to a value between 25
and 100. This range ensures that the client is capable of and 100. This range ensures that the client is capable of
receiving a sufficient number of entries and continuation receiving a sufficient number of entries and continuation
references in a single response, but also works to prevent references in a single response, but also works to prevent
runaway queries that match everything (such as searches for runaway queries that match everything (such as searches for
"com", which can match every inetDnsDomain entry in the "com", which can match every inetDnsDomain entry in the
Hall I-D Expires: December 2003 [page 27]
"cn=inetResources,dc=com" container). Servers MAY truncate "cn=inetResources,dc=com" container). Servers MAY truncate
answer sets to 100 responses if the client specifies a answer sets to 100 responses if the client specifies a
larger value. larger value.
* Time limit. The time limit field specifies the maximum * Time limit. The time limit field specifies the maximum
number of seconds that a server should process the search. number of seconds that a server should process the search.
Hall I-D Expires: December 2003 [page 30]
For the FIRS service, this setting SHOULD be set to a value For the FIRS service, this setting SHOULD be set to a value
between 10 and 60 seconds. This range ensures that the between 10 and 60 seconds. This range ensures that the
server is able to process a sufficient number of entries, server is able to process a sufficient number of entries,
but also works to prevent runaway queries that match but also works to prevent runaway queries that match
everything. Servers MAY stop processing queries after 60 everything. Servers MAY stop processing queries after 60
seconds if the client specifies a larger value. seconds if the client specifies a larger value.
* Types-only. The types-only setting is a Boolean flag which * Types-only. The types-only setting is a Boolean flag which
controls whether or not attribute values are returned in controls whether or not attribute values are returned in
the answer sets. Since excessive queries are likely to be the answer sets. Since excessive queries are likely to be
skipping to change at line 1384 skipping to change at line 1284
be prepared to issue the necessary subsequent queries. be prepared to issue the necessary subsequent queries.
* Filter. The search operation will depend on the type of * Filter. The search operation will depend on the type of
data being queried. For FIRS queries, the filter MUST use data being queried. For FIRS queries, the filter MUST use
the matching rules defined for the relevant resource type. the matching rules defined for the relevant resource type.
* Attribute list. Clients MAY restrict the list of attributes * Attribute list. Clients MAY restrict the list of attributes
which are returned in searches, but are discouraged from which are returned in searches, but are discouraged from
doing so without cause. doing so without cause.
5.3.2. Authentication and access controls 5.3.2. Query-volume restrictions
The restrictions listed in section 5.3.1 represent suggested The restrictions listed in section 5.3.1 represent suggested
defaults, although server operators MAY impose any kinds of usage defaults, although server operators MAY impose any kinds of usage
limits they deem necessary or desirable. For example, server limits they deem necessary or desirable.
operators MAY restrict the number of queries that they will accept
from a particular client and/or user over a given amount of time.
Server operators MAY choose to restrict the amount of information
provided to specific clients and/or users. For example, server
operators MAY choose to withhold detailed contact information from
anonymous users or non-privileged clients, as necessary or
desirable. Clients SHOULD NOT equate the absence of any attributes
with the absence of data, and SHOULD assume that the user is not
authorized to view any data which has not been provided.
Servers SHOULD allow anonymous authentication for read-only access Specifically, server operators MAY restrict the amount of
to public delegation data. Clients SHOULD use anonymous information provided to specific clients and/or users over a given
authentication by default. Server operators MAY require any kind amount of time, within reason. For example, servers MAY restrict
of authentication mechanisms they wish for any other data, clients to an arbitrary number of queries per hour, per day, and
although operators are encouraged to use one of the well-known so forth. Servers which refuse to process a query due volume
mechanisms commonly used with LDAPv3. policy SHOULD reject the connection and/or query using the
"unwillingToPerform" response code ("53").
Hall I-D Expires: December 2003 [page 31]
Clients MUST be prepared for connection requests and queries to be Clients MUST be prepared for connection requests and queries to be
denied for any reason, and MUST treat these conditions as non- denied for any reason, and MUST treat these conditions as non-
permanent failures. Clients MAY retry the operations if the error permanent failures. Clients MAY retry the operations if a known
condition is corrected (such as having the user authenticate to
the server), but SHOULD NOT automatically generate retry attempts Hall I-D Expires: December 2003 [page 28]
for the failing partition (including any replicas). error condition is corrected (such as authentication errors), but
SHOULD NOT automatically generate retry attempts.
5.3.3. Authentication restrictions
Servers operators SHOULD allow anonymous authentication for read-
only access to public delegation data. Clients SHOULD use
anonymous authentication by default.
Wherever a server operator requires or desires clients to
authenticate for access, servers MUST support the simple
authentication mechanism defined in RFC 2222 [RFC2222], although
server operators MAY require the use of any authentication
mechanisms in addition to or instead of the simple mechanism.
Server operators SHOULD NOT impose unreasonable requirements for
proprietary authentication mechanisms for routine purposes.
Server operators MAY withhold privileged information from non-
privileged clients or users, as necessary.
Clients SHOULD NOT equate the absence of any attributes with the
absence of data, and SHOULD assume that the user is not authorized
to view any data which has not been provided.
5.3.4. Protocol and schema version controls
5.3.3. Protocol and schema version controls
The FIRS collection of specifications are explicitly bound to the The FIRS collection of specifications are explicitly bound to the
LDAPv3 protocol, as defined by [RFC2251]. If a new version of the LDAPv3 protocol, as defined by [RFC3377] and its subordinate
LDAP protocol emerges, it is expected that some type of mechanism specifications. If a new version of the LDAP protocol emerges, it
will be included for end-points to use when negotiating over the is expected that some type of mechanism will be included for end-
version in use. Lacking such a mechanism, FIRS is explicitly points to use when negotiating over the version in use. Lacking
restricted to LDAPv3. such a mechanism, FIRS is explicitly restricted to LDAPv3.
LDAP attributes, object classes, syntaxes and matching filters LDAP attributes, object classes, syntaxes and matching filters
have OIDs which uniquely identify the format of the data they have OIDs which uniquely identify the format of the data they
provide, and which act as simple schema-version identifiers in the provide, and which act as simple schema-version identifiers in the
generic case. [RFC2251] defines standardized mechanisms for generic case. [RFC2251] defines standardized mechanisms for
retrieving and reading the OIDs associated with object classes and retrieving and reading the OIDs associated with object classes and
attributes (among other resource types). These mechanisms MAY be attributes (among other resource types). These mechanisms MAY be
used whenever a FIRS client reads an entry, and MUST be used used whenever a FIRS client reads an entry, and MUST be used
whenever a FIRS client modifies or creates an entry (even though whenever a FIRS client modifies or creates an entry (even though
FIRS does not define mechanisms for updating entries, it is FIRS does not define mechanisms for updating entries, it is
assumed that some clients will allow this behavior). assumed that some clients will allow this behavior).
Hall I-D Expires: December 2003 [page 29]
Modifications to existing schema definitions MUST be accompanied Modifications to existing schema definitions MUST be accompanied
by OID changes. by OID changes.
5.4. Post-Query Processing 5.4. Referral Processing
As was discussed in section 3.4, FIRS supports two types of As was discussed in section 3.4, FIRS supports two types of
referrals, which are subordinate reference referrals and referrals, which are subordinate reference referrals and
continuation reference referrals. Both referral types use URLs for continuation reference referrals. Both referral types use URLs for
the purpose of providing referral targets, using the rules the purpose of providing referral targets, using the rules
described in section 3.4 of this document. described in section 3.4 of this document.
Non-compliance with the requirements provided in section 3.4 Non-compliance with the requirements provided in section 3.4
amounts to an error, and is sufficient cause for a client to stop amounts to an error, and is sufficient cause for a client to stop
processing a query. processing a query.
As was discussed in section 3.4, subordinate reference referrals As was discussed in section 3.4, subordinate reference referrals
are defined in [RFC3296], and use the SearchResultDone response are defined in [RFC3296], and use the SearchResultDone response
with a Referral result code as defined in [RFC2251]. Subordinate with a Referral result code as defined in [RFC2251]. Subordinate
Hall I-D Expires: December 2003 [page 32]
reference referrals use a subset of the labeledURI syntax as reference referrals use a subset of the labeledURI syntax as
defined in [RFC2079], and use the syntax definitions from defined in [RFC2079], and use the syntax definitions from
[RFC2255] when LDAP URLs in particular are provided, although [RFC2255] when LDAP URLs in particular are provided, although
section 3.4 of this document also defines additional restrictions section 3.4 of this document also defines additional restrictions
on the allowable URL syntax. This condition means that the current on the allowable URL syntax. This condition means that the current
search operation cannot proceed past this point, and the search search operation cannot proceed past this point, and the search
MUST be restarted. This will most often occur when the MUST be restarted. This will most often occur when the
inetResources entry for a partition has been redirected to another inetResources entry for a partition has been redirected to another
directory partition. directory partition.
skipping to change at line 1481 skipping to change at line 1396
for all of the answer data to be retrieved (in many cases, no for all of the answer data to be retrieved (in many cases, no
answer data will be provided, and in those situations, new queries answer data will be provided, and in those situations, new queries
will be required for any data to be retrieved). This will occur will be required for any data to be retrieved). This will occur
whenever the assertion value of a search has matched a resource whenever the assertion value of a search has matched a resource
entry which is being managed by another directory partition, and entry which is being managed by another directory partition, and
can occur with any of the search operations described in this can occur with any of the search operations described in this
document. document.
The procedure for processing referral URLs is as follows: The procedure for processing referral URLs is as follows:
Hall I-D Expires: December 2003 [page 30]
a. [RFC2251] allows multiple URLs to be provided, although the a. [RFC2251] allows multiple URLs to be provided, although the
URLs are not provided with any "preference" or "weighting" URLs are not provided with any "preference" or "weighting"
values. If a set of URLs are provided, only one of the URLs values. If a set of URLs are provided, only one of the URLs
need to be tried (implementations MAY perform additional need to be tried (implementations MAY perform additional
queries in an attempt to recover from temporary failures, queries in an attempt to recover from temporary failures,
although this is not required). Select one of the URLs at although this is not required). Select one of the URLs at
random ("round-robin"), and continue to the next step in random ("round-robin"), and continue to the next step in
the process. the process.
b. Validate the protocol label. FIRS only supports the use of b. Validate the protocol label. FIRS only supports the use of
the LDAP service type. URLs with other protocol identifiers the LDAP service type. URLs with other protocol identifiers
are to be treated as malformed. are to be treated as malformed.
c. Extract the port number provided with the URL, and set it c. Extract the port number provided with the URL, and set it
aside for use with the subsequent connection attempt. If no aside for use with the subsequent connection attempt. If no
port number has been provided in the URL, use the default port number has been provided in the URL, use the port
number discovered through any subsequent SRV lookups (as
Hall I-D Expires: December 2003 [page 33] described below), or as a last resort use the default port
port numbers associated with the protocol, as discovered in number associated with the protocol identifier.
step 5.4.b as a default value.
d. Determine the authoritative partition and search base d. Determine the authoritative partition and search base
specified in the referral URL. specified in the referral URL.
1. If no distinguished name element was provided, report 1. If no distinguished name element was provided, reuse
the failure to the user and exit. the existing authoritative partition and search base.
2. Otherwise, use the distinguished name element for the 2. Otherwise, use the distinguished name element for the
search base of the subsequent search operation. search base of the subsequent search operation.
3. Extract the right-most sequence of domainComponent 3. Extract the sequence of domainComponent distinguished
distinguished names from the search base, and use them names from the search base, and use them as the
as the authoritative partition. authoritative partition.
e. Determine the server address and port number specified in e. Determine the server address and port number specified in
the referral URL. the referral URL.
1. If the host identifier is an IP address, extract it 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
this step fails, report the error to the user and exit
the query.
2. If the host identifier is an IP address, extract it
and skip to step 5.4.f. and skip to step 5.4.f.
2. If no port number was provided in the URL, submit a Hall I-D Expires: December 2003 [page 31]
3. If no port number was provided in the URL, submit a
DNS lookup for the SRV resource records associated DNS lookup for the SRV resource records associated
with the domain name, as described in section 5.2.4. with the domain name, as described in section 5.2.4.
If this lookup succeeds, skip to step 5.4.f.
3. If a port number was provided or if the SRV lookup 4. If the SRV lookup from the previous step fails, or if
fails, submit a DNS lookup for the A resource records. no port number was specified, submit a DNS lookup for
the A resource records.
4. If a host identifier was not provided, map the
domainComponent elements determined in step 5.4.d to a
DNS domain name and submit an SRV DNS lookup for the
LDAP servers associated with that domain name. If this
final step fails, report the error to the user and
exit the query.
f. Determine the new assertion value and/or matching filter f. Determine the new assertion value and/or matching filter
specified in the referral URL. specified in the referral URL.
1. If the URL's path element does not contain a filter 1. If the URL's path element does not contain a filter
element, reuse the current matching filter and element, reuse the current matching filter and
assertion value. assertion value.
2. If the URL's path element contains a filter element, 2. If the URL's path element contains a filter element,
use it to form the new matching filter and/or use it to form the new matching filter and/or
assertion value. assertion value.
Hall I-D Expires: December 2003 [page 34]
g. Discard the remainder of the URL. g. Discard the remainder of the URL.
h. Use the discovered parameter values to start a new query. h. Use the discovered parameter values to start a new query.
For example, imagine that a referral has been received with the
URL value of "ldap:///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 the subsequent query.
* Use the domainComponent sequence of "dc=example,dc=com" as
the new authoritative partition.
* No host identifier was specified in the URL, so the
"dc=example,dc=com" partition must be used to seed a server
identifier of "example.com".
* Issue DNS lookups for the SRV resource records associated
with "_ldap._tcp.example.com" to determine the server and
port number for the subsequent query.
* Reuse the existing assertion value and matching filter.
Hall I-D Expires: December 2003 [page 32]
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 the subsequent query.
* Use the domainComponent sequence of "dc=example,dc=com" as
the new authoritative partition.
* Use the host identifier of "example.com" as specified in
the URL.
* Issue DNS lookups for the SRV resource records associated
with "_ldap._tcp.example.com" to determine the server and
port number for the subsequent query.
* Reuse the existing assertion value and matching filter.
As another example, imagine a referral with the URL value of
"ldap:////???(cn:dn:www.example.com). The processing rules for
this URL would be as follows:
* Reuse the existing search base and authoritative partition
information.
* Reuse the existing server and port number.
* Use "(cn:dn:www.example.com)" as the new matching filter
and assertion value.
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.
6. Security Considerations 6. Security Considerations
Security considerations are discussed in [FIRS-ARCH]. Security considerations are discussed in [FIRS-ARCH].
7. IANA Considerations 7. IANA Considerations
IANA considerations are discussed in [FIRS-ARCH]. IANA considerations are discussed in [FIRS-ARCH].
Hall I-D Expires: December 2003 [page 33]
8. Author's Addresses 8. Author's Addresses
Eric A. Hall Eric A. Hall
ehall@ehsco.com ehall@ehsco.com
9. Normative References 9. Normative References
[RFC1274] Barker, P., and Kille, S. "The COSINE and [RFC1274] Barker, P., and Kille, S. "The COSINE and
Internet X.500 Schema", RFC 1274, November Internet X.500 Schema", RFC 1274, November
1991. 1991.
[RFC2079] Smith, M. "Definition of an X.500 Attribute [RFC2079] Smith, M. "Definition of an X.500 Attribute
Type and an Object Class to Hold Uniform Type and an Object Class to Hold Uniform
Resource Identifiers (URIs)", RFC 2079, Resource Identifiers (URIs)", RFC 2079,
January 1997. January 1997.
[RFC2222] Myers, J. "Simple Authentication and Security
Layer (SASL)", RFC 2222, October 1997.
[RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R.,
and Sataluri, S. "Using Domains in LDAP/X.500 and Sataluri, S. "Using Domains in LDAP/X.500
DNs", RFC 2247, January 1998. DNs", RFC 2247, January 1998.
[RFC2251] Wahl, M., Howes, T., and Kille, S. [RFC2251] Wahl, M., Howes, T., and Kille, S.
"Lightweight Directory Access Protocol (v3)", "Lightweight Directory Access Protocol (v3)",
RFC 2251, December 1997. RFC 2251, December 1997.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille,
S. "Lightweight Directory Access Protocol S. "Lightweight Directory Access Protocol
(v3): Attribute Syntax Definitions", RFC 2252, (v3): Attribute Syntax Definitions", RFC 2252,
December 1997. December 1997.
[RFC2253] Wahl, M., Kille, S., and Howes, T. [RFC2253] Wahl, M., Kille, S., and Howes, T.
"Lightweight Directory Access Protocol (v3): "Lightweight Directory Access Protocol (v3):
UTF-8 String Representation of DNs", RFC 2253, UTF-8 String Representation of DNs", RFC 2253,
December 1997. December 1997.
Hall I-D Expires: December 2003 [page 35]
[RFC2254] Howes, T. "The String Representation of LDAP [RFC2254] Howes, T. "The String Representation of LDAP
Search Filters", RFC 2254, December 1997. Search Filters", RFC 2254, December 1997.
[RFC2255] Howes, T., and Smith, M. "The LDAP URL [RFC2255] Howes, T., and Smith, M. "The LDAP URL
Format", RFC 2255, December 1997. Format", RFC 2255, December 1997.
[RFC2256] Wahl, M. "A Summary of the X.500(96) User [RFC2256] Wahl, M. "A Summary of the X.500(96) User
Schema for use with LDAPv3", RFC 2256, Schema for use with LDAPv3", RFC 2256,
December 1997. December 1997.
[RFC2277] Alvestrand, H. "IETF Policy on Character Sets [RFC2277] Alvestrand, H. "IETF Policy on Character Sets
and Languages", BCP 18, RFC 2277, January and Languages", BCP 18, RFC 2277, January
1998. 1998.
Hall I-D Expires: December 2003 [page 34]
[RFC2308] Andrews, M. "Negative Caching of DNS Queries [RFC2308] Andrews, M. "Negative Caching of DNS Queries
(DNS NCACHE)", RFC 2308, March 1998. (DNS NCACHE)", RFC 2308, March 1998.
[RFC2596] Wahl, M., and Howes, T. "Use of Language Codes [RFC2596] Wahl, M., and Howes, T. "Use of Language Codes
in LDAP", RFC 2596, May 1999. in LDAP", RFC 2596, May 1999.
[RFC2782] Gulbrandsen, A., Vixie, P., and Esibov, L. "A [RFC2782] Gulbrandsen, A., Vixie, P., and Esibov, L. "A
DNS RR for specifying the location of services DNS RR for specifying the location of services
(DNS SRV)", RFC 2782, February 2000. (DNS SRV)", RFC 2782, February 2000.
skipping to change at line 1631 skipping to change at line 1615
[RFC3377] Hodges, J., and Morgan, R. "Lightweight [RFC3377] Hodges, J., and Morgan, R. "Lightweight
Directory Access Protocol (v3): Technical Directory Access Protocol (v3): Technical
Specification", RFC 3377, September 2002. Specification", RFC 3377, September 2002.
[RFC3490] Faltstrom, P., Hoffman, P., and Costello, A. [RFC3490] Faltstrom, P., Hoffman, P., and Costello, A.
"Internationalizing Domain Names in "Internationalizing Domain Names in
Applications (IDNA)", RFC 3490, March 2003. Applications (IDNA)", RFC 3490, March 2003.
[FIRS-ARCH] Hall, E. "The Federated Internet Registry [FIRS-ARCH] Hall, E. "The Federated Internet Registry
Service: Architecture and Implementation Service: Architecture and Implementation
Guide", draft-ietf-crisp-firs-arch-00, May Guide", draft-ietf-crisp-firs-arch-01, May
2003. 2003.
[FIRS-ASN] Hall, E. "Defining and Locating Autonomous [FIRS-ASN] Hall, E. "Defining and Locating Autonomous
System Numbers in the Federated Internet System Numbers in the Federated Internet
Registry Service", draft-ietf-crisp-firs-asn- Registry Service", draft-ietf-crisp-firs-asn-
00, May 2003. 01, May 2003.
Hall I-D Expires: December 2003 [page 36]
[FIRS-CONTCT] Hall, E. "Defining and Locating Contact [FIRS-CONTCT] Hall, E. "Defining and Locating Contact
Persons in the Federated Internet Registry Persons in the Federated Internet Registry
Service", draft-ietf-crisp-firs-contact-00, Service", draft-ietf-crisp-firs-contact-01,
May 2003. May 2003.
[FIRS-CORE] Hall, E. "The Federated Internet Registry [FIRS-CORE] Hall, E. "The Federated Internet Registry
Service: Core Elements", draft-ietf-crisp- Service: Core Elements", draft-ietf-crisp-
firs-core-00, May 2003. firs-core-01, May 2003.
[FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in
the Federated Internet Registry Service", the Federated Internet Registry Service",
draft-ietf-crisp-firs-dns-00, May 2003. draft-ietf-crisp-firs-dns-01, May 2003.
[FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource
Records in the Federated Internet Registry Records in the Federated Internet Registry
Service", draft-ietf-crisp-firs-dnsrr-00, May
Hall I-D Expires: December 2003 [page 35]
Service", draft-ietf-crisp-firs-dnsrr-01, May
2003. 2003.
[FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address
Blocks in the Federated Internet Registry Blocks in the Federated Internet Registry
Service", draft-ietf-crisp-firs-ipv4-00, May Service", draft-ietf-crisp-firs-ipv4-01, May
2003. 2003.
[FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address
Blocks in the Federated Internet Registry Blocks in the Federated Internet Registry
Service", draft-ietf-crisp-firs-ipv6-00, May Service", draft-ietf-crisp-firs-ipv6-01, May
2003. 2003.
[US-ASCII] Cerf, V. "ASCII format for Network [US-ASCII] Cerf, V. "ASCII format for Network
Interchange", RFC 20, October 1969. Interchange", RFC 20, October 1969.
10. Acknowledgments 10. Acknowledgments
Funding for the RFC editor function is currently provided by the Funding for the RFC editor function is currently provided by the
Internet Society. Internet Society.
Portions of this document were funded by Verisign Labs. Portions of this document were funded by Verisign Labs.
The first version of this specification was co-authored by Andrew The first version of this specification was co-authored by Andrew
Newton of Verisign Labs, and subsequent versions continue to be Newton of Verisign Labs, and subsequent versions continue to be
developed with his active participation. developed with his active participation.
11. Changes from Previous Versions 11. Changes from Previous Versions
skipping to change at line 1682 skipping to change at line 1668
Funding for the RFC editor function is currently provided by the Funding for the RFC editor function is currently provided by the
Internet Society. Internet Society.
Portions of this document were funded by Verisign Labs. Portions of this document were funded by Verisign Labs.
The first version of this specification was co-authored by Andrew The first version of this specification was co-authored by Andrew
Newton of Verisign Labs, and subsequent versions continue to be Newton of Verisign Labs, and subsequent versions continue to be
developed with his active participation. developed with his active participation.
11. Changes from Previous Versions 11. Changes from Previous Versions
draft-ietf-crisp-fir-core-00:
draft-ietf-crisp-firs-core-01:
* Several clarifications and corrections have been made.
* Significant portions of text were moved to [FIRS-ARCH].
draft-ietf-crisp-firs-core-00:
* Restructured document set, separating the architectural * Restructured document set, separating the architectural
discussion from the technical descriptions. Several discussion from the technical descriptions. Several
Hall I-D Expires: December 2003 [page 37]
sections were relocated to [FIRS-ARCH] as a result of this sections were relocated to [FIRS-ARCH] as a result of this
change. change.
* "Attribute references" have been eliminated from the * "Attribute references" have been eliminated from the
specification. All referential attributes now provide specification. All referential attributes now provide
actual data instead of URL pointers to data. Clients that actual data instead of URL pointers to data. Clients that
wish to retrieve these values will need to start new wish to retrieve these values will need to start new
queries using the data values instead of URLs. queries using the data values instead of URLs.
Hall I-D Expires: December 2003 [page 36]
* The various modified* operational attributes in the core * The various modified* operational attributes in the core
schema have been eliminated as unnecessary. schema have been eliminated as unnecessary.
* Several attributes had their OIDs changed. NOTE THAT THIS * Several attributes had their OIDs changed. NOTE THAT THIS
IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO
ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED.
draft-ietf-crisp-lw-core-00: draft-ietf-crisp-lw-core-00:
* As a result of the formation of the CRISP working group, * As a result of the formation of the CRISP working group,
skipping to change at line 1720 skipping to change at line 1712
describe the per-resource schema and access mechanisms. describe the per-resource schema and access mechanisms.
* References to the ldaps: URL scheme have been removed, * References to the ldaps: URL scheme have been removed,
since there is no standards-track specification for the since there is no standards-track specification for the
ldaps: scheme. ldaps: scheme.
* An acknowledgements section was added. * An acknowledgements section was added.
draft-hall-ldap-whois-01: draft-hall-ldap-whois-01:
* The ôObjectivesö section has been removed. [ir-dir-req] is * The “Objectives” section has been removed. [ir-dir-req] is
now being used as the guiding document for this service. now being used as the guiding document for this service.
* Several typographical errors have been fixed. * Several typographical errors have been fixed.
* Some unnecessary text has been removed. * Some unnecessary text has been removed.
* Figures changed to show complete sets of object classes, to * Figures changed to show complete sets of object classes, to
improve inheritance visibility. improve inheritance visibility.
Hall I-D Expires: December 2003 [page 38]
* Clarified the handling of reverse-lookup domains (zones * Clarified the handling of reverse-lookup domains (zones
within the in-addr.arpa portion of the DNS hierarchy) in within the in-addr.arpa portion of the DNS hierarchy) in
the inetDnsDomain object class reference text. the inetDnsDomain object class reference text.
* Referrals now use regular LDAP URLs (multiple responses * Referrals now use regular LDAP URLs (multiple responses
with explicit hostnames and port numbers). Prior editions with explicit hostnames and port numbers). Prior editions
of this specification used LDAP SRV resource records for of this specification used LDAP SRV resource records for
all referrals. all referrals.
* The delegation status codes used by the * The delegation status codes used by the
inetDnsDelegationStatus, inetIpv4DelegationStatus, inetDnsDelegationStatus, inetIpv4DelegationStatus,
inetIpv6DelegationStatus and inetAsnDelegationStatus inetIpv6DelegationStatus and inetAsnDelegationStatus
attributes have been condensed to a more logical set. attributes have been condensed to a more logical set.
Hall I-D Expires: December 2003 [page 37]
* Added an inetDnsAuthServers attribute for publishing the * Added an inetDnsAuthServers attribute for publishing the
authoritative DNS servers associated with a domain. NOTE authoritative DNS servers associated with a domain. NOTE
THAT THIS IS A TEMPORARY ATTRIBUTE THAT WILL EVENTUALLY BE THAT THIS IS A TEMPORARY ATTRIBUTE THAT WILL EVENTUALLY BE
REPLACED BY GENERALIZED RESOURCE-RECORD ENTRIES AND REPLACED BY GENERALIZED RESOURCE-RECORD ENTRIES AND
ATTRIBUTES. ATTRIBUTES.
* Added an inetGeneralDisclaimer attribute for publishing * Added an inetGeneralDisclaimer attribute for publishing
generalized disclaimers. generalized disclaimers.
* Added the inetAssociatedResources auxiliary object class * Added the inetAssociatedResources auxiliary object class
skipping to change at line 1776 skipping to change at line 1769
to others, and derivative works that comment on or otherwise to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards procedures for copyrights defined in the Internet Standards
Hall I-D Expires: December 2003 [page 39]
process must be followed, or as required to translate it into process must be followed, or as required to translate it into
languages other than English. languages other than English.
The limited permissions granted above are perpetual and will not The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns. be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Hall I-D Expires: December 2003 [page 40] Hall I-D Expires: December 2003 [page 38]
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/