idnits 2.17.1 draft-ietf-crisp-firs-core-01.txt: -(1661): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in ' Category: Standards-Track', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2003) is 7645 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CRISP-REQ' is mentioned on line 1476, but not defined == Unused Reference: 'RFC1274' is defined on line 1496, but no explicit reference was found in the text == Unused Reference: 'RFC2252' is defined on line 1516, but no explicit reference was found in the text == Unused Reference: 'RFC2253' is defined on line 1521, but no explicit reference was found in the text == Unused Reference: 'RFC2254' is defined on line 1526, but no explicit reference was found in the text == Unused Reference: 'RFC2277' is defined on line 1536, but no explicit reference was found in the text == Unused Reference: 'RFC2308' is defined on line 1540, but no explicit reference was found in the text == Unused Reference: 'RFC2596' is defined on line 1543, but no explicit reference was found in the text == Unused Reference: 'RFC2798' is defined on line 1550, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1274 (Obsoleted by RFC 4524) ** Obsolete normative reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) ** Obsolete normative reference: RFC 2254 (Obsoleted by RFC 4510, RFC 4515) ** Obsolete normative reference: RFC 2255 (Obsoleted by RFC 4510, RFC 4516) ** Obsolete normative reference: RFC 2256 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) ** Obsolete normative reference: RFC 2596 (Obsoleted by RFC 3866) ** Downref: Normative reference to an Informational RFC: RFC 2798 ** Obsolete normative reference: RFC 3377 (Obsoleted by RFC 4510) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-arch-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-ARCH' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-asn-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-ASN' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-contact-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-CONTCT' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-core-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-CORE' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-dns-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNS' == Outdated reference: A later version (-02) exists of draft-ietf-crisp-firs-dnsrr-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNSRR' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv4-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-IPV4' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv6-01 -- Possible downref: Normative reference to a draft: ref. 'FIRS-IPV6' Summary: 14 errors (**), 0 flaws (~~), 20 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Eric A. Hall 3 Document: draft-ietf-crisp-firs-core-01.txt May 2003 4 Expires: December, 2003 5 Category: Standards-Track 7 The Federated Internet Registry Service: 8 Core Elements 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document describes the core technical elements of the 39 Federated Internet Registry Service (FIRS), a distributed service 40 for storing, locating and transferring information about Internet 41 resources using LDAPv3. 43 Table of Contents 45 1. Introduction...............................................3 46 2. Prerequisites and Terminology..............................3 47 3. The FIRS Namespace.........................................4 48 3.1. The domainComponent (dc=) Namespace Component...........4 49 3.2. The inetResources Namespace Component...................5 50 3.3. The Resource-Specific Namespace Component...............5 51 3.4. Referrals...............................................6 52 3.4.1. Subordinate reference referrals...................8 53 3.4.2. Continuation reference referrals..................9 54 4. Global FIRS Object Classes and Attributes..................9 55 4.1. The inetResources Object Class..........................9 56 4.1.1. Naming syntax.....................................9 57 4.1.2. Schema definition................................10 58 4.1.3. Example..........................................12 59 4.2. The inetAssociatedResources Object Class...............12 60 4.2.1. Naming syntax....................................13 61 4.2.2. Schema definition................................13 62 4.2.3. Example..........................................14 63 4.3. The referral Object Class..............................15 64 5. Global Query Processing Rules.............................15 65 5.1. Query Pre-Processing...................................16 66 5.2. Query Bootstrap Models.................................18 67 5.2.1. Targeted query processing........................18 68 5.2.2. Top-down processing..............................19 69 5.2.3. Bottom-up processing.............................22 70 5.2.4. SRV processing...................................25 71 5.3. Query Processing.......................................26 72 5.3.1. Matching filters.................................26 73 5.3.2. Query-volume restrictions........................28 74 5.3.3. Authentication restrictions......................29 75 5.3.4. Protocol and schema version controls.............29 76 5.4. Referral Processing....................................30 77 6. Security Considerations...................................33 78 7. IANA Considerations.......................................33 79 8. Author's Addresses........................................34 80 9. Normative References......................................34 81 10. Acknowledgments...........................................36 82 11. Changes from Previous Versions............................36 83 12. Full Copyright Statement..................................38 84 1. Introduction 86 This specification defines the core object classes, attributes, 87 syntax rules, matching filters, and operational behaviors for the 88 FIRS service as a whole. Refer to [FIRS-ARCH] for information on 89 the FIRS architecture, and the resource-specific specifications 90 for definitions and rules which govern each of the different 91 resource-types. 93 The definitions in this specification are intended to be used with 94 FIRS. Their usage outside of FIRS is not prohibited, but any such 95 usage is beyond this specification's scope of authority. 97 2. Prerequisites and Terminology 99 The complete set of specifications in the FIRS collection 100 cumulative define a structured and distributed information service 101 using LDAPv3 for the data-formatting and transport functions. This 102 specification should be read in the context of the complete set of 103 specifications, which currently include the following: 105 draft-ietf-crisp-firs-arch-01, "The Federated Internet 106 Registry Service: Architecture and Implementation" 107 [FIRS-ARCH] 109 draft-ietf-crisp-firs-core-01, "The Federated Internet 110 Registry Service: Core Elements" (this document) 111 [FIRS-CORE] 113 draft-ietf-crisp-firs-dns-01, "Defining and Locating DNS 114 Domains in the Federated Internet Registry Service" 115 [FIRS-DNS] 117 draft-ietf-crisp-firs-dnsrr-01, "Defining and Locating DNS 118 Resource Records in the Federated Internet Registry 119 Service" [FIRS-DNSRR] 121 draft-ietf-crisp-firs-contact-01, "Defining and Locating 122 Contact Persons in the Federated Internet Registry Service" 123 [FIRS-CONTCT] 125 draft-ietf-crisp-firs-asn-01, "Defining and Locating 126 Autonomous System Numbers in the Federated Internet 127 Registry Service" [FIRS-ASN] 128 draft-ietf-crisp-firs-ipv4-01, "Defining and Locating IPv4 129 Address Blocks in the Federated Internet Registry Service" 130 [FIRS-IPV4] 132 draft-ietf-crisp-firs-ipv6-01, "Defining and Locating IPv6 133 Address Blocks in the Federated Internet Registry Service" 134 [FIRS-IPV6] 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 137 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 138 in this document are to be interpreted as described in RFC 2119. 140 3. The FIRS Namespace 142 The FIRS namespace acts as an index to the federated partition 143 structure of the globally-distributed database of FIRS servers. 144 There are three major components to this namespace, which are: 146 * The domainComponent entries. Each partition of the globally 147 distributed FIRS directory database is represented by a 148 sequence of domainComponent distinguished names. These 149 sequences effectively identify the root scope of authority 150 for each partition in the global directory database. 152 * An inetResources entry. All of the FIRS-related resource- 153 specific entries in the global database are required to be 154 stored within a well-known "cn=inetResources" container 155 entry at the root of each directory partition. These well- 156 known entries act as application-specific access points 157 within the globally distributed directory database. 159 * The resource-specific entries. Each of the resource- 160 specific entries within the inetResources container entries 161 have their own unique naming rules, as defined in the 162 governing specifications for those resources. 164 These naming rules are discussed in more detail below. 166 3.1. The domainComponent (dc=) Namespace Component 168 The global FIRS directory database is divided into administrative 169 partitions, each of which represent a scope-of-authority for a 170 certain portion of the global database. The root of each partition 171 is represented by a sequence of domainComponent relative 172 distinguished names (RDNs), as defined in RFC 2247 [RFC2247]. In 173 this model, the scope-of-authority for a FIRS partition is derived 174 from a domain name in the global DNS directory, meaning that 175 whoever has authority over any particular domain name effectively 176 has authority over the related FIRS partition. 178 Note that the domainComponent attribute is restricted to seven-bit 179 character codes, and is therefore effectively limited to using 180 character codes from US-ASCII [US-ASCII]. Due to this limitation, 181 internationalized domain names MUST be converted into their ASCII- 182 compatible forms using the "ToASCII" process defined in RFC 3490 183 [RFC3490] before the domainComponent RDNs are used in the 184 directory database or LDAP messages. 186 3.2. The inetResources Namespace Component 188 The FIRS-specific directory entries are segregated from other 189 application-specific entries by the use of a container entry with 190 the MANDATORY name of "cn=inetResources". Any entry which is to be 191 located through FIRS MUST refer to this container entry. 193 Note that this rule specifically applies to entries which are to 194 be located by FIRS clients. The entries themselves MAY be 195 referrals which reference entries in other locations if this is 196 necessary or desirable (see section 3.4), although it is important 197 for administrators to recognize that the referral targets will not 198 be locatable through FIRS. 200 3.3. The Resource-Specific Namespace Component 202 Every resource-specific entry also has a RDN which identifies that 203 resource within the context of the inetResources container of any 204 given partition. Examples of these resource-specific entries can 205 be seen in Figure 1 of [FIRS-ARCH], and include "cn=example.com" 206 which refers to the "example.com" DNS domain name resource, and 207 "cn=admins@example.com" which refers to the "admins@example.com" 208 contact resource. 210 Each of the FIRS resource-types have their own specific naming 211 rules which govern those resources. Refer to the resource-specific 212 specifications for information on those rules. 214 Note that the rules specifically apply to entries which are to be 215 located by FIRS clients. The entries themselves MAY be referrals 216 which reference entries in other locations if this is necessary or 217 desirable (see section 3.4), although it is important for 218 administrators to recognize that the referral targets will not be 219 locatable through FIRS. 221 3.4. Referrals 223 FIRS allows entries in the namespace to refer to other entries, as 224 necessary or desirable. This model allows certain entries to be 225 created as "placeholders" for other canonical entries which 226 contain the actual data. 228 FIRS allows two methods for generating and processing these 229 referrals: subordinate reference referrals, and continuation 230 reference referrals. 232 Subordinate reference referrals indicate that the search base in 233 the original query is an alias for some other entry, and that the 234 query has to be restarted with a new search base in order for the 235 search operation to be processed. Meanwhile, continuation 236 reference referrals indicate that the search was successfully 237 initiated and that some data has been found, but that additional 238 queries for additional resources are required for the query to be 239 completely exhausted. 241 Subordinate and continuation reference referrals use the ref 242 attribute and referral object class defined in RFC 3296 [RFC3296]. 243 Each of these mechanisms use LDAP URLs as defined in RFC 2255 244 [RFC2255] to carry referral data, with some additional FIRS- 245 specific restrictions. 247 Among these restrictions: 249 * Referral source entries MUST comply with all of the 250 applicable namespace and schema rules. 252 * Referral targets MUST use the domainComponent ("dc=") 253 naming syntax for their directory partitions. Although 254 other naming syntaxes are implicitly allowed by [RFC3296], 255 those syntaxes are only guaranteed to be resolvable if they 256 use domainComponent sequences. 258 * Referral targets are encouraged to reside in an 259 inetResources container entry, although this is not 260 required. For example, a general-purpose administrative 261 contact entry may need to refer to a user-specific contact 262 entry in another container if this is necessary, and this 263 kind of usage is allowed. 265 * Referral sources and targets MUST have the same resource- 266 specific object class defined (for example, the referral 267 source and target for a DNS domain resource would both have 268 the inetDnsDomain object class defined). This is a 269 prerequisite for the proper handling of the search filters 270 specified in this document. 272 * Referral targets MAY exist as referrals to other entries, 273 but recursive referrals are discouraged. Clients MAY 274 discontinue referral processing after a reasonable amount 275 of effort (eight referrals is a suggested default value). 277 * The protocol identifier of a URL MUST specify the LDAP 278 service type. Although general-purpose LDAP referrals are 279 allowed to specify any kind of protocol, FIRS referrals are 280 intended to be used for automated queries, and the use of 281 other protocols is forbidden in the default case. 283 * URLs MAY specify host identifiers and port numbers, but 284 none of these elements are required. 286 * If a matching filter and/or assertion value needs to be 287 specified in the referral, they MUST be specified in the 288 filter element of the referral's LDAP URL. Matching filters 289 and/or assertion values MUST NOT be specified unless the 290 referral source needs to explicitly reference a specific 291 target entry in a specific partition. This should only be 292 necessary in those cases where the referral target entry 293 would not normally be located (most likely due to a 294 radically different entry name). 296 * The attribute, scope and extension elements of LDAP URLs 297 will be ignored by the client, and SHOULD NOT be provided. 299 * URLs MUST use a URL-safe format. For example, the IPv4 and 300 IPv6 network address syntaxes defined in this document make 301 use of the forward-slash ("/") character to indicate a 302 subnet prefix, and if this character needs to be provided 303 in a URL, it must be provided in the escaped form ("%2F" in 304 this example). Similarly, some domain names and email 305 addresses contain UTF-8 character data, and some of those 306 character codes will need to be escaped in order to be 307 passed as URL data. 309 * Implementations MUST NOT restrict URL values to verifiable 310 entries from local partitions. Implementations MAY validate 311 referral targets in URLs, but a lack of knowledge regarding 312 a target MUST NOT be treated as sufficient cause to prevent 313 the referral target from being specified. 315 The rules for processing referral URLs are given in section 5.4. 317 Note that the "superior reference referral" defined in RFC 2251 318 [RFC2251] used as a "default referral" for out-of-scope searches 319 is explicitly unsupported in FIRS; any superior reference 320 referrals which are encountered as a part of this service are to 321 be treated as errors. 323 Each of the supported referral mechanisms are discussed in more 324 detail below. 326 3.4.1. Subordinate reference referrals 328 Subordinate reference referrals are defined in [RFC3296], and are 329 returned whenever the search base specified in a query exists as a 330 referral to some other entry. This means that the query MUST be 331 restarted, using the referral target as the new search base. 333 Any entries MAY be defined as subordinate reference referrals 334 which point to other entries. However, almost all of the search 335 functions defined for use by this service use the inetResources 336 container entry as the search base (the exceptions to this rule 337 are targeted searches for explicit entries), so subordinate 338 reference referrals will most commonly be seen when an 339 inetResources container entry has been redirected to an 340 inetResources container in another directory partition. 342 Servers MUST support the use of subordinate reference referrals 343 for this purpose, and clients MUST be prepared to accept and 344 process any subordinate reference referrals in answer sets. 346 When subordinate reference referrals are used for this purpose, 347 the referral source MUST be defined with the referral object 348 class, and MUST also be defined with the appropriate object class 349 for that resource type. For example, a "cn=inetResources" entry 350 which provided a subordinate reference referral would need to have 351 both the referral and inetResources object classes defined, while 352 a DNS domain resource such as "dc=example.com" would need to have 353 both the referral and inetDnsDomain object classes defined (among 354 the other object class definitions which were required for that 355 entry). Referral targets need to use whatever object classes are 356 appropriate for the resource in question, and MAY also be 357 referrals to other entries. 359 3.4.2. Continuation reference referrals 361 Continuation reference referrals are defined in RFC 2251 362 [RFC2251], and are returned when a search operation has been 363 successfully processed but the answer data also includes referrals 364 to other entries. These referrals are often provided as 365 supplemental data to an answer set, although this is not required 366 (a continuation reference referral can be the only response, but 367 it won't be the only response in the common case). 369 Servers MUST support the use of continuation reference referrals 370 for this purpose, and clients MUST be prepared to accept and 371 process any subordinate reference referrals in answer sets. 373 When continuation reference referrals are used for this purpose, 374 entries MAY exist for the queried resource, but one or more 375 entries MUST exist with the referral object class defined, and 376 which provide LDAP URLs that point to other entries which have 377 additional information about the resource in question. 379 4. Global FIRS Object Classes and Attributes 381 Each of the schema definitions provided in this document include 382 attribute definitions, naming rules, and other definitions which 383 are designed to facilitate the consistent storage and retrieval of 384 information within the FIRS service. 386 4.1. The inetResources Object Class 388 The inetResources object class is a structural object class which 389 defines the attributes associated with the "cn=inetResources" 390 container entry, and which provides general information about the 391 network resources associated with the current directory partition. 393 4.1.1. Naming syntax 395 This document requires the presence of an entry named 396 "cn=inetResources" in the root of every directory partition which 397 provides FIRS services. 399 4.1.2. Schema definition 401 Every directory partition which provides public FIRS data MUST 402 have a "cn=inetResources" entry in the root of the directory 403 partition. The inetResources entry MUST exist with the top and 404 inetResources object classes defined. If the entry exists as a 405 referral source, the entry MUST also be defined with the referral 406 object class, in addition to the above requirements. 408 The inetResources object class is a structural object class which 409 is subordinate to the top abstract class, and which MUST be 410 treated as a container class capable of holding additional 411 subordinate entries. The inetResources object class has one 412 mandatory attribute which is "cn" (the naming attribute), and also 413 has several optional attributes. Each of the other object classes 414 defined for use with FIRS are subordinate to the inetResources 415 object class and inherit its attributes. 417 The schema definition for the inetResources object class is as 418 follows: 420 inetResources 421 ( 1.3.6.1.4.1.7161.1.0.0 NAME 'inetResources' DESC 'The 422 inetResources container for the FIRS service' SUP top 423 STRUCTURAL MUST cn MAY ( o $ ou $ description $ 424 inetResourceComments $ businessCategory $ telephoneNumber $ 425 facsimileTelephoneNumber $ labeledURI $ 426 preferredDeliveryMethod $ physicalDeliveryOfficeName $ 427 postOfficeBox $ postalAddress $ postalCode $ street $ l $ 428 st $ c $ inetAbuseContacts $ inetGeneralContacts $ 429 inetSecurityContacts $ inetTechContacts $ 430 inetGeneralDisclaimer ) ) 432 The attributes from the inetResources object class are described 433 below: 435 businessCategory, see RFC 2256 [RFC2256], section 5.16 437 c (country), see [RFC2256], section 5.7 439 cn (commonName), see [RFC2256], section 5.4 441 description, see [RFC2256], section 5.14 442 facsimileTelephoneNumber, see [RFC2256], section 5.24 444 inetAbuseContacts 445 ( 1.3.6.1.4.1.7161.1.0.2 NAME 'inetAbuseContacts' DESC 446 'Contacts for reporting abusive behavior or acceptable-use 447 policy violations.' EQUALITY caseIgnoreMatch SYNTAX 448 inetContactSyntax ) 450 inetGeneralContacts 451 ( 1.3.6.1.4.1.7161.1.0.3 NAME 'inetGeneralContacts' DESC 452 'Contacts for general administrative issues.' EQUALITY 453 caseIgnoreMatch SYNTAX inetContactSyntax ) 455 inetGeneralDisclaimer 456 ( 1.3.6.1.4.1.7161.1.0.4 NAME 'inetResourceComments' DESC 457 'General disclaimer text regarding this data' EQUALITY 458 caseIgnoreMatch SYNTAX DirectoryString{1024} ) 460 inetResourceComments 461 ( 1.3.6.1.4.1.7161.1.0.5 NAME 'inetResourceComments' DESC 462 'General comments about this entry' EQUALITY 463 caseIgnoreMatch SYNTAX DirectoryString{1024} ) 465 inetSecurityContacts 466 ( 1.3.6.1.4.1.7161.1.0.6 NAME 'inetSecurityContacts' DESC 467 'Contacts for general security issues.' EQUALITY 468 caseIgnoreMatch SYNTAX inetContactSyntax ) 470 inetTechContacts 471 ( 1.3.6.1.4.1.7161.1.0.7 NAME 'inetTechContacts' DESC 472 'Contacts for general technical issues.' EQUALITY 473 caseIgnoreMatch SYNTAX inetContactSyntax ) 475 l (locality), see [RFC2256], section 5.8 477 labeledURI, see RFC 2079 [RFC2079] 479 o (organization), see [RFC2256], section 5.11 481 ou (organizational unit), see [RFC2256], section 5.12 483 physicalDeliveryOfficeName, see [RFC2256], section 5.20 485 postalAddress, see [RFC2256], section 5.17 486 postalCode, see [RFC2256], section 5.18 488 postOfficeBox, see [RFC2256], section 5.19 490 preferredDeliveryMethod, see [RFC2256], section 5.29 492 st (stateOrProvinceName), see [RFC2256], section 5.9 494 street (streetAddress), see [RFC2256], section 5.10 496 telephoneNumber, see [RFC2256], section 5.21 498 4.1.3. Example 500 An example of the inetResources object class in use is shown in 501 Figure 1 below. 503 cn=inetResources,dc=example,dc=com 504 [top object class] 505 [inetResources object class] 506 | 507 +-attribute: o 508 | value: "Example Widgets' network resources" 509 | 510 +-attribute: inetGeneralContacts 511 | value: "admins@example.com" 512 | 513 +-attribute: telephoneNumber 514 | value: "1-800-555-1212" 515 | 516 +-attribute: inetResourceComments 517 value: "Please don't send complaints to the 518 postmaster@example.com mailbox." 520 Figure 1: The Example Widgets inetResources container entry. 522 4.2. The inetAssociatedResources Object Class 524 The inetAssociatedResources object class defines attributes which 525 are useful for cross-referencing entries with other resources. For 526 example, it allows inetOrgPerson entries to be associated with 527 IPv4 networks or DNS domains, providing generic cross-reference 528 pointer attributes (this information may be useful if a single 529 organization has multiple DNS domains registered). In short, any 530 resource can be associated with any other resource through the use 531 of this object class. 533 4.2.1. Naming syntax 535 The inetAssociatedResources object class is an auxiliary object 536 class, and not a structural object class. Entries which use this 537 object class definition are defined under the rules associated 538 with the structural object class that defines the Internet 539 resource in question. As such, the naming rules associated with 540 that entry take precedence, and the inetAssociatedResources object 541 class does not define an independent naming syntax. 543 4.2.2. Schema definition 545 The inetAssociatedResources object class is an auxiliary object 546 class which is subordinate to the top object class. The 547 inetAssociatedResources object class has no mandatory attributes, 548 and only has optional attributes. 550 Although the inetAssociatedResources object class is subordinate 551 to the top object class, it is intended to be used with the 552 resource-specific structural object classes defined for use with 553 FIRS. The inetAssociatedResources object class is not likely to 554 provide much value when it is associated with the inetResources 555 object class, since the inetResources object class does not 556 specifically define any resources (and since it does not define 557 resources, it cannot define any associated resources). On the 558 other hand, it is reasonable for the inetAssociatedResources 559 object class to be associated with an inetOrgPerson object class 560 entry, particularly if the referenced person (or role) is 561 responsible for the management of multiple resources. 563 The inetAssociatedResources object class MUST NOT be associated 564 with an entry that only exists as a referral source. 566 Each of the associated resource attributes provide multi-valued 567 data, using the syntax notations which are specific to the 568 resource in question. For example, the inetAssociatedDnsDomain 569 attribute provides multiple associated DNS domain name resources 570 using a multi-valued array, with each domain name using the 571 inetDnsDomainSyntax naming rules defined in [FIRS-DNS]. 573 The schema definition for the inetAssociatedResources object class 574 is as follows: 576 inetAssociatedResources 577 ( 1.3.6.1.4.1.7161.1.5.0 NAME 'inetAssociatedResources' DESC 578 'Internet resources associated with this resource.' SUP top 579 AUXILIARY MAY ( inetAssociatedContacts $ 580 inetAssociatedDnsDomains $ inetAssociatedIpv4Networks $ 581 inetAssociatedIpv6Networks $ inetAssociatedAsNumbers ) ) 583 The attributes from the inetAssociatedResources object class are 584 described below: 586 inetAssociatedAsNumbers 587 ( 1.3.6.1.4.1.7161.1.5.2 NAME 'inetAssociatedAsNumbers' DESC 588 'Autonomous system numbers associated with this Internet 589 resource.' EQUALITY caseIgnoreMatch SYNTAX 590 inetAsNumberSyntax ) 592 inetAssociatedContacts 593 ( 1.3.6.1.4.1.7161.1.5.3 NAME 'inetAssociatedContacts' DESC 594 'Other contacts associated with this Internet resource.' 595 EQUALITY caseIgnoreMatch SYNTAX inetContactSyntax ) 597 inetAssociatedDnsDomains 598 ( 1.3.6.1.4.1.7161.1.5.4 NAME 'inetAssociatedDnsDomains' DESC 599 'DNS domains associated with this Internet resource.' 600 EQUALITY caseIgnoreMatch SYNTAX inetDnsDomainSyntax ) 602 inetAssociatedIpv4Networks 603 ( 1.3.6.1.4.1.7161.1.5.5 NAME 'inetAssociatedIpv4Networks' 604 DESC 'IPv4 networks associated with this Internet 605 resource.' EQUALITY caseIgnoreMatch SYNTAX 606 inetIpv4NetworkSyntax ) 608 inetAssociatedIpv6Networks 609 ( 1.3.6.1.4.1.7161.1.5.6 NAME 'inetAssociatedIpv6Networks' 610 DESC 'IPv6 networks associated with this entry.' EQUALITY 611 caseIgnoreMatch SYNTAX inetIpv6NetworkSyntax ) 613 4.2.3. Example 615 An example of the inetAssociatedResources object class is shown in 616 Figure 2 below. 618 cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com 619 [top object class] 620 [inetResources object class] 621 [inetIpv4Network object class] 622 [inetAssociatedResources object class] 623 | 624 +-attribute: description 625 | value: "The Example Widgets network" 626 | 627 +-attribute: inetAssociatedAsNumbers 628 | value: "65535" 629 | 630 +-attribute: inetAssociatedDnsDomains 631 value: "2.0.192.in-addr.arpa" 633 Figure 2: The inetAssociatedResources attributes associated with 634 the 192.0.2.0/24 IPv4 network entry. 636 4.3. The referral Object Class 638 Entries use the referral object class to define subordinate 639 reference referrals and continuation reference referrals, thereby 640 facilitating the programmatic redirection of queries in support of 641 the referral mechanisms defined in section 3.4. 643 Referral entries MUST conform to the schema specification defined 644 in [RFC3296]. 646 Referral sources MUST NOT contain any user-definable attributes 647 (other than the mandatory naming attribute), and MUST NOT have any 648 subordinate child entries. 650 Refer to section 3.4 for the rules that govern referral URLs in 651 FIRS. Refer to section 5.4 for information on processing referral 652 URLs in FIRS. 654 5. Global Query Processing Rules 656 Another critical aspect to FIRS is the query-processing behavior. 657 These rules govern the ways in which a client parses a query, 658 locates a server which is authoritative for the resource being 659 queried, generates LDAPv3 queries, and processes any resulting 660 referrals. More specifically: 662 * Query pre-processing. The first step is for the client to 663 prepare the query. Portions of this process require the 664 client to determine the type of resource being queried for, 665 and to determine the initial partition which should be used 666 for the query. Since this process is different for each 667 particular resource-type, the rules which govern this 668 behavior are defined in each of the resource-specific 669 specifications. 671 * Bootstrap processing. Once a partition has been determined, 672 the client must locate the LDAP servers which are 673 authoritative for the resource in question. Section 0 674 defines three different bootstrap models that clients can 675 use as part of this process, while each of the resource- 676 specific specifications define which of the models are to 677 be used for each particular resource-type. 679 * Query processing. Once a server has been located, the 680 client must submit the LDAP query which was formed during 681 the pre-preprocessing phase. Section 5.3 defines the global 682 considerations for all FIRS queries, while the resource- 683 specific specifications also define additional parameters. 685 * Query post-processing. FIRS explicitly supports different 686 types of LDAP referral mechanisms, any of which may result 687 in the client application restarting the query or 688 initiating a brand-new query. These mechanisms and their 689 behavioral rules are defined in section 5.4. 691 Each of these phases are discussed in more detail below. 693 5.1. Query Pre-Processing 695 Client input is generally limited to a single well-formed unit of 696 data, such as a domain name ("example.com") or an email address 697 ("admins@example.com"), and this single piece of information must 698 be used to subsequently build a fully-formed LDAPv3 query, 699 including the assertion value, the search base, the matching 700 filter, and so forth. All of these steps are part of the pre- 701 processing phase. 703 Although the exact sequence of steps will vary according to the 704 resource-type being queried, there are some commonalities between 705 each of them. Among these steps: 707 * Determine the resource type. Different kinds of resources 708 have different processing steps, validation mechanisms, and 709 so forth, each of which require that the resource-type be 710 appropriately identified. Clients MAY use any mechanisms 711 necessary to force this determination. 713 * Validate and normalize the data. In all cases, the input 714 data MUST be validated and normalized according to the 715 syntax rules defined in the specification which governs the 716 resource-type. As an example of this step, queries for 717 internationalized domain names must be validated and 718 normalized into a canonical UTF-8 form before any other 719 steps can be taken. Similarly, IPv6 addresses are required 720 to conform to specific syntax rules, and input address may 721 need to be expanded or compressed in order to comply with 722 the syntax requirements. 724 * Determine the authoritative directory partition for the 725 named resource. In most cases, the authoritative partition 726 will be a variation of the input query string, but this is 727 not always the case. For example, the default partition for 728 an email address will be extrapolated from the domain 729 component of the email address itself, while the 730 authoritative partition for an ASN uses a reserved 731 (special-purpose) domain name. In some cases, the 732 authoritative partition may change during the subsequent 733 query-processing steps. 735 * Determine the search base for the query. Each resource type 736 has resource-specific query-processing rules which will 737 dictate how the authoritative partitions are mapped to the 738 search base. In some cases, the cn=inetResources container 739 entry in the authoritative partition will be used "as-is", 740 while in other cases, the cn=inetResources container entry 741 in a delegation parent of the authoritative partition will 742 be used instead. In some cases, the search base may change 743 during subsequent query-processing steps. 745 * Determine the assertion value for the query. The assertion 746 value will usually be the normalized form of the input 747 query. In some cases, the assertion value may change during 748 subsequent query-processing steps. 750 * Determine the matching filter. Each resource-type has its 751 own matching filter rules. For example, contact entries are 752 matched with a simple equalityMatch comparison, while in 753 other cases the matching filter will be an extensibleMatch 754 which is peculiar to the resource-type in use. 756 Once all of the pre-processing steps have been successfully 757 completed, the client will have to locate an LDAPv3 server which 758 is authoritative for the search base before it can submit the 759 query. This process is described in section 5.2 below. 761 5.2. Query Bootstrap Models 763 Once a client has determined which partition should be queried for 764 the specified resource, the client must determine which LDAP 765 servers are authoritative for that partition. 767 The FIRS service supports three different bootstrap models for 768 this process, although these models only differ in relatively 769 minor ways; once a server has been located, the rest of the query 770 process follows the same basic path (issuing the LDAPv3 query, 771 following referrals, and so forth). 773 The three bootstrapping models defined for use with this service 774 are the "targeted " model which is functionally identical to 775 traditional lookups for LDAP servers, the "top-down" model which 776 causes a client to submit a query to the root of a delegation 777 hierarchy, and a "bottom-up" model which causes a client to work 778 up through a delegation hierarchy until a server has been located. 780 5.2.1. Targeted query processing 782 The "targeted" model is similar to the traditional model of LDAP 783 lookups, in that a client queries a previously specified LDAP 784 server for a particular resource under the assumption that the 785 resource exists on that server. If the server or resource does not 786 exist (notwithstanding any referrals which may be returned), the 787 entire query fails. 789 The targeted model can be used when a fixed resource has been 790 specified (such as may occur with a URL), but can also be used if 791 the client prefers to use a "default" server for all operations. 792 The latter may occur when clients use proxy servers, caching 793 servers, or other fixed servers, in lieu of navigating the global 794 directory database with every query. In all of these cases, 795 however, failed lookups are considered to be fatal. 797 The steps for processing targeted queries are described below: 799 a. Determine the IP address and port number to be used (this 800 information may be determined from user input, a 801 configuration file, a URL, or from any other source). 803 1. If a non-ASCII domain name has been specified for this 804 purpose, convert the domain name into its ASCII- 805 compatible form using the "ToASCII" process defined in 806 [RFC3490] before performing any lookups. 808 2. Locate the LDAP servers associated with the domain 809 name through the SRV query steps provided in section 810 5.2.4. If this step fails, use DNS lookups for A 811 resource records instead. If no resource records are 812 available, report the error to the user and exit. 814 b. Once a server has been determined, submit the search 815 operation. If the search operation fails, report the error 816 to the user and exit. Otherwise, display any answer data 817 which is returned. 819 c. If the answer data contains a subordinate reference 820 referral or a continuation reference referral, new query 821 processes MUST be spawned. 823 For subordinate reference referrals, process the URLs 824 according to the rules described in section 5.4 and restart 825 the query process at step 5.2.1.a. For each continuation 826 reference referral, display the answer data received so 827 far, process the LDAP URLs according to the rules described 828 in section 5.4 and start new query processes for each 829 referral at step 5.2.1.a, appending the output from these 830 searches to the current output. 832 Any additional subordinate reference referrals or 833 continuation reference referrals which are encountered from 834 any subsequent searches will need to be processed in the 835 same manner as specified above, until no additional 836 referrals are received. 838 d. Exit the query operation. 840 5.2.2. Top-down processing 842 The top-down model uses an input string to construct an LDAP 843 assertion value and search base, with DNS queries being used to 844 locate the LDAP servers associated with the appropriate top-level 845 delegation entity. Once this process completes, a query is issued 846 to the specified servers. This query may be subsequently 847 redirected to other servers through the use of LDAP referrals. 849 The top-down model is primarily suited for locating Internet 850 resources which are centrally managed and delegated, and where 851 information about the delegation is desired. In particular, this 852 includes resources such as DNS domain names, IP address blocks, 853 and AS numbers. 855 Note that the top-down model does not use incrementally larger 856 domain names for the bootstrap process. Instead, it is assumed 857 that the root partition in the delegation tree will be able to 858 provide any necessary redirection services. For example, if the 859 domain name of "www.example.co.uk" is used in a query, the query 860 will be sent to the "dc=uk" partition, which should provide a 861 referral for the "dc=co,dc=uk" partition, which in turn should 862 provide a referral for the "dc=example,dc=co,dc=uk" partition. 864 The steps for processing top-down queries are described below: 866 a. Determine the directory partition for the query. 868 1. Separate the input string into discrete elements where 869 this is possible. For a DNS domain name of 870 "www.example.com", this would be "www", "example" and 871 "com". For the IPv4 network number of "192.0.2.14", 872 this would be "192", "0", "2" and "14". AS numbers 873 only have a single value and require no separation. Do 874 not discard the original query string. 876 2. IP addresses and AS numbers require additional 877 conversion. For IPv4 addresses, strip off the prefix 878 and convert the input string into a reverse-lookup DNS 879 domain name by reversing the order of the octets and 880 appending "in-addr.arpa" to the right of the domain 881 name. For IPv6 addresses, strip off the prefix and 882 reverse the nibble order of the address (where each 883 nibble is represented by a single hexadecimal 884 character), and append "ip6.arpa". For AS numbers, 885 append only the "arpa" domain name. 887 b. Form the LDAP search base for the query. 889 1. If the client application allows non-ASCII input, 890 convert the domain name formed in step 5.2.2.a above 891 into its ASCII-compatible form using the "ToASCII" 892 process defined in RFC 3490. 894 2. Convert the right-most element from the domain name 895 formed in step 5.2.2.b.1 into a domainComponent DN 896 (such as "dc=com" or "dc=arpa"). This represents the 897 directory partition for the current query. 899 3. Append "cn=inetResources" to the front of the 900 domainComponent syntax ("cn=inetResources,dc=com"). 901 This will form the fully-qualified search base for the 902 LDAP query. 904 c. Locate the LDAP servers associated with the resource by 905 processing the domain name formed in step 5.2.2.a above 906 through the SRV query steps provided in section 5.2.4. 908 d. If the SRV lookup succeeds: 910 1. Choose the best LDAP server, using the weighting 911 formula described in [RFC2782]. 913 2. Formulate the LDAP search using the search base and 914 search filter constructed earlier. For example, if the 915 input query string was for "www.example.com", then the 916 client would begin the process by submitting an 917 inetDnsDomainMatch extensibleMatch search with the 918 assertion value of "www.example.com", and with a 919 search base of "dc=inetResources,dc=com". Similarly, 920 if the input query string was "192.0.2.14", then the 921 client would begin the process by submitting an 922 inetIpv4NetworkMatch extensibleMatch search with the 923 assertion value of "192.0.2.14/32", and with the 924 search base of "cn=inetResources,dc=arpa". 926 3. Submit the search operation to the chosen server and 927 port number. If the operation fails, report the 928 failure to the user and exit. Otherwise, display any 929 answer data which is returned. 931 4. If the answer data contains a subordinate reference 932 referral or a continuation reference referral, new 933 query processes MUST be spawned. 935 For subordinate reference referrals, process the URLs 936 according to the rules described in section 5.4 and 937 restart the query process at step 5.2.2.b. For each 938 continuation reference referral, display the answer 939 data received so far, process the LDAP URLs according 940 to the rules described in section 5.4 and start new 941 query processes for each referral at step 5.2.2.b, 942 appending the output from these searches to the 943 current output. 945 Any additional subordinate reference referrals or 946 continuation reference referrals which are encountered 947 from any subsequent searches will need to be processed 948 in the same manner as specified above, until no 949 additional referrals are received. 951 e. If the SRV lookup fails (where failure is defined as any 952 DNS response message other than an answer), report the 953 failure to the user and exit the current search operation. 955 f. Exit the query operation. 957 5.2.3. Bottom-up processing 959 The bottom-up model uses an input string to construct an LDAP 960 assertion value and search base, with DNS queries being used to 961 locate the LDAP servers which are associated with the management 962 entity that is directly responsible for the resource in question. 963 If no servers are available for that partition, the parent 964 partition in the delegation hierarchy is used instead, with this 965 process repeating until a server has been located. 967 The bottom-up model is best used when a leaf-node partition needs 968 to be queried directly, either because there is no direct 969 delegation path for the resource in question, or because the user- 970 managed partition is preferable to the centralized delegation 971 information. For example, there is no global delegation body which 972 assigns and manages contact identifiers, so these identifiers need 973 to be directed towards the leaf-node partitions directly. The 974 bottom-up model can also be used for other kinds of resources if 975 desirable, although in most cases the bottom-down model will be 976 more useful for those resources. 978 The steps for processing bottom-up queries are described below: 980 a. Determine the input type (DNS Domain, IPv4 Address, etc.) 982 b. Determine the authoritative DNS domain for the resource. 984 1. Separate the input string into discrete elements where 985 this is possible. For a DNS domain name of 986 "www.example.com", this would be "www", "example" and 987 "com". For the IPv4 network number of "192.0.2.14", 988 this would be "192", "0", "2" and "14". Do not discard 989 the original query string. 991 2. IP addresses require additional conversion. For IPv4 992 addresses, strip off the prefix and convert the input 993 string into a reverse-lookup DNS domain name by 994 reversing the order of the octets and appending 995 "in-addr.arpa" to the right of the resulting sequence. 996 For IPv6 addresses, strip off the prefix and reverse 997 the nibble order of the address (where each nibble is 998 represented by a single hexadecimal character), and 999 append "ip6.arpa" to the right of the resulting 1000 sequence. 1002 c. Form the LDAP search base for the query. 1004 1. If the client application allows non-ASCII input, 1005 convert the domain name formed in step 5.2.3.b above 1006 into its ASCII-compatible form using the "ToASCII" 1007 process defined in RFC 3490. 1009 2. Convert the domain name formed in step 5.2.3.c.1 above 1010 into a domainComponent DN (such as 1011 "dc=www,dc=example,dc=com" or "dc=0,dc=2,dc=0,dc=192, 1012 dc=in-addr,dc=arpa"). This represents the directory 1013 partition for the current query. 1015 3. Append the "cn=inetResources" RDN to the left of the 1016 domainComponent syntax (perhaps resulting in 1017 "cn=inetResources,dc=www,dc=example,dc=com"). This 1018 will become the search base for the LDAP query. 1020 d. Locate the LDAP servers associated with the resource by 1021 processing the domain name formed in step 5.2.3.b above 1022 through the SRV query steps provided in section 5.2.4. 1024 e. If the SRV lookup fails with an NXDOMAIN response code (as 1025 described in RFC 2308), then the domain name used for the 1026 SRV lookup does not exist, and a substitute LDAP server and 1027 search base must be used instead. This process involves 1028 determining the parent zone for the domain name in 1029 question, issuing an SRV lookup for that zone, and using 1030 the domain name of the zone as the new LDAP search base, 1031 with this process repeating until a search base can be 1032 located, or until a critical failure forces an exit. 1034 1. Remove the left-most label from the domain name formed 1035 in step 5.2.3.b. 1037 2. If this process has already resulted in a query domain 1038 name at a top-level domain such as "com" or "arpa", 1039 convert the query domain name to "." (to signify the 1040 root domain). 1042 3. If the queried domain name is already set to ".", the 1043 query can go no higher (this most likely indicates a 1044 malformed DNS configuration, a connectivity problem, 1045 or a typo in the query). Exit and report the failure 1046 to the user. 1048 4. Restart the process at step 5.2.2.b, using the domain 1049 name formed above. Repeat until a server is located or 1050 a critical failure forces an exit. 1052 For example, if the original input string of 1053 "www.example.com" resulted in a failed SRV lookup for 1054 "_ldap._tcp.www.example.com", then the first fallback 1055 SRV query would be for "_ldap._tcp.example.com", and 1056 the next fallback query would be for "_ldap._tcp.com", 1057 possibly being followed by "_ldap._tcp.", and possibly 1058 resulting in failure after that. 1060 f. If the SRV lookup succeeds: 1062 1. Choose the best LDAP server, using the weighting 1063 formula described in RFC 2782. 1065 2. Formulate the LDAP search using the search base and 1066 search filter constructed above. For example, if the 1067 input query string was for "www.example.com", then the 1068 client would begin the process by submitting an 1069 inetDnsDomainMatch extensibleMatch search with the 1070 assertion value of "www.example.com", with the search 1071 base of "cn=inetResources,dc=www,dc=example,dc=com". 1072 If the SRV lookups had failed (resulting in "com" 1073 being used as the authoritative directory partition), 1074 then the search base for the query would also be 1075 trimmed accordingly ("cn=inetResources,dc=com"). 1077 3. Submit the search operation to the chosen server and 1078 port number. If the operation fails, report the 1079 failure to the user and exit. Otherwise, display any 1080 answer data which is returned. 1082 4. If the answer data contains a subordinate reference 1083 referral or a continuation reference referral, new 1084 query processes MUST be spawned. 1086 For subordinate reference referrals, process the URLs 1087 according to the rules described in section 5.4 and 1088 restart the query process at step 5.2.3.d. For each 1089 continuation reference referral, display the answer 1090 data received so far, process the LDAP URLs according 1091 to the rules described in section 5.4 and start new 1092 query processes for each referral at step 5.2.3.d, 1093 appending the output from these searches to the 1094 current output. 1096 Any additional subordinate reference referrals or 1097 continuation reference referrals which are encountered 1098 from any subsequent queries will need to be processed 1099 in the same manner as specified above, until no 1100 additional referrals are received. 1102 g. If a fatal DNS error condition occurs, report the error to 1103 the user and stop processing the current query. A fatal DNS 1104 error is any response message with an RCODE of FORMERR, 1105 SERVFAIL, NOTIMPL, or REFUSED, or where a query results in 1106 NODATA (implying that an "_ldap._tcp" domain name exists 1107 but it doesn't have an SRV resource record associated with 1108 it, which is most likely a configuration error). 1110 h. Exit the query operation. 1112 5.2.4. SRV processing 1114 The bootstrapping models described in this document make use of 1115 DNS SRV resource records to locate the LDAP servers associated 1116 with the resource provided in the query input. 1118 The procedure for constructing this SRV lookup is as follows: 1120 a. Construct an SRV-specific label pair for the service type. 1121 For LDAP queries, this will be "_ldap._tcp". 1123 b. If the client allows non-ASCII characters to be input, then 1124 convert the domain name input into its ASCII-compatible 1125 form by using the "ToASCII" process described in [RFC3490]. 1127 c. Append the SRV label pair to the left of the input domain 1128 name from step 5.2.4.b. In the case of a query for the 1129 "example.com" domain, this would result in an SRV-specific 1130 domain name of "_ldap._tcp.example.com". 1132 d. Issue a DNS query for the SRV resource records associated 1133 with the domain name formed in step 5.2.4.b. 1135 Multiple SRV resource records may be returned in response to a 1136 query. Each resource record identifies a different connection 1137 target, including the domain name of a server, and a port number 1138 for that server. The port number specified in a SRV resource 1139 record MUST be used for any subsequent bind and search operations. 1141 SRV resource records provide "priority" and "weight" values which 1142 MUST be used to determine the preferred server. If a server is 1143 unavailable or unreachable, a connection attempt must be made to 1144 the next-best server in the answer set. 1146 Refer to [RFC2782] for a detailed explanation of SRV resource 1147 records and their handling. 1149 5.3. Query Processing 1151 Once an authoritative server for the partition in question has 1152 been located, the LDAP query can be submitted. In order to ensure 1153 interoperability, this specification defines several behavioral 1154 rules which clients and servers are encouraged to conform with. 1155 These guidelines are discussed in the following sections. 1157 5.3.1. Matching filters 1159 LDAP search filters are fairly flexible, in that they allow for a 1160 wide variety of configurable elements, such as the maximum number 1161 of entries which are returned, the type of comparison operation 1162 that needs to be performed, and other details. In order to ensure 1163 interoperability, default values are defined here for many of 1164 these elements. 1166 [RFC2251] defines the LDAP search request specification, although 1167 it does not provide guidelines or recommended values for the 1168 filter settings. In an effort to promote interoperability among 1169 FIRS clients and servers, this document defines some recommended 1170 and mandatory values for searches within the FIRS service. 1172 NOTE: These rules ONLY apply to the FIRS search operations 1173 in particular. Any queries for other resources SHOULD NOT 1174 impose these restrictions. Also note that other documents 1175 which define additional resource types can also define 1176 different restrictions, and those definitions will take 1177 precedence over the global defaults. 1179 Servers MUST be prepared to enforce these rules independently of 1180 the client settings, and clients MUST be prepared to receive 1181 truncated search results accordingly. 1183 The default values of an LDAPv3 search filter in FIRS are: 1185 * Search base. The directory partition to be used in a search 1186 will vary for each query operation. The methodology for 1187 determining the current search base for a query is defined 1188 by the query-processing protocols described in section 5.1, 1189 although FIRS searches are normally constrained to the 1190 "cn=inetResources" container of a particular directory 1191 partition. 1193 * Scope. In order to support continuation reference referrals 1194 (which are defined as referral entries beneath a resource- 1195 specific entry), clients MUST use a sub-tree scope for FIRS 1196 searches. Servers MUST NOT arbitrarily limit the scope of 1197 search operations. 1199 * Dereference aliases. Although the FIRS service does not 1200 make direct use of alias entries, they are not prohibited. 1201 Clients SHOULD set the Dereference Aliases option to 1202 "Always" for FIRS searches. Servers SHOULD dereference any 1203 aliases which are encountered, where this is feasible (in 1204 particular, where the alias refers to another directory 1205 partition on the same server). 1207 * Size limit. The size limit field specifies the maximum 1208 number of entries that a server should return. For the FIRS 1209 service, this setting SHOULD be set to a value between 25 1210 and 100. This range ensures that the client is capable of 1211 receiving a sufficient number of entries and continuation 1212 references in a single response, but also works to prevent 1213 runaway queries that match everything (such as searches for 1214 "com", which can match every inetDnsDomain entry in the 1215 "cn=inetResources,dc=com" container). Servers MAY truncate 1216 answer sets to 100 responses if the client specifies a 1217 larger value. 1219 * Time limit. The time limit field specifies the maximum 1220 number of seconds that a server should process the search. 1221 For the FIRS service, this setting SHOULD be set to a value 1222 between 10 and 60 seconds. This range ensures that the 1223 server is able to process a sufficient number of entries, 1224 but also works to prevent runaway queries that match 1225 everything. Servers MAY stop processing queries after 60 1226 seconds if the client specifies a larger value. 1228 * Types-only. The types-only setting is a Boolean flag which 1229 controls whether or not attribute values are returned in 1230 the answer sets. Since excessive queries are likely to be 1231 more burdensome than larger answer sets, this setting 1232 SHOULD be set to FALSE. Resource-constrained clients (such 1233 as PDAs) MAY set this value to TRUE, but these clients MUST 1234 be prepared to issue the necessary subsequent queries. 1236 * Filter. The search operation will depend on the type of 1237 data being queried. For FIRS queries, the filter MUST use 1238 the matching rules defined for the relevant resource type. 1240 * Attribute list. Clients MAY restrict the list of attributes 1241 which are returned in searches, but are discouraged from 1242 doing so without cause. 1244 5.3.2. Query-volume restrictions 1246 The restrictions listed in section 5.3.1 represent suggested 1247 defaults, although server operators MAY impose any kinds of usage 1248 limits they deem necessary or desirable. 1250 Specifically, server operators MAY restrict the amount of 1251 information provided to specific clients and/or users over a given 1252 amount of time, within reason. For example, servers MAY restrict 1253 clients to an arbitrary number of queries per hour, per day, and 1254 so forth. Servers which refuse to process a query due volume 1255 policy SHOULD reject the connection and/or query using the 1256 "unwillingToPerform" response code ("53"). 1258 Clients MUST be prepared for connection requests and queries to be 1259 denied for any reason, and MUST treat these conditions as non- 1260 permanent failures. Clients MAY retry the operations if a known 1261 error condition is corrected (such as authentication errors), but 1262 SHOULD NOT automatically generate retry attempts. 1264 5.3.3. Authentication restrictions 1266 Servers operators SHOULD allow anonymous authentication for read- 1267 only access to public delegation data. Clients SHOULD use 1268 anonymous authentication by default. 1270 Wherever a server operator requires or desires clients to 1271 authenticate for access, servers MUST support the simple 1272 authentication mechanism defined in RFC 2222 [RFC2222], although 1273 server operators MAY require the use of any authentication 1274 mechanisms in addition to or instead of the simple mechanism. 1276 Server operators SHOULD NOT impose unreasonable requirements for 1277 proprietary authentication mechanisms for routine purposes. 1279 Server operators MAY withhold privileged information from non- 1280 privileged clients or users, as necessary. 1282 Clients SHOULD NOT equate the absence of any attributes with the 1283 absence of data, and SHOULD assume that the user is not authorized 1284 to view any data which has not been provided. 1286 5.3.4. Protocol and schema version controls 1288 The FIRS collection of specifications are explicitly bound to the 1289 LDAPv3 protocol, as defined by [RFC3377] and its subordinate 1290 specifications. If a new version of the LDAP protocol emerges, it 1291 is expected that some type of mechanism will be included for end- 1292 points to use when negotiating over the version in use. Lacking 1293 such a mechanism, FIRS is explicitly restricted to LDAPv3. 1295 LDAP attributes, object classes, syntaxes and matching filters 1296 have OIDs which uniquely identify the format of the data they 1297 provide, and which act as simple schema-version identifiers in the 1298 generic case. [RFC2251] defines standardized mechanisms for 1299 retrieving and reading the OIDs associated with object classes and 1300 attributes (among other resource types). These mechanisms MAY be 1301 used whenever a FIRS client reads an entry, and MUST be used 1302 whenever a FIRS client modifies or creates an entry (even though 1303 FIRS does not define mechanisms for updating entries, it is 1304 assumed that some clients will allow this behavior). 1306 Modifications to existing schema definitions MUST be accompanied 1307 by OID changes. 1309 5.4. Referral Processing 1311 As was discussed in section 3.4, FIRS supports two types of 1312 referrals, which are subordinate reference referrals and 1313 continuation reference referrals. Both referral types use URLs for 1314 the purpose of providing referral targets, using the rules 1315 described in section 3.4 of this document. 1317 Non-compliance with the requirements provided in section 3.4 1318 amounts to an error, and is sufficient cause for a client to stop 1319 processing a query. 1321 As was discussed in section 3.4, subordinate reference referrals 1322 are defined in [RFC3296], and use the SearchResultDone response 1323 with a Referral result code as defined in [RFC2251]. Subordinate 1324 reference referrals use a subset of the labeledURI syntax as 1325 defined in [RFC2079], and use the syntax definitions from 1326 [RFC2255] when LDAP URLs in particular are provided, although 1327 section 3.4 of this document also defines additional restrictions 1328 on the allowable URL syntax. This condition means that the current 1329 search operation cannot proceed past this point, and the search 1330 MUST be restarted. This will most often occur when the 1331 inetResources entry for a partition has been redirected to another 1332 directory partition. 1334 Meanwhile, continuation reference referrals use the 1335 SearchResultReference response, which is defined and described in 1336 section 4.5.3 of [RFC2251]. Continuation reference referrals use a 1337 subset of the labeledURI syntax as defined in [RFC2079], and use 1338 the syntax definitions from [RFC2255] when LDAP URLs in particular 1339 are to be provided, although section 3.4 of this document also 1340 defines additional restrictions on the allowable URL syntax. This 1341 condition means that the current search operation has partially 1342 succeeded, but that additional searches SHOULD be started in order 1343 for all of the answer data to be retrieved (in many cases, no 1344 answer data will be provided, and in those situations, new queries 1345 will be required for any data to be retrieved). This will occur 1346 whenever the assertion value of a search has matched a resource 1347 entry which is being managed by another directory partition, and 1348 can occur with any of the search operations described in this 1349 document. 1351 The procedure for processing referral URLs is as follows: 1353 a. [RFC2251] allows multiple URLs to be provided, although the 1354 URLs are not provided with any "preference" or "weighting" 1355 values. If a set of URLs are provided, only one of the URLs 1356 need to be tried (implementations MAY perform additional 1357 queries in an attempt to recover from temporary failures, 1358 although this is not required). Select one of the URLs at 1359 random ("round-robin"), and continue to the next step in 1360 the process. 1362 b. Validate the protocol label. FIRS only supports the use of 1363 the LDAP service type. URLs with other protocol identifiers 1364 are to be treated as malformed. 1366 c. Extract the port number provided with the URL, and set it 1367 aside for use with the subsequent connection attempt. If no 1368 port number has been provided in the URL, use the port 1369 number discovered through any subsequent SRV lookups (as 1370 described below), or as a last resort use the default port 1371 number associated with the protocol identifier. 1373 d. Determine the authoritative partition and search base 1374 specified in the referral URL. 1376 1. If no distinguished name element was provided, reuse 1377 the existing authoritative partition and search base. 1379 2. Otherwise, use the distinguished name element for the 1380 search base of the subsequent search operation. 1382 3. Extract the sequence of domainComponent distinguished 1383 names from the search base, and use them as the 1384 authoritative partition. 1386 e. Determine the server address and port number specified in 1387 the referral URL. 1389 1. If a host identifier was not provided, map the 1390 domainComponent elements determined in step 5.4.d to a 1391 DNS domain name and submit a DNS lookup for the SRV 1392 resource records associated with that domain name. If 1393 this step fails, report the error to the user and exit 1394 the query. 1396 2. If the host identifier is an IP address, extract it 1397 and skip to step 5.4.f. 1399 3. If no port number was provided in the URL, submit a 1400 DNS lookup for the SRV resource records associated 1401 with the domain name, as described in section 5.2.4. 1402 If this lookup succeeds, skip to step 5.4.f. 1404 4. If the SRV lookup from the previous step fails, or if 1405 no port number was specified, submit a DNS lookup for 1406 the A resource records. 1408 f. Determine the new assertion value and/or matching filter 1409 specified in the referral URL. 1411 1. If the URL's path element does not contain a filter 1412 element, reuse the current matching filter and 1413 assertion value. 1415 2. If the URL's path element contains a filter element, 1416 use it to form the new matching filter and/or 1417 assertion value. 1419 g. Discard the remainder of the URL. 1421 h. Use the discovered parameter values to start a new query. 1423 For example, imagine that a referral has been received with the 1424 URL value of "ldap:///cn=inetResources,dc=example,dc=com". The 1425 processing rules for this URL would be as follows: 1427 * Use "cn=inetResources,dc=example,dc=com" as the new search 1428 base for the subsequent query. 1430 * Use the domainComponent sequence of "dc=example,dc=com" as 1431 the new authoritative partition. 1433 * No host identifier was specified in the URL, so the 1434 "dc=example,dc=com" partition must be used to seed a server 1435 identifier of "example.com". 1437 * Issue DNS lookups for the SRV resource records associated 1438 with "_ldap._tcp.example.com" to determine the server and 1439 port number for the subsequent query. 1441 * Reuse the existing assertion value and matching filter. 1443 As another example, imagine a referral with the URL value of 1444 "ldap://example.com/cn=inetResources,dc=example,dc=com". The 1445 processing rules for this URL would be as follows: 1447 * Use "cn=inetResources,dc=example,dc=com" as the new search 1448 base for the subsequent query. 1450 * Use the domainComponent sequence of "dc=example,dc=com" as 1451 the new authoritative partition. 1453 * Use the host identifier of "example.com" as specified in 1454 the URL. 1456 * Issue DNS lookups for the SRV resource records associated 1457 with "_ldap._tcp.example.com" to determine the server and 1458 port number for the subsequent query. 1460 * Reuse the existing assertion value and matching filter. 1462 As another example, imagine a referral with the URL value of 1463 "ldap:////???(cn:dn:www.example.com). The processing rules for 1464 this URL would be as follows: 1466 * Reuse the existing search base and authoritative partition 1467 information. 1469 * Reuse the existing server and port number. 1471 * Use "(cn:dn:www.example.com)" as the new matching filter 1472 and assertion value. 1474 Note that step 5.4.g requires the client to discard the remainder 1475 of the URL, although this step may be changed in subsequent 1476 versions of this specification. In particular, [CRISP-REQ] 1477 requires the ability to pass an inter-server "referral bag", and 1478 this mechanism may be implemented through the use of extensions in 1479 the LDAP URL. 1481 6. Security Considerations 1483 Security considerations are discussed in [FIRS-ARCH]. 1485 7. IANA Considerations 1487 IANA considerations are discussed in [FIRS-ARCH]. 1489 8. Author's Addresses 1491 Eric A. Hall 1492 ehall@ehsco.com 1494 9. Normative References 1496 [RFC1274] Barker, P., and Kille, S. "The COSINE and 1497 Internet X.500 Schema", RFC 1274, November 1498 1991. 1500 [RFC2079] Smith, M. "Definition of an X.500 Attribute 1501 Type and an Object Class to Hold Uniform 1502 Resource Identifiers (URIs)", RFC 2079, 1503 January 1997. 1505 [RFC2222] Myers, J. "Simple Authentication and Security 1506 Layer (SASL)", RFC 2222, October 1997. 1508 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 1509 and Sataluri, S. "Using Domains in LDAP/X.500 1510 DNs", RFC 2247, January 1998. 1512 [RFC2251] Wahl, M., Howes, T., and Kille, S. 1513 "Lightweight Directory Access Protocol (v3)", 1514 RFC 2251, December 1997. 1516 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 1517 S. "Lightweight Directory Access Protocol 1518 (v3): Attribute Syntax Definitions", RFC 2252, 1519 December 1997. 1521 [RFC2253] Wahl, M., Kille, S., and Howes, T. 1522 "Lightweight Directory Access Protocol (v3): 1523 UTF-8 String Representation of DNs", RFC 2253, 1524 December 1997. 1526 [RFC2254] Howes, T. "The String Representation of LDAP 1527 Search Filters", RFC 2254, December 1997. 1529 [RFC2255] Howes, T., and Smith, M. "The LDAP URL 1530 Format", RFC 2255, December 1997. 1532 [RFC2256] Wahl, M. "A Summary of the X.500(96) User 1533 Schema for use with LDAPv3", RFC 2256, 1534 December 1997. 1536 [RFC2277] Alvestrand, H. "IETF Policy on Character Sets 1537 and Languages", BCP 18, RFC 2277, January 1538 1998. 1540 [RFC2308] Andrews, M. "Negative Caching of DNS Queries 1541 (DNS NCACHE)", RFC 2308, March 1998. 1543 [RFC2596] Wahl, M., and Howes, T. "Use of Language Codes 1544 in LDAP", RFC 2596, May 1999. 1546 [RFC2782] Gulbrandsen, A., Vixie, P., and Esibov, L. "A 1547 DNS RR for specifying the location of services 1548 (DNS SRV)", RFC 2782, February 2000. 1550 [RFC2798] Smith, M. "Definition of the inetOrgPerson 1551 LDAP Object Class", RFC 2798, April 2000. 1553 [RFC3296] Zeilenga, K. "Named Subordinate References in 1554 Lightweight Directory Access Protocol (LDAP) 1555 Directories", RFC 3296, July 2002. 1557 [RFC3377] Hodges, J., and Morgan, R. "Lightweight 1558 Directory Access Protocol (v3): Technical 1559 Specification", RFC 3377, September 2002. 1561 [RFC3490] Faltstrom, P., Hoffman, P., and Costello, A. 1562 "Internationalizing Domain Names in 1563 Applications (IDNA)", RFC 3490, March 2003. 1565 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 1566 Service: Architecture and Implementation 1567 Guide", draft-ietf-crisp-firs-arch-01, May 1568 2003. 1570 [FIRS-ASN] Hall, E. "Defining and Locating Autonomous 1571 System Numbers in the Federated Internet 1572 Registry Service", draft-ietf-crisp-firs-asn- 1573 01, May 2003. 1575 [FIRS-CONTCT] Hall, E. "Defining and Locating Contact 1576 Persons in the Federated Internet Registry 1577 Service", draft-ietf-crisp-firs-contact-01, 1578 May 2003. 1580 [FIRS-CORE] Hall, E. "The Federated Internet Registry 1581 Service: Core Elements", draft-ietf-crisp- 1582 firs-core-01, May 2003. 1584 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in 1585 the Federated Internet Registry Service", 1586 draft-ietf-crisp-firs-dns-01, May 2003. 1588 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 1589 Records in the Federated Internet Registry 1590 Service", draft-ietf-crisp-firs-dnsrr-01, May 1591 2003. 1593 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 1594 Blocks in the Federated Internet Registry 1595 Service", draft-ietf-crisp-firs-ipv4-01, May 1596 2003. 1598 [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address 1599 Blocks in the Federated Internet Registry 1600 Service", draft-ietf-crisp-firs-ipv6-01, May 1601 2003. 1603 [US-ASCII] Cerf, V. "ASCII format for Network 1604 Interchange", RFC 20, October 1969. 1606 10. Acknowledgments 1608 Funding for the RFC editor function is currently provided by the 1609 Internet Society. 1611 Portions of this document were funded by Verisign Labs. 1613 The first version of this specification was co-authored by Andrew 1614 Newton of Verisign Labs, and subsequent versions continue to be 1615 developed with his active participation. 1617 11. Changes from Previous Versions 1619 draft-ietf-crisp-firs-core-01: 1621 * Several clarifications and corrections have been made. 1623 * Significant portions of text were moved to [FIRS-ARCH]. 1625 draft-ietf-crisp-firs-core-00: 1627 * Restructured document set, separating the architectural 1628 discussion from the technical descriptions. Several 1629 sections were relocated to [FIRS-ARCH] as a result of this 1630 change. 1632 * "Attribute references" have been eliminated from the 1633 specification. All referential attributes now provide 1634 actual data instead of URL pointers to data. Clients that 1635 wish to retrieve these values will need to start new 1636 queries using the data values instead of URLs. 1638 * The various modified* operational attributes in the core 1639 schema have been eliminated as unnecessary. 1641 * Several attributes had their OIDs changed. NOTE THAT THIS 1642 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 1643 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 1645 draft-ietf-crisp-lw-core-00: 1647 * As a result of the formation of the CRISP working group, 1648 the original monolithic document has been broken into 1649 multiple documents, with draft-ietf-crisp-lw-core 1650 describing the core service, while related documents 1651 describe the per-resource schema and access mechanisms. 1653 * References to the ldaps: URL scheme have been removed, 1654 since there is no standards-track specification for the 1655 ldaps: scheme. 1657 * An acknowledgements section was added. 1659 draft-hall-ldap-whois-01: 1661 * The �Objectives� section has been removed. [ir-dir-req] is 1662 now being used as the guiding document for this service. 1664 * Several typographical errors have been fixed. 1666 * Some unnecessary text has been removed. 1668 * Figures changed to show complete sets of object classes, to 1669 improve inheritance visibility. 1671 * Clarified the handling of reverse-lookup domains (zones 1672 within the in-addr.arpa portion of the DNS hierarchy) in 1673 the inetDnsDomain object class reference text. 1675 * Referrals now use regular LDAP URLs (multiple responses 1676 with explicit hostnames and port numbers). Prior editions 1677 of this specification used LDAP SRV resource records for 1678 all referrals. 1680 * The delegation status codes used by the 1681 inetDnsDelegationStatus, inetIpv4DelegationStatus, 1682 inetIpv6DelegationStatus and inetAsnDelegationStatus 1683 attributes have been condensed to a more logical set. 1685 * Added an inetDnsAuthServers attribute for publishing the 1686 authoritative DNS servers associated with a domain. NOTE 1687 THAT THIS IS A TEMPORARY ATTRIBUTE THAT WILL EVENTUALLY BE 1688 REPLACED BY GENERALIZED RESOURCE-RECORD ENTRIES AND 1689 ATTRIBUTES. 1691 * Added an inetGeneralDisclaimer attribute for publishing 1692 generalized disclaimers. 1694 * Added the inetAssociatedResources auxiliary object class 1695 for defining associated resources, and moved some of the IP 1696 addressing and ASN attributes to the new object class. 1698 * Several attributes had their OIDs changed. NOTE THAT THIS 1699 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 1700 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 1702 12. Full Copyright Statement 1704 Copyright (C) The Internet Society (2003). All Rights Reserved. 1706 This document and translations of it may be copied and furnished 1707 to others, and derivative works that comment on or otherwise 1708 explain it or assist in its implementation may be prepared, 1709 copied, published and distributed, in whole or in part, without 1710 restriction of any kind, provided that the above copyright notice 1711 and this paragraph are included on all such copies and derivative 1712 works. However, this document itself may not be modified in any 1713 way, such as by removing the copyright notice or references to the 1714 Internet Society or other Internet organizations, except as needed 1715 for the purpose of developing Internet standards in which case the 1716 procedures for copyrights defined in the Internet Standards 1717 process must be followed, or as required to translate it into 1718 languages other than English. 1720 The limited permissions granted above are perpetual and will not 1721 be revoked by the Internet Society or its successors or assigns. 1723 This document and the information contained herein is provided on 1724 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1725 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1726 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1727 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1728 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.