draft-ietf-crisp-firs-core-02.txt   draft-ietf-crisp-firs-core-03.txt 
INTERNET-DRAFT Eric A. Hall INTERNET-DRAFT Eric A. Hall
Document: draft-ietf-crisp-firs-core-02.txt July 2003 Document: draft-ietf-crisp-firs-core-03.txt August 2003
Expires: February, 2004 Expires: March, 2004
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 50 skipping to change at line 50
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.........................................3 3. The FIRS Namespace.........................................3
3.1. The domainComponent (dc=) Namespace Component...........4 3.1. The domainComponent (dc=) Namespace Component...........4
3.2. The inetResources Namespace Component...................4 3.2. The inetResources Namespace Component...................4
3.3. The Resource-Specific Namespace Component...............4 3.3. The Resource-Specific Namespace Component...............5
3.4. Referrals...............................................5 3.4. Attribute References....................................5
3.4.1. Subordinate reference referrals...................7 3.5. Referrals...............................................6
3.4.2. Continuation reference referrals..................8 3.5.1. Referral source entries...........................6
4. Global FIRS Object Classes and Attributes..................8 3.5.2. Referral target data..............................7
4.1. The inetResources Object Class..........................9 3.5.3. Subordinate reference referrals..................11
4.1.1. Naming syntax.....................................9 3.5.4. Continuation reference referrals.................12
4.1.2. Schema definition.................................9 4. Global FIRS Object Classes and Attributes.................12
4.1.3. Example..........................................12 4.1. The inetResources Object Class.........................13
4.2. The inetAssociatedResources Object Class...............13 4.1.1. Naming syntax....................................13
4.2.1. Naming syntax....................................13 4.1.2. Schema definition................................13
4.2.2. Schema definition................................13 4.1.3. Example..........................................16
4.2.3. Example..........................................15 4.2. The inetAssociatedResources Object Class...............17
4.3. The referral Object Class..............................15 4.2.1. Naming syntax....................................17
5. Global Query Processing Rules.............................16 4.2.2. Schema definition................................17
5.1. Query Pre-Processing...................................17 4.2.3. Example..........................................19
5.2. Query Bootstrap Models.................................18 4.3. The referral Object Class..............................19
5.2.1. Targeted query processing........................19 5. Global Query Processing Rules.............................20
5.2.2. Top-down processing..............................20 5.1. Query Pre-Processing...................................21
5.2.3. Bottom-up processing.............................23 5.2. Query Bootstrap Models.................................22
5.2.4. SRV processing...................................26 5.2.1. Targeted query processing........................23
5.3. Query Processing.......................................27 5.2.2. Top-down processing..............................24
5.3.1. The firsVersion server control...................27 5.2.3. Bottom-up processing.............................27
5.3.2. Matching filters.................................28 5.2.4. SRV processing...................................30
5.3.3. Query-volume restrictions........................30 5.3. Query Processing.......................................31
5.3.4. Authentication restrictions......................30 5.3.1. The inetResourcesControl server control..........31
5.3.5. Protocol and schema version controls.............31 5.3.2. Matching filters.................................34
5.4. Referral Processing....................................32 5.3.3. Query-volume restrictions........................36
6. Security Considerations...................................36 5.3.4. Authentication restrictions......................37
7. IANA Considerations.......................................36 5.3.5. Extended attribute ACLs..........................37
8. Normative References......................................36 5.3.6. Protocol and schema version controls.............39
9. Changes from Previous Versions............................38 5.4. Referral Processing....................................40
10. Author's Address..........................................40 6. Security Considerations...................................42
11. Acknowledgments...........................................41 7. IANA Considerations.......................................42
12. Full Copyright Statement..................................41 8. Normative References......................................42
9. Changes from Previous Versions............................44
10. Author's Address..........................................47
11. Acknowledgments...........................................47
12. Full Copyright Statement..................................48
Hall I-D Expires: February 2004 [page 2] Hall I-D Expires: March 2004 [page 2]
1. Introduction 1. Introduction
This specification defines the core object classes, attributes, This specification defines the core object classes, attributes,
syntax rules, matching filters, and operational behaviors for the syntax rules, matching filters, and operational behaviors for the
FIRS service as a whole. Refer to [FIRS-ARCH] for information on FIRS service as a whole. Refer to [FIRS-ARCH] for information on
the FIRS architecture, and the resource-specific specifications the FIRS architecture, and the resource-specific specifications
for definitions and rules which govern each of the different for definitions and rules which govern each of the 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
skipping to change at line 116 skipping to change at line 120
that set, which currently includes [FIRS-ARCH], [FIRS-DNS], [FIRS- that set, which currently includes [FIRS-ARCH], [FIRS-DNS], [FIRS-
DNSRR], [FIRS-CONTCT], [FIRS-ASN], [FIRS-IPV4] and [FIRS-IPV6]. DNSRR], [FIRS-CONTCT], [FIRS-ASN], [FIRS-IPV4] and [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 FIRS database. There are
There are three major components to this namespace, which are: three major components to this namespace, which are:
* The domainComponent entries. Each partition of the globally * The domainComponent entries. Each partition of the
distributed FIRS directory database is represented by a globally-distributed FIRS database is uniquely represented
sequence of domainComponent distinguished names. These by a sequence of domainComponent relative distinguished
sequences effectively identify the root scope of authority names. These sequences effectively identify the root scope
for each partition in the global directory database. of authority for each partition in the global directory
database. Partitions MAY be replicated across one or more
servers, but every instance of a specific partition MUST
use the same sequence of domainComponent relative
distinguished names.
* An inetResources entry. All of the FIRS-related resource- * An inetResources entry. All of the FIRS-related resource-
specific entries in the global database are required to be specific entries in the global database are required to be
stored within a well-known "cn=inetResources" container stored within a well-known "cn=inetResources" container
entry at the root of each directory partition. These well-
known entries act as application-specific access points
within the globally distributed directory database.
Hall I-D Expires: February 2004 [page 3] Hall I-D Expires: March 2004 [page 3]
entry at the root of each partition. These well-known
entries act as application-specific access points within
the globally distributed directory database, and also
provide some information about the partition and the
organization which manages that partition.
* 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. Note that an inetResources container or any of the resource-
specific entries MAY exist as referral stub entries that redirect
clients to other entries in the FIRS database.
The naming rules associated with the different portions of the
FIRS namespace are discussed in more detail below.
3.1. The domainComponent (dc=) Namespace Component 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 each partition certain portion of the global database. The root of each partition
is represented by a sequence of domainComponent relative is represented by a sequence of domainComponent relative
distinguished names (RDNs), as defined in RFC 2247 [RFC2247]. In distinguished names (RDNs), as defined in RFC 2247 [RFC2247]. In
this model, the scope-of-authority for a FIRS partition is derived this model, the scope-of-authority for a FIRS partition is derived
from a domain name in the global DNS directory, meaning that from a domain name in the global DNS directory, meaning that
skipping to change at line 164 skipping to change at line 180
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 used in the [RFC3490] before the domainComponent RDNs are used in the
directory database or LDAP messages. directory database or LDAP messages.
3.2. The inetResources Namespace Component 3.2. The inetResources Namespace Component
The FIRS-specific directory entries are segregated from other The FIRS-specific directory entries are segregated from other
application-specific entries by the use of a container entry with application-specific entries by the use of a container entry with
the MANDATORY name of "cn=inetResources". Any entry which is to be the MANDATORY name of "cn=inetResources".
located through FIRS MUST refer to this container entry.
Note that this rule specifically applies to entries which are to Every FIRS-specific resource that is to be located via the FIRS
be located by FIRS clients. The entries themselves MAY be service MUST be stored within the inetResources container entry.
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 Hall I-D Expires: March 2004 [page 4]
However, the entries themselves MAY exist as referrals which point
to entries in other LDAP partitions or namespace branches if this
is necessary or desirable (see section 3.5).
Every resource-specific entry also has a RDN which identifies that 3.3. The Resource-Specific Namespace Component
resource within the context of the inetResources container of any
given partition. Examples of these resource-specific entries can
Hall I-D Expires: February 2004 [page 4] Every resource-specific entry has a relative distinguished name
be seen in Figure 1 of [FIRS-ARCH], and include "cn=example.com" which identifies that resource within the context of the
which refers to the "example.com" DNS domain name resource, and inetResources container of a FIRS partition. Examples of these
"cn=admins@example.com" which refers to the "admins@example.com" entries can be seen in Figure 1 of [FIRS-ARCH], and include
contact resource. "cn=example.com" which refers to the "example.com" DNS domain
resource, and "cn=admins@example.com" which refers to the
"admins@example.com" contact resource.
Each of the FIRS resource-types have their own specific naming 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 the rules specifically apply to entries which are to be 3.4. Attribute References
located by FIRS clients. The entries themselves MAY be referrals
which reference entries in other locations if this is necessary or
desirable (see section 3.4), although it is important for
administrators to recognize that the referral targets will not be
locatable through FIRS.
3.4. Referrals Many of the core attributes provide pointers to other resources,
thereby allowing the client to initiate follow-up queries for
related data. For example, an entry for a domain name resource has
attributes for a variety of contacts for the domain name, and FIRS
clients are able to extract and use that data to generate
additional queries for any of those contact resources.
FIRS allows entries in the namespace to refer to other entries, as Pointers to resources that are stored within the global FIRS
necessary or desirable. This model allows certain entries to be database are generally provided as the identifier for the target
created as "placeholders" for other canonical entries which resource, using the syntax rules associated with the resource in
contain the actual data. question. For example, a pointer to the contact entry of
"admins@example.com" will be provided as that resource name, using
the syntax rules associated with contact names. Examples of this
usage form can be seen in Figure 1 of [FIRS-ARCH].
FIRS allows two methods for generating and processing these Note that traditional LDAP models often use URIs or distinguished
referrals: subordinate reference referrals, and continuation names to provide fully-qualified pointers to entries, although
reference referrals. these syntaxes usually require detailed knowledge about the target
resources or the servers for the target partition. However, FIRS
is much more distributed than traditional LDAP usages, and may
require pointing to data in an opaque partition, or where the
topology of the target partition is unknown. For these reasons,
attribute references in FIRS typically use the short name of the
target resource, with the expectation that the client will use the
attribute value as the query seed for new FIRS queries.
Subordinate reference referrals indicate that the search base in Hall I-D Expires: March 2004 [page 5]
the original query is an alias for some other entry, and that the However, pointers to resource data that is likely to be stored
query has to be restarted with a new search base in order for the outside the global FIRS database (such as a web page) is generally
search operation to be processed. Meanwhile, continuation provided as a URI so that any necessary application and/or
reference referrals indicate that the search was successfully protocol transfer services can be specified. For example, the
initiated and that some data has been found, but that additional inetResources object class provides an attribute for the
queries for additional resources are required for the query to be organization which manages the resource, with a secondary
completely exhausted. attribute for a URL associated with the target organization, thus
allowing additional (extra-directory) information to be specified
and retrieved where this would be useful.
Subordinate and continuation reference referrals use the ref In those cases where a URI provides an LDAP URL that references a
attribute and referral object class defined in RFC 3296 [RFC3296]. resource in the global FIRS directory, the URL data SHOULD use the
Each of these mechanisms use LDAP URLs as defined in RFC 2255 referral URL rules described in section 3.5.
[RFC2255] to carry referral data, with some additional FIRS-
specific restrictions.
Among these restrictions: 3.5. Referrals
* Referral source entries MUST comply with all of the Entries in the namespace can refer to other entries, as necessary
applicable namespace and schema rules. or desirable. Specifically, FIRS allows certain entries to be
created as "placeholders" for other entries which contain the
canonical data, and also allows "stub" child entries to provide
reference pointers to additional data.
Hall I-D Expires: February 2004 [page 5] LDAP provides several methods for conveying and processing these
* Referral targets MUST use the domainComponent ("dc=") kinds of referrals, although FIRS only makes specific use of
naming syntax for their directory partitions. Although subordinate reference referrals and continuation reference
other naming syntaxes are implicitly allowed by [RFC3296], referrals. Subordinate reference referrals indicate that the
those syntaxes are only guaranteed to be resolvable if they search base in the original query is an alias for some other
use domainComponent sequences. entry, and that the query has to be restarted with a new search
base in order for the search operation to be processed. Meanwhile,
continuation reference referrals indicate that the search was
successfully initiated and that some data has been found, but that
additional queries for additional resources are required for the
query to be completely exhausted.
* Referral targets are encouraged to reside in an 3.5.1. Referral source entries
inetResources container entry, although this is not
required. For example, a general-purpose administrative
contact entry may need to refer to a user-specific contact
entry in another container if this is necessary, and this
kind of usage is allowed.
* Referral sources and targets MUST have the same resource- Referral entries can be used in FIRS in two distinct scenarios,
specific object class defined (for example, the referral with each scenario having different naming requirements for the
source and target for a DNS domain resource would both have referral sources.
the inetDnsDomain object class defined). This is a
prerequisite for the proper handling of the search filters
specified in this document.
* Referral targets MAY exist as referrals to other entries, In the first instance, specific entries can be defined as
but recursive referrals are discouraged. Clients MAY referrals so that queries for the entry always generate a single
discontinue referral processing after a reasonable amount referral. This may be necessary when an entire inetResources
of effort (eight referrals is a suggested default value). container entry needs to be redirected to another inetResources
container entry in another tree, but can also be useful when
entries only exist as placeholders for other entries.
* At least one of the URLs in a referral MUST specify the Hall I-D Expires: March 2004 [page 6]
LDAP service type. Furthermore, FIRS clients MUST disregard For example, a registrar can create referral entries for variant
all referral URLs that do not specify the LDAP service domain names whenever a canonical domain name is registered, with
type. Although general-purpose LDAP referrals are allowed the variant entries only providing referrals to the canonical
to use any kind of protocol, FIRS clients have a entry. Similarly, an entry for the host named "www.example.com"
fundamental obligation to automatically process referrals, could exist as a referral which pointed to the domain name entry
which precludes the use of ambiguous services and their for "www-1.example.net". In these scenarios, users who generate
data formats. queries for the alias domain name entries would always get
referred to the canonical domain name entries.
* LDAP URLs MAY specify host identifiers and port numbers, Most entries are expected to provide some kind of information, and
but neither of these elements are required. in this kind of situation, the canonical entry will have data, but
will need to be able to generate referrals to one or more other
entries where additional data about the resource can be retrieved.
For example, the entries in the partition for the "com" domain
registry can provide basic information about a domain, but can
also provide a referral to the domain registrar, while the
registrar can provide another referral to the domain operator.
* If a matching filter and/or assertion value needs to be In these cases, each partition would need to have an entry for the
specified in a referral, they MUST be specified in the resource in question, while child entries underneath each of those
filter element of the referral's LDAP URL. Matching filters entries would be used to generate the necessary referrals. For
and/or assertion values MUST NOT be specified unless the example, the "example.com" domain would likely exist as a
referral source needs to explicitly reference a specific canonical entry within a registry's partition, with that entry
target entry in a specific partition. This should only be providing information that the registry had about that domain
necessary in those cases where the referral target entry name. Meanwhile, the registry could have a child entry underneath
the canonical entry which provided a referral to the registrar's
partition, and so forth.
Hall I-D Expires: February 2004 [page 6] The relative distinguished name of a referral child entry is
would not normally be located (most likely due to a usually irrelevant, and can therefore be defined according to
radically different entry name). local policy rather than fixed rules. However, operators SHOULD
NOT use names that are likely to match against searches for other
resources. In the general case, using generalized relative
distinguished names such as "cn=ref1" or the like would be the
safest practice.
* The attribute, scope and extension elements of LDAP URLs 3.5.2. Referral target data
will be ignored by the client, and SHOULD NOT be provided.
* LDAP URLs MUST use a URL-safe format. For example, the IPv4 Referral entries MUST use the ref attribute and referral object
and IPv6 network address syntaxes defined in this document class, as defined in RFC 3296 [RFC3296].
make use of the forward-slash ("/") character to indicate a
subnet prefix, and if this character needs to be provided
in a URL, it must be provided in the escaped form ("%2F" in
this example). Similarly, some domain names and email
addresses contain UTF-8 character data, and some of those
character codes will need to be escaped in order to be
passed as URL data.
* Providers MUST NOT restrict values to verifiable entries The referral target is provided to the client with the ref
from local partitions. Providers MAY validate the referral attribute, which provides a URI as the destination pointer,
targets in URLs, but a lack of knowledge regarding a target although there are some additional FIRS-specific restrictions
MUST NOT be treated as sufficient cause to prevent the which are as follows:
referral target from being specified.
The rules for processing referral URLs are given in section 5.4. Hall I-D Expires: March 2004 [page 7]
* At least one of the URLs in a referral MUST be an LDAP URL
as specified in RFC 2255 [RFC2255], and FIRS clients MUST
ignore all non-LDAP URIs. Note that general-purpose LDAP
referrals are allowed to use any protocol, but FIRS clients
have a requirement to automatically process referrals, and
this requirement precludes the use of ambiguous services
and their data formats. As such, every FIRS referral MUST
specify at least one LDAP URL, and FIRS clients MUST only
use the LDAP URLs.
* Referral targets MUST use domainComponent ("dc=") naming
syntax for target partitions. If a referral needs to
specify an exact partition or container for the referral
target, the path to the referral target MUST be provided as
the search base of the LDAP URLs, and this data MUST be
used by FIRS clients when the subsequent query is built.
* The LDAP URL data MUST be escaped prior to being sent. For
example, domain names and contact names can contain UTF-8
character data, and some of those character codes will need
to be escaped in order to be passed as URL data. Similarly,
the IPv4 and IPv6 network address syntaxes defined in this
document make use of the forward-slash ("/") character to
indicate a subnet prefix, and if this character needs to be
provided in a URL, it must be provided in the escaped form
("%2F" in this example).
In the general sense, referrals SHOULD NOT provide any more
information about the referral target than absolutely necessary.
For example, if a referral source for a domain name resource needs
to reference a referral target for another domain name resource,
then only the resource type and identifier SHOULD be provided
(this will give the client enough information to begin a new
query), while data such as the target partition or LDAP server
SHOULD NOT be provided since the authoritative forms of this
information will be detected as part of the subsequent query's
bootstrapping process. With this in mind, the following
recommendations apply to referral targets in the general sense,
and SHOULD be followed:
* In those cases where a referral points to a FIRS resource
of a known type and name (E.G., a domain name, or an IPv4
address), the referral URL MUST specify the matching filter
and assertion value of the referral target. For example, a
referral that points to a DNS domain resource MUST provide
Hall I-D Expires: March 2004 [page 8]
the inetDnsDomainMatch matching filter and value in the
filter element of the LDAP URL (such as providing
"(1.3.6.1.4.1.7161.1.3.0.1:=example.com)" for a referral to
the "example.com" DNS domain). Clients MUST use this data
to seed the resource type and assertion value of the
subsequent query if it is provided.
* In those cases where a referral points to a FIRS resource
in a particular partition, the referral URL MUST specify
the search base element. For example, if an entry for the
"example.com" domain name resource in the "com" partition
needs to specify the "example.com" domain name resource in
the "registrar.com" partition, then the referral MUST
specify "dc=registrar,dc=com" in the search base element of
the LDAP URL. Clients MUST use this data to seed the boot
partition of the subsequent query if it is provided.
* In those cases where a referral points to some other kind
of entry, the referral target SHOULD specify as little
information as possible, while still providing an adequate
reference. For example, if a referral needs to point to a
contact in an alternate container of a specific partition,
the full path to the referral target SHOULD be specified in
the search base element of the URL. Clients MUST use the
additional information if it is provided.
* In the general case, referral sources and targets SHOULD
have the same resource-specific object classes defined,
although referral targets MAY specify other resource types
if needed. For example, the referral source and target for
a DNS domain resource should both have the inetDnsDomain
object class defined, although a referral may point to an
IPv4 host address if this is necessary. If a referral
target is known to have a different object class than the
referral source, a matching filter for the referral target
MUST be provided in the filter element of the LDAP URLs,
and this data MUST be used by FIRS clients when the
subsequent query is built.
* LDAP URLs SHOULD NOT provide host identifiers or port
numbers unless this is absolutely necessary, since the
client will usually discover this information during the
bootstrap process. If a referral provides this information,
it MUST be used by FIRS clients when the subsequent query
is built.
Hall I-D Expires: March 2004 [page 9]
* Attribute lists, scope filters, and URL extensions SHOULD
NOT be provided, and these elements MUST be ignored by FIRS
clients unless an applicable specification details explicit
behavior for these elements.
* The operators of a partition MUST NOT restrict referral
data to verifiable referral targets. Providers MAY validate
the referral targets in URLs, but a lack of knowledge
regarding a target MUST NOT be treated as sufficient cause
to prevent the referral target from being specified.
* Referral targets MAY themselves be referrals to other
entries, but recursive referrals are discouraged. Clients
MAY discontinue referral processing after a reasonable
amount of effort (eight referrals is a reasonable
threshold, but the actual amount of processing is left to
the discretion of the clients).
An example referral is illustrated in Figure 1 of [FIRS-ARCH]. In
that example, the referral data provides an inetDnsDomainMatch
matching filter with the explicit assertion value of
"www-1.example.net". This data would inform the client of the
resource-type to be queried and the assertion value to use, which
collectively would give the client everything needed to begin
bootstrapping a new query.
As another example, a referral to a specific entry could look like
the following:
ldap://cn=admins@example.com,cn=inetResources,
dc=example,dc=com
In that example, the referral is pointing to an explicit entry in
an explicit container in an explicit partition. Although the
client would not be able to tell what kind of resource was being
queried for, it would be able to determine the resource-type once
an answer was received, based on the object class values of
resulting entry.
The client-side rules for processing referral URLs are given in
section 5.4.
Note that the "superior reference referral" defined in RFC 2251 Note that the "superior reference referral" defined in RFC 2251
[RFC2251] used as a "default referral" for out-of-scope searches [RFC2251] used as a "default referral" for out-of-scope searches
is explicitly unsupported in FIRS; any superior reference is explicitly unsupported in FIRS. Superior reference referrals
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 Hall I-D Expires: March 2004 [page 10]
detail below. which are encountered as a part of this service are to be treated
as errors and silently ignored.
3.4.1. Subordinate reference referrals 3.5.3. Subordinate reference referrals
Subordinate reference referrals are defined in [RFC3296], and are Subordinate reference referrals are defined in [RFC3296], and are
returned whenever the search base specified in a query exists as a returned whenever the search base specified in a query exists as a
referral to some other entry. This means that the query MUST be referral to some other entry. This means that the query MUST be
restarted, using the referral target as the new search base. restarted with the referral target.
Any entries MAY be defined as subordinate reference referrals Specifically, subordinate reference referrals are defined in
which point to other entries. However, almost all of the search [RFC3296], and use the SearchResultDone response with a Referral
functions defined for use by this service use the inetResources result code as defined in [RFC2251]. Subordinate reference
container entry as the search base (the exceptions to this rule referrals use a subset of the labeledURI syntax as defined in
are targeted searches for explicit entries), so subordinate [RFC2079], and use the syntax definitions from [RFC2255] when LDAP
reference referrals will most commonly be seen when an URLs in particular are provided, although section 3.5.2 of this
document also defines additional restrictions on the allowable URL
syntax. This condition means that the current search operation
cannot proceed past this point, and the search MUST be restarted.
This will most often occur when the inetResources entry for a
partition has been redirected to another directory partition.
Hall I-D Expires: February 2004 [page 7] Almost all of the search functions used with FIRS use the
inetResources container entry as the search base (the exceptions
to this rule are targeted searches for explicit entries), so
subordinate reference referrals will most commonly be seen when an
inetResources container entry has been redirected to an inetResources container entry has been redirected to an
inetResources container in another directory partition. 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 and clients MUST be prepared to accept and process any subordinate
process any subordinate reference referrals in answer sets. reference referrals they receive.
When subordinate reference referrals are used for this purpose, When subordinate reference referrals are used, the referral source
the referral source MUST be defined with the referral object MUST be defined with the referral object class, and MUST also be
class, and MUST also be defined with the appropriate object class defined with the appropriate object class for that resource type.
for that resource type. For example, a "cn=inetResources" entry For example, a "cn=inetResources" entry which provided a
which provided a subordinate reference referral would need to have subordinate reference referral would need to have both the
both the referral and inetResources object classes defined, while referral and inetResources object classes defined, while a DNS
a DNS domain resource such as "dc=example.com" would need to have domain resource such as "dc=example.com" would need to have both
both the referral and inetDnsDomain object classes defined (among the referral and inetDnsDomain object classes defined (among the
the other object class definitions which were required for that 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
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.
3.4.2. Continuation reference referrals Hall I-D Expires: March 2004 [page 11]
3.5.4. Continuation reference referrals
Continuation reference referrals are defined in RFC 2251 Continuation reference referrals are defined in RFC 2251
[RFC2251], and are returned when a search operation has been [RFC2251], and are returned when a search operation has been
successfully processed but the answer data also includes referrals successfully processed but the answer data also includes referrals
to other entries. These referrals are often provided as to other entries. These referrals are usually provided as
supplemental data to an answer set, although this is not required supplemental data to an answer, although it's also possible for a
(a continuation reference referral can be the only response, but continuation reference referral to be the only data in an answer.
it won't be the only response in the common case).
Servers MUST support the use of continuation reference referrals Specifically, continuation reference referrals use the
for this purpose, and clients MUST be prepared to accept and SearchResultReference response, which is defined and described in
process any subordinate reference referrals in answer sets. section 4.5.3 of [RFC2251]. Continuation reference referrals use a
subset of the labeledURI syntax as defined in [RFC2079], and use
the syntax definitions from [RFC2255] when LDAP URLs in particular
are to be provided, although section 3.5.2 of this document also
defines additional restrictions on the allowable URL syntax. This
condition means that the current search operation has partially
succeeded, but that additional searches SHOULD be started in order
for all of the answer data to be retrieved (in many cases, no
answer data will be provided, and in those situations, new queries
will be required for any data to be retrieved). This will occur
whenever the assertion value of a search has matched a resource
entry which is being managed by another directory partition, and
can occur with any of the search operations described in this
document.
Servers MUST support the use of continuation reference referrals,
and clients MUST be prepared to accept and process any subordinate
reference referrals that they receive.
When continuation reference referrals are used for this purpose, 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.
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.
Hall I-D Expires: February 2004 [page 8] Hall I-D Expires: March 2004 [page 12]
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
skipping to change at line 402 skipping to change at line 591
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 for use with FIRS are subordinate to the inetResources defined for use with FIRS are subordinate to the inetResources
object class and inherit its attributes. object class and inherit its attributes.
Hall I-D Expires: February 2004 [page 9] Hall I-D Expires: March 2004 [page 13]
The schema definition for the inetResources object class is as The schema definition for the inetResources object class is as
follows: follows:
inetResources inetResources
( 1.3.6.1.4.1.7161.1.1.1 ( 1.3.6.1.4.1.7161.1.1.1
NAME 'inetResources' NAME 'inetResources'
DESC 'The inetResources container for the FIRS service' DESC 'The inetResources container for the FIRS service'
SUP top SUP top
STRUCTURAL STRUCTURAL
MUST cn MUST cn
MAY ( inetPrivateIdentifier $ o $ ou $ description $ MAY ( inetLocalIdentifier $ 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 $
inetGeneralDisclaimer ) ) inetGeneralDisclaimer ) )
The attributes from the inetResources object class are described The attributes from the inetResources object class are described
below: below:
skipping to change at line 447 skipping to change at line 636
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: February 2004 [page 10] Hall I-D Expires: March 2004 [page 14]
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
telephoneNumber, see [RFC2256], section 5.21 telephoneNumber, see [RFC2256], section 5.21
inetPrivateIdentifier inetLocalIdentifier
( 1.3.6.1.4.1.7161.1.1.2 ( 1.3.6.1.4.1.7161.1.1.2
NAME 'inetPrivateIdentifier' NAME 'inetLocalIdentifier'
DESC 'Operator-specific identification tag for this entry' DESC 'Provider name for this entry'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
inetResourceComments inetResourceComments
( 1.3.6.1.4.1.7161.1.1.3 ( 1.3.6.1.4.1.7161.1.1.3
NAME 'inetResourceComments' NAME 'inetResourceComments'
DESC 'General comments about this entry' DESC 'General comments about this entry'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
skipping to change at line 488 skipping to change at line 677
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
inetGeneralContacts inetGeneralContacts
( 1.3.6.1.4.1.7161.1.1.5 ( 1.3.6.1.4.1.7161.1.1.5
NAME 'inetGeneralContacts' NAME 'inetGeneralContacts'
DESC 'Contacts for general administrative issues.' DESC 'Contacts for general administrative issues.'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.7161.1.7.1 ) SYNTAX 1.3.6.1.4.1.7161.1.7.1 )
Hall I-D Expires: February 2004 [page 11] Hall I-D Expires: March 2004 [page 15]
inetAbuseContacts inetAbuseContacts
( 1.3.6.1.4.1.7161.1.1.6 ( 1.3.6.1.4.1.7161.1.1.6
NAME 'inetAbuseContacts' NAME 'inetAbuseContacts'
DESC 'Contacts for reporting abusive behavior or DESC 'Contacts for reporting abusive behavior or
acceptable-use policy violations.' acceptable-use policy violations.'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.7161.1.7.1 ) SYNTAX 1.3.6.1.4.1.7161.1.7.1 )
inetSecurityContacts inetSecurityContacts
( 1.3.6.1.4.1.7161.1.1.7 ( 1.3.6.1.4.1.7161.1.1.7
skipping to change at line 535 skipping to change at line 724
| |
+-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.
Hall I-D Expires: February 2004 [page 12] Hall I-D Expires: March 2004 [page 16]
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.
skipping to change at line 583 skipping to change at line 772
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 The inetAssociatedResources object class MUST NOT be associated
with an entry that only exists as a referral source. 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
Hall I-D Expires: February 2004 [page 13] Hall I-D Expires: March 2004 [page 17]
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:
inetAssociatedResources inetAssociatedResources
( 1.3.6.1.4.1.7161.1.2.1 ( 1.3.6.1.4.1.7161.1.2.1
NAME 'inetAssociatedResources' NAME 'inetAssociatedResources'
skipping to change at line 610 skipping to change at line 799
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.2.2 ( 1.3.6.1.4.1.7161.1.2.2
NAME 'inetAssociatedAsNumbers' NAME 'inetAssociatedAsNumbers'
DESC 'Autonomous system numbers associated with this DESC 'Autonomous system numbers associated with this
Internet resource.' Internet resource.'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.7161.1.4.1 ) SYNTAX 1.3.6.1.4.1.7161.1.7.0 )
inetAssociatedContacts inetAssociatedContacts
( 1.3.6.1.4.1.7161.1.2.3 ( 1.3.6.1.4.1.7161.1.2.3
NAME 'inetAssociatedContacts' NAME 'inetAssociatedContacts'
DESC 'Other contacts associated with this Internet DESC 'Other contacts associated with this Internet
resource.' resource.'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.7161.1.7.1 ) SYNTAX 1.3.6.1.4.1.7161.1.4.0 )
inetAssociatedDnsDomains inetAssociatedDnsDomains
( 1.3.6.1.4.1.7161.1.2.4 ( 1.3.6.1.4.1.7161.1.2.4
NAME 'inetAssociatedDnsDomains' NAME 'inetAssociatedDnsDomains'
DESC 'DNS domains associated with this Internet resource.' DESC 'DNS domains associated with this Internet resource.'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.7161.1.1.1 ) SYNTAX 1.3.6.1.4.1.7161.1.3.0 )
Hall I-D Expires: February 2004 [page 14] Hall I-D Expires: March 2004 [page 18]
inetAssociatedIpv4Networks inetAssociatedIpv4Networks
( 1.3.6.1.4.1.7161.1.2.5 ( 1.3.6.1.4.1.7161.1.2.5
NAME 'inetAssociatedIpv4Networks' NAME 'inetAssociatedIpv4Networks'
DESC 'IPv4 networks associated with this Internet DESC 'IPv4 networks associated with this Internet
resource.' resource.'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.7161.1.2.1 ) SYNTAX 1.3.6.1.4.1.7161.1.5.0 )
inetAssociatedIpv6Networks inetAssociatedIpv6Networks
( 1.3.6.1.4.1.7161.1.2.6 ( 1.3.6.1.4.1.7161.1.2.6
NAME 'inetAssociatedIpv6Networks' NAME 'inetAssociatedIpv6Networks'
DESC 'IPv6 networks associated with this entry.' DESC 'IPv6 networks associated with this entry.'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.7161.1.3.1 ) SYNTAX 1.3.6.1.4.1.7161.1.6.0 )
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.
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]
skipping to change at line 671 skipping to change at line 860
value: "2.0.192.in-addr.arpa" 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.
4.3. The referral Object Class 4.3. The referral Object Class
Entries use the referral object class to define subordinate Entries use the referral object class to define subordinate
reference referrals and continuation reference referrals, thereby reference referrals and continuation reference referrals, thereby
facilitating the programmatic redirection of queries in support of facilitating the programmatic redirection of queries in support of
the referral mechanisms defined in section 3.4. the referral mechanisms defined in section 3.5.
Hall I-D Expires: February 2004 [page 15] Hall I-D Expires: March 2004 [page 19]
Referral entries MUST conform to the schema specification defined Referral entries MUST conform to the schema specification defined
in [RFC3296]. in [RFC3296].
Referral sources MUST NOT contain any user-definable attributes Referral sources MUST NOT contain any user-definable attributes
(other than the mandatory naming attribute), and MUST NOT have any (other than the mandatory naming attribute), and MUST NOT have any
subordinate child entries. subordinate child entries.
Refer to section 3.4 for the rules that govern referral URLs in Refer to section 3.5 for the rules that govern referral URLs in
FIRS. Refer to section 5.4 for information on processing referral FIRS. Refer to section 5.4 for information on processing referral
URLs in FIRS. 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:
skipping to change at line 720 skipping to change at line 909
* 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
Hall I-D Expires: February 2004 [page 16] Hall I-D Expires: March 2004 [page 20]
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 limited to 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"), and this single piece of information must ("admins@example.com"), and this single piece of information must
skipping to change at line 768 skipping to change at line 957
named resource. In most cases, the authoritative partition named resource. In most cases, the authoritative partition
will be a variation of the input query string, but this is will be a variation of the input query string, but this is
not always the case. For example, the default partition for not always the case. For example, the default partition for
an email address will be extrapolated from the domain an email address will be extrapolated from the domain
component of the email address itself, while the component of the email address itself, while the
authoritative partition for an ASN uses a reserved authoritative partition for an ASN uses a reserved
(special-purpose) domain name. In some cases, the (special-purpose) domain name. In some cases, the
authoritative partition may change during the subsequent authoritative partition may change during the subsequent
query-processing steps. query-processing steps.
Hall I-D Expires: February 2004 [page 17] Hall I-D Expires: March 2004 [page 21]
* Determine the search base for the query. Each resource type * Determine the search base for the query. Each resource type
has resource-specific query-processing rules which will has resource-specific query-processing rules which will
dictate how the authoritative partitions are mapped to the dictate how the authoritative partitions are mapped to the
search base. In some cases, the cn=inetResources container search base. In some cases, the cn=inetResources container
entry in the authoritative partition will be used "as-is", entry in the authoritative partition will be used "as-is",
while in other cases, the cn=inetResources container entry while in other cases, the cn=inetResources container entry
in a delegation parent of the authoritative partition will in a delegation parent of the authoritative partition will
be used instead. In some cases, the search base may change be used instead. In some cases, the search base may change
during subsequent query-processing steps. during subsequent query-processing steps.
skipping to change at line 814 skipping to change at line 1003
process follows the same basic path (issuing the LDAPv3 query, process follows the same basic path (issuing the LDAPv3 query,
following referrals, and so forth). following referrals, 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.
Hall I-D Expires: February 2004 [page 18] Hall I-D Expires: March 2004 [page 22]
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 specified LDAP server for a lookups, in that a client queries a specified LDAP server for a
particular resource under the assumption that the named resource particular resource under the assumption that the named resource
exists on the named server. If the known resource or the known exists on the named server. If the known resource or the known
server do not exist or cannot be located (notwithstanding any server do not exist or cannot be located (notwithstanding any
referrals which may be returned), then the query process exits. referrals which may be returned), then the query process exits.
The targeted model can be used when an application-specific The targeted model can be used when an application-specific
skipping to change at line 861 skipping to change at line 1050
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: February 2004 [page 19] Hall I-D Expires: March 2004 [page 23]
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 5.4 and restart according to the rules described in section 5.4 and restart
the query process at step 5.2.1.a. For each continuation the query process at step 5.2.1.a. For each continuation
skipping to change at line 909 skipping to change at line 1098
resources under the top-level domains themselves, such as queries resources under the top-level domains themselves, such as queries
for domain delegations under the "com" zone. for domain delegations under the "com" zone.
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: February 2004 [page 20] Hall I-D Expires: March 2004 [page 24]
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 957 skipping to change at line 1146
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: February 2004 [page 21] Hall I-D Expires: March 2004 [page 25]
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 RFC 2782 [RFC2782]. formula described in RFC 2782 [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 1001 skipping to change at line 1190
query processes for each referral at step 5.2.2.b, query processes for each referral at step 5.2.2.b,
appending the output from these searches to the appending the output from these searches to the
current output. 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: February 2004 [page 22] Hall I-D Expires: March 2004 [page 26]
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
skipping to change at line 1049 skipping to change at line 1238
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: February 2004 [page 23] Hall I-D Expires: March 2004 [page 27]
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 1095 skipping to change at line 1284
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: February 2004 [page 24] Hall I-D Expires: March 2004 [page 28]
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 1143 skipping to change at line 1332
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 5.4 and according to the rules described in section 5.4 and
Hall I-D Expires: February 2004 [page 25] Hall I-D Expires: March 2004 [page 29]
restart the query process at step 5.2.3.d. For each restart the query process at step 5.2.3.d. For each
continuation reference referral, display the answer continuation reference referral, display the answer
data received so far, process the LDAP URLs according data received so far, process the LDAP URLs according
to the rules described in section 5.4 and start new to the rules described in section 5.4 and start new
query processes for each referral at step 5.2.3.d, query processes for each referral at step 5.2.3.d,
appending the output from these searches to the appending the output from these searches to the
current output. 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
skipping to change at line 1191 skipping to change at line 1380
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".
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.
Hall I-D Expires: February 2004 [page 26] Hall I-D Expires: March 2004 [page 30]
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
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.
skipping to change at line 1218 skipping to change at line 1407
using the next-preferred connection target. using the next-preferred connection target.
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 SHOULD conform with. These rules which clients and servers SHOULD conform with. These
guidelines are discussed in the following sections. guidelines are discussed in the following sections.
5.3.1. The firsVersion server control 5.3.1. The inetResourcesControl server control
When a client successfully binds to a FIRS-compatible server, the The inetResourcesControl server control is the master control
server SHOULD return the "firsVersion" server control described object for the FIRS service, and provides the version of each
below. object class that is available for use on the current server, and
also lists the matching filters that the server is willing to use
for each of the listed object classes.
The firsVersion control has an OID of 1.3.6.1.4.1.7161.1.0.0. The The OID for inetResourcesControl is 1.3.6.1.4.1.7161.1.0.0. This
value field of the control MUST provide the OIDs of the FIRS- value MUST be provided in the OID field of the control.
specific object classes which the server supports, with each of
the OIDs being separated by Dollar Sign characters ("$"). At a
minimum, this field SHOULD contain the OID for the inetResources
object class described in section 4.1, but MAY contain the OID for
any of the resource-specific object classes (such as inetDnsDomain
or inetIpv4Network).
The OID values MUST NOT be provided unless the server fully The value section of the inetResourcesControl contains nested
supports all of the schema definitions associated with that object sequences of data. The first element in each sequence identifies
class, specifically including any attributes, syntaxes and an object class, while first nested element identifies a matching
matching filters defined for use with that resource type. For filter which may be used for that object class, while the next set
of nested elements identify the attributes that may be used with
each matching filter.
Hall I-D Expires: February 2004 [page 27] Hall I-D Expires: March 2004 [page 31]
example, if a server "supports" the inetDnsDomain object class but The structure of the value section of inetResourcesControl is
does not support the inetDnsDomainSyntax naming syntax or does not illustrated by the following ASN.1 definition:
support the inetDnsDomainMatch matching filter, then that server
MUST NOT return the OID for the inetDnsDomain object class.
Clients MAY use the absence or contents of the firsVersion control inetResourcesControlValue ::= SEQUENCE {
to choose a different server, but SHOULD NOT use the absence or objectClass LDAPOID,
contents of this control alone to abort processing. E.G., if none matchingFilters SEQUENCE OF matchingFilter,
of the servers provide the firsVersion control, then the client attributes SEQUENCE OF attribute }
can be said to have run out of servers, and MAY abort the current
query process.
Clients MAY also use the absence or contents of the firsVersion matchingFilter ::= LDAPSTRING
control to perform local processing which would otherwise usually
be performed by the server. For example, if the server does not attribute ::= LDAPOID
advertise support for the inetDnsDomain object class, the client
MAY issue discrete searches for resources, instead of relying on Each object class, matching filter, and attribute MUST be
the server for these functions. However, if the server does presented as a string. Object classes MUST be listed as OIDs so
advertise support for a particular resource type, the client MUST that clients can determine the supported object classes according
make use of the server-provided services. to their version. Matching filters MUST also be provided as OIDs,
except for the "stock" matching filter operators defined in
[RFC2251], which MUST be presented with the textual identifiers
shown therein. Attributes MUST be listed with their textual
identifiers.
At a minimum, servers MUST support the equalityMatch and
extensibleMatch filters from [RFC2251] for every object class
listed, and SHOULD always declare these filters. Furthermore,
servers MUST support the "cn" attribute for every matching filter,
and SHOULD declare these attributes. The Asterisk character ("*")
MAY be provided as a wildcard to indicate that the server will
accept any matching filter for the associated object class, or to
indicate that the server will accept any attribute for the
associated matching filter. Servers MUST allow any supported
matching filter to be used as part of an extensibleMatch
operation, and clients MAY assume that any allowed operation will
be acceptable as part of an extensibleMatch.
Hall I-D Expires: March 2004 [page 32]
An example of an inetResourcesControl server control is shown
below for illustration purposes:
{ 1.3.6.1.4.1.7161.1.0.0, FALSE, {
1.3.6.1.4.1.7161.1.1.1 {
equalityMatch {*},
extensibleMatch {*} } }, {
1.3.6.1.4.1.7161.1.3.1 {
1.3.6.1.4.1.7161.1.3.0.1 {*},
equalityMatch {*},
substringMatch {cn},
extensibleMatch {*} } } }
Figure 3: An example inetResourcesControl server control.
In the example shown in Figure 3, the inetResourcesControl type is
identified by the OID of 1.3.6.1.4.1.7161.1.0.0, while the
criticality field is set to FALSE, as per the requirements in
[RFC2251]. The contents of the control value identify the current
OID for the inetResources object class along with the [RFC2251]
textual identifiers of the equalityMatch and extensibleMatch
operators, each of which will accept any attributes. Figure 3 also
identifies the OID for the inetDnsDomain object class along with
the OID for the inetDnsDomainMatch and the [RFC2251] textual
identifiers for the equalityMatch, substringMatch and
extensibleMatch operators, although the substringMatch filter is
only advertised for use with the "cn" attribute.
FIRS-compliant servers SHOULD return the inetResourcesControl
server control as an unsolicited response to a successful bind
request. Clients MUST use the OID of the inetResourcesControl for
the purpose of validating the contents of the control, and MUST
use the OIDs of the listed object classes to discover schema
versioning information.
Servers MAY restrict the contents of the inetResourcesControl
value according to the authenticated identity of the client. For
example, servers can choose to enable computationally-intense
searches for authorized users while refusing to provide the same
searches for anonymous users.
If a client does not receive a usable inetResourcesControl control
as part of the bind response, the client SHOULD issue a request
for the control before proceeding. If a client is still unable to
obtain a usable inetResourcesControl server control, the client
Hall I-D Expires: March 2004 [page 33]
MAY choose a different server for the partition, or MAY choose to
assume that the equalityMatch matching filter will be supported
for any of the known types, or MAY choose to undergo any other
recovery efforts. In any event, clients SHOULD NOT use the absence
or contents of the control to completely abort query processing
unless all of the servers for a partition have refused to provide
service to the client.
For example, if the server advertises support for the
inetDnsDomain object class but does not advertise support for the
inetDnsDomainMatch matching filter, the client MAY issue discrete
equality searches for each of the specific domain name resources
(note that this kind of query can fail to produce referrals in
some cases, but will usually produce at least some answers).
In all cases, if any given server advertises support for a
particular object class or matching filter, the client MUST make
use of the server-provided service.
5.3.2. Matching filters 5.3.2. 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.
skipping to change at line 1286 skipping to change at line 1553
in particular. Any queries for other resources SHOULD NOT in particular. Any queries for other resources SHOULD NOT
impose these restrictions. Also note that other documents impose these restrictions. Also note that other documents
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.
Hall I-D Expires: February 2004 [page 28] Hall I-D Expires: March 2004 [page 34]
The default values of an LDAPv3 search filter in FIRS are: The default values of an LDAPv3 search filter in FIRS are:
* Search base. The directory partition to be used in a search * Search base. The directory partition to be used in a search
will vary for each query operation. The methodology for will vary for each query operation. The methodology for
determining the current search base for a query is defined determining the current search base for a query is defined
by the query-processing protocols described in section 5.1, by the query-processing protocols described in section 5.1,
although FIRS searches are normally constrained to the although FIRS searches are normally constrained to the
"cn=inetResources" container of a particular directory "cn=inetResources" container of a particular directory
partition. partition.
* Scope. In order to support continuation reference referrals * Scope. In order to successfully locate referral stub child
(which are defined as referral entries beneath a resource- entries, clients MUST use a sub-tree scope for FIRS
specific entry), clients MUST use a sub-tree scope for FIRS
searches. Servers MUST NOT arbitrarily limit the scope of searches. Servers MUST NOT arbitrarily limit the scope of
search operations. search operations.
* Dereference aliases. Although the FIRS service does not * Dereference aliases. Although the FIRS service does not
make direct use of alias entries, they are not prohibited. make direct use of alias entries, they are not prohibited.
Clients SHOULD set the Dereference Aliases option to Clients SHOULD set the Dereference Aliases option to
"Always" for FIRS searches. Servers SHOULD dereference any "Always" for FIRS searches. Servers SHOULD dereference any
aliases which are encountered, where this is feasible (in aliases which are encountered, where this is feasible (in
particular, where the alias refers to another directory particular, where the alias refers to another directory
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
"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 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.
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 the
seconds if the client specifies a larger value. time limit if the client specifies a larger value.
Hall I-D Expires: February 2004 [page 29]
* 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
Hall I-D Expires: March 2004 [page 35]
the answer sets. Since excessive queries are likely to be the answer sets. Since excessive queries are likely to be
more burdensome than larger answer sets, this setting more burdensome than larger answer sets, this setting
SHOULD be set to FALSE. Resource-constrained clients (such SHOULD be set to FALSE. Resource-constrained clients (such
as PDAs) MAY set this value to TRUE, but these clients MUST as PDAs) MAY set this value to TRUE, but these clients MUST
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.
skipping to change at line 1358 skipping to change at line 1624
5.3.3. Query-volume restrictions 5.3.3. Query-volume restrictions
The restrictions listed in section 5.3.2 represent suggested The restrictions listed in section 5.3.2 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. limits they deem necessary or desirable.
Specifically, server operators MAY restrict the amount of Specifically, server operators MAY restrict the amount of
information provided to specific clients and/or users over a given information provided to specific clients and/or users over a given
amount of time, within reason. For example, servers MAY restrict amount of time, within reason. For example, servers MAY restrict
clients to an arbitrary number of queries per hour, per day, and clients to an arbitrary number of queries per-hour or per-day, or
so forth. Servers which refuse to process a query due to volume may impose mandatory time intervals between queries, and so forth.
policy SHOULD reject the connection and/or query using the Similarly, servers MAY restrict clients to an arbitrary number of
"unwillingToPerform" response code ("53"). answers over a given time period, such as limiting clients to 100
answers regardless of the number of queries which were used to
generate those answers.
Servers which refuse to process a query due to volume policy
SHOULD use the "unwillingToPerform" response code ("53") to inform
the client of these restrictions, and SHOULD provide explanatory
text in the error message. These errors SHOULD be generated when
the session is first established, if at all possible.
In the worst cases, servers MAY deny all service to abusive
clients. This can be implemented by rejecting the TCP connection
outright, or by providing an explanatory error early in the
session, or at any other point.
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 a known permanent failures. Clients MAY retry the operations if a known
error condition is corrected (such as authentication errors), but error condition is corrected (such as authentication errors), but
SHOULD NOT automatically generate retry attempts. SHOULD NOT automatically generate retry attempts.
Hall I-D Expires: March 2004 [page 36]
5.3.4. Authentication restrictions 5.3.4. Authentication restrictions
Servers operators SHOULD allow anonymous authentication for read- Servers operators SHOULD allow anonymous authentication for read-
only access to public delegation data. Clients SHOULD use only access to public delegation data. Clients SHOULD use
anonymous authentication by default. anonymous authentication by default.
Wherever a server operator requires or desires clients to Wherever a server operator requires or desires clients to
authenticate for access, servers MUST support the simple authenticate for access, servers MUST support the simple
authentication mechanism defined in RFC 2222 [RFC2222], although authentication mechanism defined in RFC 2222 [RFC2222], although
Hall I-D Expires: February 2004 [page 30]
server operators MAY require the use of any authentication server operators MAY require the use of any authentication
mechanisms in addition to or instead of the simple mechanism. mechanisms in addition to or instead of the simple mechanism.
Server operators SHOULD NOT impose unreasonable requirements for Server operators MAY define any access controls on the data, as
proprietary authentication mechanisms for routine purposes. necessary for policy considerations. Server operators SHOULD NOT
impose unreasonable requirements for proprietary authentication
mechanisms for routine purposes.
Server operators MAY withhold privileged information from non- Server operators MAY withhold privileged information from non-
privileged clients or users, as necessary. privileged clients or users, as necessary.
Clients MUST NOT equate the absence of any attributes with the Clients MUST NOT equate the absence of any attributes with the
absence of data, and SHOULD assume that the user is not authorized absence of data, and SHOULD assume that the authenticated user is
to view any data which has not been provided. not authorized to view any data which has not been provided.
If a client specifically requests an entry or an attribute which If a client specifically requests an entry or an attribute which
the server is unable or unwilling to provide due to policy the server is unwilling to provide due to ACL settings, the server
constraints, the server MUST use the appropriate LDAPv3 error MUST use the appropriate LDAPv3 error message. For example, if the
message. For example, if the user is unable to view an entry or a user is unable to view an entry or a requested attribute because
requested attribute because it has not yet provided sufficient it has not yet provided sufficient authentication credentials, the
authentication credentials, the server MUST return the server MUST return the "invalidCredentials" error. Similarly, if
"invalidCredentials" error. Similarly, if the client has request the client has requested an entry or attribute which the server is
an entry or attribute which the server is unwilling to provide due unwilling to provide due to policy reasons, the server MUST return
to policy reasons, the server MUST return the unwillingToPerform the unwillingToPerform error to the client.
error to the client.
5.3.5. Protocol and schema version controls See section 5.3.5 for mechanisms that can be used to determine
and/or describe usage restrictions on specific attribute values.
5.3.5. Extended attribute ACLs
In normal operations, attributes and values that the client is not
authorized to view would not be returned in response to queries
for that data, with the client equating a lack of data in a
particular attribute with "no data that you are authorized to
view". However, [CRISP-REQ] defines additional response types for
conveying explicit restrictions on data (such as reporting that
Hall I-D Expires: March 2004 [page 37]
the data is restricted due to privacy considerations), and which
requires more comprehensive reporting than simply omitting data
that the user is not authorized to view.
This extended data is provided through the use of LDAP attribute
options, as described in section 4.1.5 of [RFC2251] (this is the
same mechanism as used with language tags), using "inetExtAcl-" as
the option prefix.
The current-valid list of attribute options are:
* InetExtAcl-S0 -- Security Restricted. Some attribute values
have not been returned due to security requirements which
have not been met.
* InetExtAcl-P0 -- Privacy Restricted. Some attribute values
have not been returned due to privacy requirements which
have not been met.
* InetExtAcl-S1 -- Security Cleared. The security
requirements on the associated attribute values have been
met and the user has been granted access to the data.
* InetExtAcl-P1 -- Privacy Cleared. The privacy requirements
on the associated attribute values have been met and the
user has been granted access to the data.
* InetExtAcl-R0 -- Do Not Distribute. The associated
attribute values are not to be reused outside this session.
Each attribute instance MUST have one of the above attribute
options, but MUST NOT have more than one option. Multiple
instances of the attribute option MAY be assigned to an attribute,
although the instances SHOULD NOT have conflicting meanings.
As a simple example, "mail;inetExtAcl-S1:admins@example.com" would
indicate that this instance of the "mail" attribute had an ACL
protecting it from normal use, but that the user was authorized to
view the attribute data. Meanwhile, the attribute instance of
"mail;inetExtAcl-S1;inetExt-R0:admins@example.com" would indicate
that the user had been granted access to the data, but that the
user must not distribute the data.
Hall I-D Expires: March 2004 [page 38]
Multiple and varying instances of an attribute can co-exist in an
entry simultaneously if necessary. For example, the following
entries can all co-exist within a single entry.
mail:admins@example.com
mail;inetExtAcl-S1:postmaster@example.com
mail;inetExtAcl-P1:jack@example.com
mail;inetExtAcl-P1:inetExtAcl-R0:jill@example.com
In that example, searches for the "mail" attribute would produce
the public information, while searches for the other attribute
instances would produce the alternate data.
Each instance of an attribute can have its own ACLs in the
directory, thereby allowing specific instances of an attribute to
be restricted to certain users. For example, ACLs on the
inetExtAcl-S1 instance of an attribute can be defined so that the
entry owner can view the data, while the inetExtAcl-S0 instance
can be set such that help-desk operators are able to see that
there are hidden attribute values (but without exposing the values
to those users), but with both instances being hidden from
anonymous users so that the general public does not know that
there are any extended attribute options.
Each instance of the attributes can be requested through normal
query processes, although the inetExtAcl-S0 and inetExtAcl-P0
attributes will always be empty (the presence of the attribute
option implies that the related data could not be returned), and
thus those instances will never be returned.
In order to simplify these requests and responses, an
inetExtAclControl client control is provided that specifically
allows for the request of all extended ACL attribute options. The
OID for the inetExtAclControl control is 1.3.6.1.4.1.7161.1.0.1.
Clients MUST provide this control as part of the search request,
and servers which support this control MUST return all of the
regular and extended ACL attributes that are defined for an entry
(according to the ACLs appropriate for the current user).
5.3.6. 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 [RFC3377] and its subordinate LDAPv3 protocol, as defined by [RFC3377] and its subordinate
specifications. If a new version of the LDAP protocol emerges, it specifications. If a new version of the LDAP protocol emerges, it
is expected that some type of mechanism will be included for end- is expected that some type of mechanism will be included for end-
Hall I-D Expires: March 2004 [page 39]
points to use when negotiating over the version in use. Lacking points to use when negotiating over the version in use. Lacking
such a mechanism, FIRS is explicitly 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).
The firsVersion server control described in section 5.3.1 provides The inetResourcesControl server control described in section 5.3.1
a mechanism for clients to detect which resource-types are provides a mechanism that clients can use to determine the version
of an object class or matching filter that the server supports.
Hall I-D Expires: February 2004 [page 31]
supported by the server, although that mechanism MUST NOT be used
for any purposes other than defined herein.
Modifications to existing schema definitions MUST be accompanied Any modifications to any existing schema definitions MUST be
by OID changes. accompanied by new OID assignments for the affected elements.
5.4. Referral Processing 5.4. Referral Processing
As was discussed in section 3.4, FIRS supports two types of As was discussed in section 3.5, FIRS supports two types of LDAP
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.5 of this document.
Non-compliance with the requirements provided in section 3.4
amounts to an error, and is sufficient cause for a client to stop
processing a query.
As was discussed in section 3.4, subordinate reference referrals
are defined in [RFC3296], and use the SearchResultDone response
with a Referral result code as defined in [RFC2251]. Subordinate
reference referrals use a subset of the labeledURI syntax as
defined in [RFC2079], and use the syntax definitions from
[RFC2255] when LDAP URLs in particular are provided, although
section 3.4 of this document also defines additional restrictions
on the allowable URL syntax. This condition means that the current
search operation cannot proceed past this point, and the search
MUST be restarted. This will most often occur when the
inetResources entry for a partition has been redirected to another
directory partition.
Continuation reference referrals use the SearchResultReference
response, which is defined and described in section 4.5.3 of
[RFC2251]. Continuation reference referrals use a subset of the
labeledURI syntax as defined in [RFC2079], and use the syntax
definitions from [RFC2255] when LDAP URLs in particular are to be
provided, although section 3.4 of this document also defines
additional restrictions on the allowable URL syntax. This
condition means that the current search operation has partially
succeeded, but that additional searches SHOULD be started in order
for all of the answer data to be retrieved (in many cases, no
answer data will be provided, and in those situations, new queries
will be required for any data to be retrieved). This will occur
whenever the assertion value of a search has matched a resource
entry which is being managed by another directory partition, and
Hall I-D Expires: February 2004 [page 32] Non-compliance with the URL formatting requirements provided in
can occur with any of the search operations described in this section 3.5.2 amounts to an error, and is sufficient cause for a
document. client to stop processing a query.
The procedure for processing referral URLs is as follows: The procedure for processing referral URLs is as follows:
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. Locate the LDAP URLs in the referral data, and discard any b. Locate the LDAP URLs in the referral data, and discard any
URLs which use any other service types. FIRS clients MUST URLs which use any other service types. FIRS clients MUST
Hall I-D Expires: March 2004 [page 40]
support LDAP URLs. URLs with other service type identifiers support LDAP URLs. URLs with other service type identifiers
SHOULD be ignored. SHOULD be ignored.
c. Extract the port number provided with the URL, and set it c. Extract any port number which may have been provided with
aside for use with the subsequent connection attempt. If no the URL, and set it aside for possible use with the
port number has been provided in the URL, use the port subsequent connection attempt. Use the port number
number discovered through any subsequent SRV lookups (as discovered through any subsequent SRV lookups (as described
described below), or as a last resort use the default port below), or as a last resort use the default port number
number associated with the protocol identifier. associated with the protocol identifier.
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, reuse 1. If no distinguished name element was provided,
the existing authoritative partition and search base. determine the authoritative partition and search base
from the provided assertion value, according to the
procedures for the bootstrap model that is most
relevant to the resource-type.
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 sequence of domainComponent distinguished 3. Extract the sequence of domainComponent distinguished
names from the search base, and use them as the names from the search base, and use them 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 a host identifier was not provided, map the 1. If a host identifier was not provided, map the
domainComponent elements determined in step 5.4.d to a domainComponent elements determined in step 5.4.d to a
DNS domain name and submit a DNS lookup for the SRV DNS domain name and submit a DNS lookup for the SRV
resource records associated with that domain name. If resource records associated with that domain name. If
Hall I-D Expires: February 2004 [page 33]
this step fails, report the error to the user and exit this step fails, report the error to the user and exit
the query. the query.
2. If the host identifier is an IP address, extract it 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.
3. If no port number was provided in the URL, submit a 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. If this lookup succeeds, skip to step 5.4.f.
Hall I-D Expires: March 2004 [page 41]
4. If the SRV lookup from the previous step fails, or if 4. If the SRV lookup from the previous step fails, or if
no port number was specified, submit a DNS lookup for no port number was specified, submit a DNS lookup for
the A resource records. the A resource records.
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.
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".
Hall I-D Expires: February 2004 [page 34]
* 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://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 Note that step 5.4.g requires the client to discard the remainder
of the URL, although this step may be changed in subsequent of the URL, although this step may be changed in subsequent
versions of this specification. In particular, [CRISP-REQ] versions of this specification. In particular, [CRISP-REQ]
requires the ability to pass an inter-server "referral bag", and requires the ability to pass an inter-server "referral bag", and
this mechanism may be implemented through the use of extensions in this mechanism may be implemented through the use of extensions in
the LDAP URL. the LDAP URL.
Hall I-D Expires: February 2004 [page 35]
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].
8. Normative References 8. Normative References
skipping to change at line 1635 skipping to change at line 1928
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 [RFC2222] Myers, J. "Simple Authentication and Security
Layer (SASL)", RFC 2222, October 1997. Layer (SASL)", RFC 2222, October 1997.
Hall I-D Expires: March 2004 [page 42]
[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
skipping to change at line 1663 skipping to change at line 1957
[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.
Hall I-D Expires: February 2004 [page 36]
[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.
[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.
skipping to change at line 1685 skipping to change at line 1978
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.
[RFC2798] Smith, M. "Definition of the inetOrgPerson [RFC2798] Smith, M. "Definition of the inetOrgPerson
LDAP Object Class", RFC 2798, April 2000. LDAP Object Class", RFC 2798, April 2000.
[RFC3296] Zeilenga, K. "Named Subordinate References in [RFC3296] Zeilenga, K. "Named Subordinate References in
Lightweight Directory Access Protocol (LDAP) Lightweight Directory Access Protocol (LDAP)
Directories", RFC 3296, July 2002. Directories", RFC 3296, July 2002.
Hall I-D Expires: March 2004 [page 43]
[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] Falstrom, P., Hoffman, P., and Costello, A. [RFC3490] Falstrom, 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-02, July Guide", draft-ietf-crisp-firs-arch-03, August
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-
02, July 2003. 03, August 2003.
[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-02, Service", draft-ietf-crisp-firs-contact-03,
July 2003. August 2003.
[FIRS-CORE] Hall, E. "The Federated Internet Registry
Service: Core Elements", draft-ietf-crisp-
firs-core-02, July 2003.
Hall I-D Expires: February 2004 [page 37]
[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-02, July 2003. draft-ietf-crisp-firs-dns-03, August 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-02, July Service", draft-ietf-crisp-firs-dnsrr-02, July
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-02, July Service", draft-ietf-crisp-firs-ipv4-03,
2003. August 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-02, July Service", draft-ietf-crisp-firs-ipv6-03,
2003. August 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.
9. Changes from Previous Versions 9. Changes from Previous Versions
draft-ietf-crisp-firs-arch-02: draft-ietf-crisp-firs-core-03:
* Several clarifications and corrections have been made.
Hall I-D Expires: March 2004 [page 44]
* Added a discussion on attribute references.
* Added a discussion on referral source entry names.
* Clarified the rules for LDAP referral URLs.
* Temporarily removed the examples for referral processing,
pending additional clarification text.
* Renamed the firsVersion control to inetResourcesControl and
redefined its usage slightly.
* Renamed inetPrivateIdentifier to inetLocalIdentifier
* Added the inetExtAcl attribute option family, and defined
the inetExtAcl client control.
draft-ietf-crisp-firs-core-02:
* Several clarifications and corrections have been made. * Several clarifications and corrections have been made.
* Changed the referral requirements so that servers are * Changed the referral requirements so that servers are
allowed to provide non-LDAP URLs but that FIRS clients are allowed to provide non-LDAP URLs but that FIRS clients are
required to ignore non-LDAP URLs. This synchronizes required to ignore non-LDAP URLs. This synchronizes
referral mechanisms in the back-end data-stores, and moves referral mechanisms in the back-end data-stores, and moves
the narrower requirement to the client. the narrower requirement to the client.
* Added an inetPrivateIdentifier attribute for storing * Added an inetPrivateIdentifier attribute for storing
operator-specific labels (E.G., legacy NIC handles). operator-specific labels (E.G., legacy NIC handles).
* Added the firsVersion server control (described in section * Added the firsVersion server control, which provides a
5.3.1), which provides a limited amount of version- and limited amount of version- and feature-negotiation support
feature-negotiation support to FIRS. to FIRS.
* 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.
Hall I-D Expires: February 2004 [page 38]
draft-ietf-crisp-firs-core-01: draft-ietf-crisp-firs-core-01:
* Several clarifications and corrections have been made. * Several clarifications and corrections have been made.
* Significant portions of text were moved to [FIRS-ARCH]. * Significant portions of text were moved to [FIRS-ARCH].
Hall I-D Expires: March 2004 [page 45]
draft-ietf-crisp-firs-core-00: 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
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
skipping to change at line 1804 skipping to change at line 2115
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.
Hall I-D Expires: February 2004 [page 39]
* 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: March 2004 [page 46]
* 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
skipping to change at line 1848 skipping to change at line 2159
* 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.
10. Author's Address 10. Author's Address
Eric A. Hall Eric A. Hall
ehall@ehsco.com ehall@ehsco.com
Hall I-D Expires: February 2004 [page 40]
11. Acknowledgments 11. 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
Hall I-D Expires: March 2004 [page 47]
developed with his active participation. Edward Lewis and Peter developed with his active participation. Edward Lewis and Peter
Gietz also contributed significant feedback to this specification Gietz also contributed significant feedback to this specification
in the later stages of its developments. in the later stages of its developments.
12. Full Copyright Statement 12. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise to others, and derivative works that comment on or otherwise
skipping to change at line 1890 skipping to change at line 2202
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: February 2004 [page 41] Hall I-D Expires: March 2004 [page 48]
 End of changes. 

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