idnits 2.17.1 draft-ietf-crisp-firs-core-00.txt: -(1666): 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: 'FIRS-CONTACT' is mentioned on line 516, but not defined == Unused Reference: 'RFC1274' is defined on line 1512, but no explicit reference was found in the text == Unused Reference: 'RFC2252' is defined on line 1529, but no explicit reference was found in the text == Unused Reference: 'RFC2253' is defined on line 1534, but no explicit reference was found in the text == Unused Reference: 'RFC2254' is defined on line 1539, but no explicit reference was found in the text == Unused Reference: 'RFC2277' is defined on line 1549, but no explicit reference was found in the text == Unused Reference: 'RFC2308' is defined on line 1553, but no explicit reference was found in the text == Unused Reference: 'RFC2596' is defined on line 1556, but no explicit reference was found in the text == Unused Reference: 'RFC2798' is defined on line 1563, but no explicit reference was found in the text == Unused Reference: 'RFC3377' is defined on line 1570, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1274 (Obsoleted by RFC 4524) ** 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-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-ARCH' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-asn-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-ASN' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-contact-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-CONTCT' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-core-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-CORE' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-dns-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNS' == Outdated reference: A later version (-02) exists of draft-ietf-crisp-firs-dnsrr-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNSRR' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv4-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-IPV4' == Outdated reference: A later version (-03) exists of draft-ietf-crisp-firs-ipv6-00 -- Possible downref: Normative reference to a draft: ref. 'FIRS-IPV6' Summary: 13 errors (**), 0 flaws (~~), 21 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-00.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..............6 51 3.4. Referrals..............................................6 52 3.4.1. Subordinate reference referrals..................9 53 3.4.2. Continuation reference referrals.................9 54 3.5. Partition Replicas....................................10 55 4. Global FIRS Object Classes and Attributes................11 56 4.1. The inetResources Object Class........................11 57 4.1.1. Naming syntax...................................11 58 4.1.2. Schema definition...............................11 59 4.1.3. Example.........................................14 60 4.2. The inetAssociatedResources Object Class..............15 61 4.2.1. Naming syntax...................................15 62 4.2.2. Schema definition...............................16 63 4.2.3. Example.........................................17 64 4.3. The referral Object Class.............................18 65 5. Global Query Processing Rules............................18 66 5.1. Query Pre-Processing..................................19 67 5.2. Query Bootstrap Models................................20 68 5.2.1. Targeted Query Processing.......................21 69 5.2.2. Top-Down Processing.............................22 70 5.2.3. Bottom-Up Processing............................25 71 5.2.4. SRV processing..................................28 72 5.3. Query Processing......................................29 73 5.3.1. Search Filters..................................29 74 5.3.2. Authentication and access controls..............31 75 5.3.3. Protocol and schema version controls............32 76 5.4. Post-Query Processing.................................32 77 6. Security Considerations..................................35 78 7. IANA Considerations......................................35 79 8. Author's Addresses.......................................35 80 9. Normative References.....................................35 81 10. Acknowledgments..........................................37 82 11. Changes from Previous Versions...........................37 83 12. Full Copyright Statement.................................39 84 1. Introduction 85 This specification defines the core object classes, attributes, 86 syntax rules, extensibleMatch filters, and operational behaviors 87 for the FIRS service as a whole. Refer to [FIRS-ARCH] for 88 information on the FIRS architecture, and the resource-specific 89 specifications for definitions and rules which govern each of the 90 different resource-types. 92 The definitions in this specification are intended to be used with 93 FIRS. Their usage outside of FIRS is not prohibited, but any such 94 usage is beyond this specification's scope of authority. 96 2. Prerequisites and Terminology 97 The complete set of specifications in the FIRS collection 98 cumulative define a structured and distributed information service 99 using LDAPv3 for the data-formatting and transport functions. This 100 specification should be read in the context of the complete set of 101 specifications, which currently include the following: 103 draft-ietf-crisp-firs-arch-00, "The Federated Internet 104 Registry Service: Architecture and Implementation" 105 [FIRS-ARCH] 107 draft-ietf-crisp-firs-core-00, "The Federated Internet 108 Registry Service: Core Elements" (this document) 109 [FIRS-CORE] 111 draft-ietf-crisp-firs-dns-00, "Defining and Locating DNS 112 Domains in the Federated Internet Registry Service" 113 [FIRS-DNS] 115 draft-ietf-crisp-firs-dnsrr-00, "Defining and Locating DNS 116 Resource Records in the Federated Internet Registry 117 Service" [FIRS-DNSRR] 119 draft-ietf-crisp-firs-contact-00, "Defining and Locating 120 Contact Persons in the Federated Internet Registry Service" 121 [FIRS-CONTCT] 123 draft-ietf-crisp-firs-asn-00, "Defining and Locating 124 Autonomous System Numbers in the Federated Internet 125 Registry Service" [FIRS-ASN] 126 draft-ietf-crisp-firs-ipv4-00, "Defining and Locating IPv4 127 Address Blocks in the Federated Internet Registry Service" 128 [FIRS-IPV4] 130 draft-ietf-crisp-firs-ipv6-00, "Defining and Locating IPv6 131 Address Blocks in the Federated Internet Registry Service" 132 [FIRS-IPV6] 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 135 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 136 in this document are to be interpreted as described in RFC 2119. 138 3. The FIRS Namespace 139 The FIRS namespace acts as an index to the federated partition 140 structure of the globally-distributed database of FIRS servers. 141 There are three major components to this namespace, which are: 143 * The domainComponent entries. Each partition of the globally 144 distributed FIRS directory database is represented by a 145 sequence of domainComponent distinguished names. These 146 sequences effectively identify the root scope of authority 147 for each partition in the global directory database. 149 * An inetResources entry. All of the FIRS-related resource- 150 specific entries in the global database are required to be 151 stored within a well-known "cn=inetResources" container 152 entry at the root of each directory partition. These well- 153 known entries act as application-specific access points 154 within the globally distributed directory database. 156 * The resource-specific entries. Each of the resource- 157 specific entries within the inetResources container entries 158 have their own unique naming rules, as defined in the 159 governing specifications for those resources. 161 These naming rules are discussed in more detail below. 163 3.1. The domainComponent (dc=) Namespace Component 164 The global FIRS directory database is divided into administrative 165 partitions, each of which represent a scope-of-authority for a 166 certain portion of the global database. The root of these 167 partitions is formally defined as a sequence of domainComponent 168 relative distinguished names (RDNs), as defined in [RFC2247]. 170 In this model, a sequence of domainComponent RDNs map to a 171 sequence of domain names in the global DNS hierarchy, with the 172 FIRS partitions mapping to the zones which are managed by the 173 governing organization. As such, the DNS namespace delegations act 174 as FIRS partition delegation, providing natural scopes of 175 administrative control in the global FIRS namespace. Furthermore, 176 the SRV resource records associated with those DNS domains also 177 provide a useful mechanism for locating the authoritative LDAP 178 servers associated with any particular resource in the global FIRS 179 directory database. 181 Since the partition roots determine the scope of control over a 182 set of resources, partitions which overlap also have overlapping 183 scopes of control. For example, the "dc=com" and 184 "dc=example,dc=com" partitions can both provide information about 185 the "www.example.com" domain name resource. In order to reduce the 186 amount of ambiguity which is naturally present in this kind of 187 model, FIRS defines multiple bootstrapping models and also defines 188 the default model which should be used for any given resource. For 189 example, queries for centrally-delegated resources are supposed to 190 ask the top-level partition for information about those resources, 191 while queries for user-managed resources are supposed to ask the 192 leaf-node partition for information about those resources. 194 Note that the domainComponent attribute is restricted to seven-bit 195 character codes, and is therefore effectively limited to using 196 character codes from US-ASCII [US-ASCII]. Due to this limitation, 197 internationalized domain names MUST be converted into their ASCII- 198 compatible forms using the "ToASCII" process defined in RFC 3490 199 [RFC3490] before the domainComponent RDNs are stored in the 200 directory database, and before any searches which reference those 201 partitions are formed. 203 3.2. The inetResources Namespace Component 204 The FIRS directory database is further separated from the 205 directory partition structure by the use of a well-known container 206 entry with the MANDATORY name of "cn=inetResources". Any entry 207 which is to be located and retrieved through FIRS MUST refer to 208 this container entry. 210 Note that these rules specifically apply to entries which are to 211 be locatable by FIRS clients. The entries themselves MAY use 212 referrals to reference entries in other namespace locations if 213 this is necessary or desirable (see section 3.4), although it is 214 important for administrators to recognize that those referral 215 targets will not be locatable through FIRS. 217 3.3. The Resource-Specific Namespace Component 218 Every resource-specific entry also has a RDN which identifies that 219 resource within the context of the inetResources container of any 220 given partition. Examples of these resource-specific entries can 221 be seen in Figure 1 of [FIRS-ARCH], and include "cn=example.com" 222 which refers to the "example.com" DNS domain name resource, and 223 "cn=admins@example.com" which refers to the "admins@example.com" 224 contact resource. 226 Each of the FIRS resource-types have their own specific naming 227 rules which govern those resources. Refer to the resource-specific 228 specifications for information on those rules. 230 Note that these rules specifically apply to entries which are to 231 be locatable by FIRS clients. The entries themselves MAY use 232 referrals to reference entries in other namespace locations if 233 this is necessary or desirable (see section 3.4), although it is 234 important for administrators to recognize that those referral 235 targets will not be locatable through FIRS. 237 3.4. Referrals 238 FIRS allows entries in the namespace to refer to other entries, as 239 necessary or desirable. This model allows certain entries to be 240 created as "placeholders" for other canonical entries which 241 contain the actual data. In turn, this allows organizations to 242 collectively publish shared entries as discrete objects (such as 243 allowing a user's leaf-node directory partition to publish an 244 entry for an ISP's web server as if it were their own entry), 245 allows partitions to reuse common data, and provides numerous 246 other benefits. 248 FIRS allows two methods for generating and processing these 249 referrals: subordinate reference referrals, and continuation 250 reference referrals, both of which are defined in RFC 3296 251 [RFC3296]. Note that the "superior reference referral" defined in 252 RFC 2251 [RFC2251] used as a "default referral" for out-of-scope 253 searches is explicitly unsupported in FIRS; any superior reference 254 referrals which are encountered as a part of this service are to 255 be treated as errors. 257 Subordinate reference referrals indicate that the queried entry is 258 an alias for some other entry, and that the query has to be 259 restarted in order for the current operation to be completed. 260 Meanwhile, continuation references indicate that the search was 261 successfully initiated and that some data has been found, but that 262 additional queries are required for the original query to be 263 completely exhausted. 265 Subordinate references and continuation references use the ref 266 attribute and referral object class defined in RFC 3296 [RFC3296]. 267 Each of these mechanisms use LDAP URLs as defined in RFC 2255 268 [RFC2255], with additional FIRS-specific restrictions. 270 Among these restrictions: 272 * Referral source entries MUST comply with all of the 273 applicable namespace and schema rules. 275 * Referral targets MUST use the domainComponent ("dc=") 276 naming syntax for their directory partitions. Although 277 other naming syntaxes are implicitly allowed by [RFC3296], 278 those syntaxes are only guaranteed to be resolvable if they 279 use domainComponent sequences. 281 * Referral targets are encouraged to reside in an 282 inetResources container entry, although this is not 283 required. For example, a general-purpose administrative 284 contact entry may need to refer to a user-specific contact 285 entry in another container if this is necessary, and this 286 kind of usage is allowed. 288 * Referral sources and targets MUST have the same resource- 289 specific object class defined (for example, the referral 290 source and target for a DNS domain resource would both have 291 the inetDnsDomain object class defined). This is a 292 prerequisite for the proper handling of the search filters 293 specified in this document. 295 * Referral targets MAY exist as referrals to other entries, 296 but recursive referrals are discouraged. Clients MAY 297 discontinue referral processing after a reasonable amount 298 of effort (eight referrals is a suggested default value). 300 * The protocol identifier of a URL MUST specify the LDAP 301 service type. Although general-purpose LDAP referrals are 302 allowed to specify any kind of protocol, FIRS referrals are 303 intended to be used for automated queries, and the use of 304 other protocols is forbidden in the default case. 306 * URLs MAY specify host identifiers and port numbers, but 307 none of these elements are required. 309 * The distinguished name element of an LDAP URL MUST specify 310 the search base of the referral target. 312 * If a matching filter and/or assertion value needs to be 313 specified, they MUST be specified in the filter element of 314 an LDAP URL. New matching filters and/or assertion values 315 MUST NOT be specified unless the referral source needs to 316 explicitly refer to a specific target entry in a specific 317 partition. This should only be necessary in those cases 318 where the referral target entry is a leaf-node with no 319 additional referrals, and where the target is substantially 320 and significantly different from the referral source. 322 * The attribute, scope and extension elements of LDAP URLs 323 will be ignored by the client, and SHOULD NOT be provided. 325 * URLs MUST be provided and stored in a URL-safe format. For 326 example, the IPv4 and IPv6 network address syntaxes defined 327 in this document make use of the forward-slash ("/") 328 character to indicate a subnet prefix, and if this 329 character needs to be provided in a URL, it must be 330 provided in the escaped form ("%2F" in this example). 331 Furthermore, some of the matching rules described in this 332 document require that the URLs also be stored in this 333 format in order for the searches to succeed. 335 * Implementations MUST NOT restrict URL values to verifiable 336 entries from local partitions. Implementations MAY validate 337 referral targets in URLs, but a lack of knowledge regarding 338 a target MUST NOT be treated as sufficient cause to prevent 339 the referral target from being specified. 341 Clients MAY implement additional support for non-LDAP URLs which 342 are provided in conflict with the requirements above. However, 343 clients MUST NOT violate any other mandates in this document while 344 doing so (in particular, clients MUST NOT break the query- 345 processing procedures defined in section 5.1 of this document). 347 Each of the supported redirection mechanisms are discussed in more 348 detail below. 350 3.4.1. Subordinate reference referrals 351 Subordinate reference referrals are returned when the search base 352 specified in a query exists as a referral to some other entry. 353 This means that the entire query MUST be restarted, using the 354 referral target as the new search base. 356 Any entries MAY be defined as subordinate reference referrals 357 which point to other entries. However, almost all of the search 358 functions defined for use by this service use the inetResources 359 container entry as the search base (the exceptions to this rule 360 are targeted searches for explicit entries), so subordinate 361 reference referrals will most commonly be seen when an 362 inetResources container entry has been redirected to an 363 inetResources container in another directory branch. 365 Servers MUST support the use of subordinate reference referrals 366 for this purpose, and clients MUST be prepared to accept and 367 process any subordinate reference referrals in answer sets. 369 When subordinate reference referrals are used for this purpose, 370 the referral source MUST be defined with the referral object 371 class, and MUST also be defined with the appropriate object class 372 for that resource type. For example, a "cn=inetResources" entry 373 which provided a subordinate reference referral would need to have 374 both the referral and inetResources object classes defined, while 375 a DNS domain resource such as "dc=example.com" would need to have 376 both the referral and inetDnsDomain object classes defined (among 377 the other object class definitions which were required for that 378 entry). Referral targets need to use whatever object classes are 379 appropriate for the resource in question, and MAY also be 380 referrals to other entries. 382 Client rules for processing subordinate reference referrals are 383 given in section 5.2.3.h. 385 3.4.2. Continuation reference referrals 386 Continuation reference referrals are returned when a search 387 operation has been successfully processed by the queried server, 388 but the answer data also includes referrals to other entries. 389 These referrals are often provided as supplemental data to an 390 answer set, although this is not required (a continuation 391 reference referral can be the only response, but it won't be the 392 only response in the common case). 394 Servers MUST support the use of continuation reference referrals 395 for this purpose, and clients MUST be prepared to accept and 396 process any subordinate reference referrals in answer sets. 398 When continuation reference referrals are used for this purpose, 399 entries MAY exist for the queried resource, but one or more 400 entries MUST exist with the referral object class defined, and 401 which provide LDAP URLs that point to other entries which have 402 additional information about the resource in question. 404 Continuation reference referrals are returned in response to 405 specific extensible match queries, and have specific naming 406 requirements which are necessary for the matching functions to 407 work properly. These considerations are described in Error! 408 Reference source not found.. 410 Client rules for processing continuation reference referrals are 411 also given in section Error! Reference source not found.. 413 3.5. Partition Replicas 414 All directory partitions which provide data for global Internet 415 resources SHOULD be replicated across two or more servers. Each of 416 the authoritative LDAP servers for the managed resource MUST be 417 specified with a unique DNS SRV resource record for the domain 418 name associated with the top-level resource assignment space. 420 Directory partitions which serve multiple organizations SHOULD 421 also be replicated. For example, an ISP which provides FIRS 422 services for their customers SHOULD also follow these same rules, 423 since outages of those servers will affect multiple parties. Leaf- 424 node directory partitions associated with an user-managed resource 425 MAY be replicated, and are encouraged to do so. 427 Similarly, any referrals which present URLs as answer data SHOULD 428 provide multiple URLs, each of which reference different hosts on 429 different networks. For leaf-node referrals, attribute references, 430 and labeledURI references, this behavior MAY be relaxed, although 431 it is still encouraged. 433 Note that the most effective replication strategy will be for 434 entities to replicate their directory partitions with the 435 delegation parents, as this will allow queries for those resources 436 to be processed by the parent servers (thereby eliminating the 437 need for referral queries). In many cases, this will not be 438 feasible (the servers for the "dc=com" directory partition cannot 439 be expected to host replicas of every subordinate directory 440 partition), but it is encouraged where practical. 442 It is also expected that certain servers will be configured to 443 serve as multi-replica masters, effectively acting as large-scale 444 caching servers for many different resources. When used in 445 conjunction with the targeted bootstrap model described in section 446 5.2.1, this will allow clients to retrieve a significant amount of 447 information without having to pursue a large number of referrals 448 or redirects. This usage is expected and endorsed. 450 Finally, it is also important to note that neither this 451 specification nor the LDAP protocol currently provide cache timers 452 or any other mechanisms which can indicate how accurate or timely 453 any replicas may be. 455 4. Global FIRS Object Classes and Attributes 456 Each of the schema definitions provided in this document include 457 attribute definitions, naming rules, and other definitions which 458 are designed to facilitate the consistent storage and retrieval of 459 information within the FIRS service. 461 4.1. The inetResources Object Class 462 The inetResources object class is a structural object class which 463 defines the attributes associated with the "cn=inetResources" 464 container entry, and which provides general information about the 465 network resources associated with the current directory partition. 467 4.1.1. Naming syntax 468 This document requires the presence of an entry named 469 "cn=inetResources" in the root of every directory partition which 470 provides FIRS services. 472 4.1.2. Schema definition 473 Every directory partition which provides public FIRS data MUST 474 have a "cn=inetResources" entry in the root of the directory 475 partition. The inetResources entry MUST exist with the top and 476 inetResources object classes defined. If the entry exists as a 477 referral source, the entry MUST also be defined with the referral 478 object class, in addition to the above requirements. 480 The inetResources object class is a structural object class which 481 is subordinate to the top abstract class, and which MUST be 482 treated as a container class capable of holding additional 483 subordinate entries. The inetResources object class has one 484 mandatory attribute which is "cn" (the naming attribute), and also 485 has several optional attributes. Each of the other object classes 486 defined by this document are subordinate to the inetResources 487 object class and inherit the attributes defined for the 488 inetResources object class. 490 The inetResources object class is intended to provide summary 491 information about a collection of resources under the control of a 492 single organization or management body. Since this object class is 493 also inherited by the resource-specific object classes, these 494 attributes can be defined at each of the subordinate entries if a 495 global set of attribute values is undesirable or unfeasible. 497 Since multiple directory partitions can use subordinate reference 498 referrals to share a single common inetResources entry, it is 499 important for the data to be applicable to all of the entries 500 which refer to it. For example, it would be effective for a small 501 private company to use a shared set of inetResources attributes 502 for their DNS domain names and IP network blocks, but it would 503 probably be counter-productive for a global ISP to share contact 504 data across all of their hosted domains and routed networks. If 505 separate contacts are required for each resource, the contact data 506 should be specified within each entry, rather than being linked to 507 the inetResources entry. 509 The inetResources object class provides several multi-valued 510 contact-related attributes for a variety of well-known 511 administrative roles. This model allows the inetResources entry 512 and each of the subordinate managed resources to share a common 513 set of administrative roles, or to have unique roles for each 514 resource, as seen fit by the managing entity. Each of the contact- 515 related attributes use the inetContactSyntax syntax rules defined 516 in [FIRS-CONTACT] for their values. 518 The schema definition for the inetResources object class is as 519 follows: 521 inetResources 522 ( 1.3.6.1.4.1.7161.1.0.0 NAME 'inetResources' DESC 'The 523 inetResources container for the FIRS service' SUP top 524 STRUCTURAL MUST cn MAY ( o $ ou $ description $ 525 inetResourceComments $ businessCategory $ telephoneNumber $ 526 facsimileTelephoneNumber $ labeledURI $ 527 preferredDeliveryMethod $ physicalDeliveryOfficeName $ 528 postOfficeBox $ postalAddress $ postalCode $ street $ l $ 529 st $ c $ inetAbuseContacts $ inetGeneralContacts $ 530 inetSecurityContacts $ inetTechContacts $ 531 inetGeneralDisclaimer ) ) 533 The attributes from the inetResources object class are described 534 below: 536 businessCategory, see RFC 2256 [RFC2256], section 5.16 538 c (country), see [RFC2256], section 5.7 540 cn (commonName), see [RFC2256], section 5.4 542 description, see [RFC2256], section 5.14 544 facsimileTelephoneNumber, see [RFC2256], section 5.24 546 inetAbuseContacts 547 ( 1.3.6.1.4.1.7161.1.0.2 NAME 'inetAbuseContacts' DESC 548 'Contacts for reporting abusive behavior or acceptable-use 549 policy violations.' EQUALITY caseIgnoreMatch SYNTAX 550 inetContactSyntax ) 552 inetGeneralContacts 553 ( 1.3.6.1.4.1.7161.1.0.3 NAME 'inetGeneralContacts' DESC 554 'Contacts for general administrative issues.' EQUALITY 555 caseIgnoreMatch SYNTAX inetContactSyntax ) 557 inetGeneralDisclaimer 558 ( 1.3.6.1.4.1.7161.1.0.4 NAME 'inetResourceComments' DESC 559 'General disclaimer text regarding this data' EQUALITY 560 caseIgnoreMatch SYNTAX DirectoryString{1024} ) 562 inetResourceComments 563 ( 1.3.6.1.4.1.7161.1.0.5 NAME 'inetResourceComments' DESC 564 'General comments about this entry' EQUALITY 565 caseIgnoreMatch SYNTAX DirectoryString{1024} ) 566 inetSecurityContacts 567 ( 1.3.6.1.4.1.7161.1.0.6 NAME 'inetSecurityContacts' DESC 568 'Contacts for general security issues.' EQUALITY 569 caseIgnoreMatch SYNTAX inetContactSyntax ) 571 inetTechContacts 572 ( 1.3.6.1.4.1.7161.1.0.7 NAME 'inetTechContacts' DESC 573 'Contacts for general technical issues.' EQUALITY 574 caseIgnoreMatch SYNTAX inetContactSyntax ) 576 l (locality), see [RFC2256], section 5.8 578 labeledURI, see RFC 2079 [RFC2079] 580 o (organization), see [RFC2256], section 5.11 582 ou (organizational unit), see [RFC2256], section 5.12 584 physicalDeliveryOfficeName, see [RFC2256], section 5.20 586 postalAddress, see [RFC2256], section 5.17 588 postalCode, see [RFC2256], section 5.18 590 postOfficeBox, see [RFC2256], section 5.19 592 preferredDeliveryMethod, see [RFC2256], section 5.29 594 st (stateOrProvinceName), see [RFC2256], section 5.9 596 street (streetAddress), see [RFC2256], section 5.10 598 telephoneNumber, see [RFC2256], section 5.21 600 4.1.3. Example 601 An example of the inetResources object class in use is shown in 602 Figure 1 below. 604 cn=inetResources,dc=example,dc=com 605 [top object class] 606 [inetResources object class] 607 | 608 +-attribute: o 609 | value: "Example Widgets' network resources" 610 | 611 +-attribute: inetGeneralContacts 612 | value: "admins@example.com" 613 | 614 +-attribute: telephoneNumber 615 | value: "1-800-555-1212" 616 | 617 +-attribute: inetResourceComments 618 value: "Please don't send complaints to the 619 postmaster@example.com mailbox." 621 Figure 1: The Example Widgets inetResources container entry. 623 4.2. The inetAssociatedResources Object Class 624 The inetAssociatedResources object class defines attributes which 625 are useful for cross-referencing entries with other resources. For 626 example, it allows inetOrgPerson entries to be associated with 627 IPv4 networks or DNS domains, providing generic cross-reference 628 pointer attributes (this information may be useful if a single 629 organization has multiple DNS domains registered). In short, any 630 resource can be associated with any other resource through the use 631 of this object class. 633 The inetAssociatedResources object class MUST NOT be associated 634 with an entry that only exists as a referral source. 636 4.2.1. Naming syntax 637 The inetAssociatedResources object class is an auxiliary object 638 class, and not a structural object class. Entries which use this 639 object class definition are defined under the rules associated 640 with the structural object class that defines the Internet 641 resource in question. As such, the naming rules associated with 642 that entry take precedence, and the inetAssociatedResources object 643 class does not define an independent naming syntax. 645 4.2.2. Schema definition 646 The inetAssociatedResources object class is an auxiliary object 647 class which is subordinate to the top object class. The 648 inetAssociatedResources object class has no mandatory attributes, 649 and only has optional attributes. 651 Although the inetAssociatedResources object class is subordinate 652 to the top object class, it is intended to be used with the 653 resource-specific structural object classes defined for use with 654 FIRS. The inetAssociatedResources object class is not likely to 655 provide much value when it is associated with the inetResources 656 object class, since the inetResources object class does not 657 specifically define any resources (and since it does not define 658 resources, it cannot define any associated resources). On the 659 other hand, it is reasonable for the inetAssociatedResources 660 object class to be associated with an inetOrgPerson object class 661 entry, particularly if the referenced person (or role) is 662 responsible for the management of multiple resources. 664 Each of the associated resource attributes provide multi-valued 665 data, using the syntax notations which are specific to the 666 resource in question. For example, the inetAssociatedDnsDomain 667 attribute provides multiple associated DNS domain name resources 668 using a multi-valued array, with each domain name using the 669 inetDnsDomainSyntax naming rules defined in [FIRS-DNS]. 671 The schema definition for the inetAssociatedResources object class 672 is as follows: 674 inetAssociatedResources 675 ( 1.3.6.1.4.1.7161.1.5.0 NAME 'inetAssociatedResources' DESC 676 'Internet resources associated with this resource.' SUP top 677 AUXILIARY MAY ( inetAssociatedContacts $ 678 inetAssociatedDnsDomains $ inetAssociatedIpv4Networks $ 679 inetAssociatedIpv6Networks $ inetAssociatedAsNumbers ) ) 681 The attributes from the inetAssociatedResources object class are 682 described below: 684 inetAssociatedAsNumbers 685 ( 1.3.6.1.4.1.7161.1.5.2 NAME 'inetAssociatedAsNumbers' DESC 686 'Autonomous system numbers associated with this Internet 687 resource.' EQUALITY caseIgnoreMatch SYNTAX 688 inetAsNumberSyntax ) 689 inetAssociatedContacts 690 ( 1.3.6.1.4.1.7161.1.5.3 NAME 'inetAssociatedContacts' DESC 691 'Other contacts associated with this Internet resource.' 692 EQUALITY caseIgnoreMatch SYNTAX inetContactSyntax ) 694 inetAssociatedDnsDomains 695 ( 1.3.6.1.4.1.7161.1.5.4 NAME 'inetAssociatedDnsDomains' DESC 696 'DNS domains associated with this Internet resource.' 697 EQUALITY caseIgnoreMatch SYNTAX inetDnsDomainSyntax ) 699 inetAssociatedIpv4Networks 700 ( 1.3.6.1.4.1.7161.1.5.5 NAME 'inetAssociatedIpv4Networks' 701 DESC 'IPv4 networks associated with this Internet 702 resource.' EQUALITY caseIgnoreMatch SYNTAX 703 inetIpv4NetworkSyntax ) 705 inetAssociatedIpv6Networks 706 ( 1.3.6.1.4.1.7161.1.5.6 NAME 'inetAssociatedIpv6Networks' 707 DESC 'IPv6 networks associated with this entry.' EQUALITY 708 caseIgnoreMatch SYNTAX inetIpv6NetworkSyntax ) 710 4.2.3. Example 711 An example of the inetAssociatedResources object class is shown in 712 Figure 2 below. 714 cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com 715 [top object class] 716 [inetResources object class] 717 [inetIpv4Network object class] 718 [inetAssociatedResources object class] 719 | 720 +-attribute: description 721 | value: "The example.com network" 722 | 723 +-attribute: inetAssociatedAsNumbers 724 | value: "65535" 725 | 726 +-attribute: inetAssociatedDnsDomains 727 value: "example.com" 729 Figure 2: The inetAssociatedResources attributes associated with 730 the 192.0.2.0/24 IPv4 network entry. 732 4.3. The referral Object Class 733 This document allows the inetResources container entries and the 734 subordinate resource-specific entries to use the referral object 735 class to define subordinate reference referrals and continuation 736 reference referrals. 738 Referral entries MUST conform to the schema specification defined 739 in [RFC3296]. In particular, referral entries MUST NOT contain any 740 user-definable attributes (other than the mandatory naming 741 attribute). Referral entries MUST be leaf nodes, and MUST NOT have 742 any subordinate entries defined at the referral source. 744 In order to facilitate programmatic access to this data, LDAP URLs 745 provided in ref attributes MUST refer to entries which use the 746 same object classes as the source entry, MUST refer to an entry in 747 a directory partition which uses the domainComponent object class 748 syntax ("dc="), and MUST specify the LDAP protocol-type. 750 Refer to section 3.4 for more information on the use of referrals 751 in FIRS. 753 5. Global Query Processing Rules 754 Another critical aspect to FIRS is the query-processing behavior. 755 These rules govern the ways in which a client parses a query, 756 locates a server which is authoritative for the resource being 757 queried, generates LDAPv3 queries, and processes any resulting 758 referrals. More specifically: 760 * Query pre-processing. The first step is for the client to 761 prepare the query. Portions of this process require the 762 client to determine the type of resource being queried for, 763 and to determine the initial partition which should be used 764 for the query. Since this process is different for each 765 particular resource-type, the rules which govern this 766 behavior are defined in each of the resource-specific 767 specifications. 769 * Bootstrap processing. Once a partition has been determined, 770 the client must locate the LDAP servers which are 771 authoritative for the resource in question. Section 5.2 772 defines three different bootstrap models that clients can 773 use as part of this process, while each of the resource- 774 specific specifications define which of the models are to 775 be used for each particular resource-type. 777 * Query processing. Once a server has been located, the 778 client must submit the LDAP query which was formed during 779 the pre-preprocessing phase. Section 5.3 defines the global 780 considerations for all FIRS queries, while the resource- 781 specific specifications also define additional parameters. 783 * Query post-processing. FIRS explicitly supports different 784 types of LDAP referral mechanisms, any of which may result 785 in the client application restarting the query or 786 initiating a brand-new query. These mechanisms and their 787 behavioral rules are defined in section 5.4. 789 Each of these phases are discussed in more detail below. 791 5.1. Query Pre-Processing 792 Client input is generally provided as a single well-formed unit of 793 data, such as a domain name ("example.com") or an email address 794 ("admins@example.com"). Since this information is typically all 795 that's provided, it must be used to subsequently build a fully- 796 formed LDAPv3 query, including the assertion value, the search 797 base, the matching filter, and so forth. All of these steps are 798 part of the pre-processing phase. 800 Although the exact sequence of steps will vary according to the 801 resource-type being queried, there are some commonalities between 802 each of them. Among these steps: 804 * Determine the resource type. Different kinds of resources 805 have different processing steps, validation mechanisms, and 806 so forth, each of which require that the resource-type be 807 appropriately identified. Clients MAY use any mechanisms 808 necessary to force this determination. 810 * Validate and normalize the data. In all cases, the input 811 data MUST be validated and normalized according to the 812 syntax rules defined in the specification which governs the 813 resource-type. As an example of this step, queries for 814 internationalized domain names must be normalized into a 815 UTF-8 form before any other steps can be taken, with the 816 domain name being validated as part of the normalization 817 process. Similarly, IPv6 addresses are required to conform 818 to specific syntax rules, and input address may need to be 819 expanded or compressed in order to comply these syntax 820 requirements. 822 * Determine the appropriate directory partition for the 823 query. Different kinds of resources have different default 824 choices. In most cases, the appropriate partition will be a 825 variation of the input query string, but this is not always 826 the case. For example, the default partition for an email 827 address will be the domain component of the email address 828 itself, while the default partition for an ASN is a 829 reserved (special-purpose) domain name. In some cases, the 830 selected partition may change as a result of errors or 831 referrals encountered during later phases of the process. 833 * Determine the search base for the query. In most cases, the 834 search base will refer to the inetResources container entry 835 within the partition which was determined in the prior 836 step, with these elements being combined into an FQDN. In 837 some cases, the search base may need to be changed as a 838 result of referrals encountered during later phases of the 839 process. 841 * Determine the assertion value for the query. The assertion 842 value will usually be the normalized form of the input 843 query. In some cases, the assertion value may need to be 844 changed as a result of referrals encountered during later 845 phases of the process. 847 * Determine the matching filter. Each resource-type has its 848 own matching filter rules. In some cases, the matching 849 filter will be a simple equalityMatch comparison, while in 850 other cases the matching filter will be an extensibleMatch 851 which is peculiar to the resource-type in use. 853 Once all of the pre-processing steps have been successfully 854 completed, the client must attempt to locate an LDAPv3 server 855 which is authoritative for that resource. This process is 856 described in section 5.2 below. 858 5.2. Query Bootstrap Models 859 Once a client has determined which partition should be queried for 860 the specified resource, the client must determine which LDAP 861 servers are authoritative for that partition. 863 The FIRS service supports three different bootstrap models for 864 this process, although these models only differ in relatively 865 minor ways. Once a server has been located, the rest of the query 866 process follows the same common path (issuing the LDAPv3 query, 867 following any referrals which may be returned, and so forth). 869 The three bootstrapping models defined for use with this service 870 are the "targeted " model which is functionally identical to 871 traditional lookups for LDAP servers, the "top-down" model which 872 causes a client to submit a query to the root of a delegation 873 hierarchy, and a "bottom-up" model which causes a client to work 874 up through a delegation hierarchy until a server has been located. 876 5.2.1. Targeted Query Processing 877 The "targeted" model is similar to the traditional model of LDAP 878 lookups, in that a client queries a previously specified LDAP 879 server for a particular resource under the assumption that the 880 resource exists on that server. If the server or resource does not 881 exist (notwithstanding any referrals which may be returned), the 882 entire query fails. 884 The targeted model can be used when a fixed resource has been 885 specified (such as may occur with a URL), but can also be used if 886 the client prefers to use a "default" server for all operations. 887 The latter may occur when clients use proxy servers, caching 888 servers, or other fixed servers, in lieu of navigating the global 889 directory database with every query. In all of these cases, 890 however, failed lookups are considered to be fatal. 892 The steps for processing targeted queries are described below: 894 a. Determine the IP address and port number to be used (this 895 information may be determined from user input, a 896 configuration file, a URL, or from any other source). 898 1. If a non-ASCII domain name has been specified for this 899 purpose, convert the domain name into its ASCII- 900 compatible form using the "ToASCII" process defined in 901 [RFC3490] before performing any lookups. 903 2. Locate the LDAP servers associated with the domain 904 name through the SRV query steps provided in section 905 5.2.4. If this step fails, use DNS lookups for A 906 resource records instead. If no resource records are 907 available, report the error to the user and exit. 909 b. Once a server has been determined, submit the search 910 operation. If the search operation fails, report the error 911 to the user and exit. Otherwise, display any answer data 912 which is returned. 914 c. If the answer data contains a subordinate reference 915 referral or a continuation reference referral, new query 916 processes MUST be spawned. 918 For subordinate reference referrals, process the URLs 919 according to the rules described in section Error! 920 Reference source not found. and restart the query process 921 at step 5.2.1.a. For each continuation reference referral, 922 display the answer data received so far, process the LDAP 923 URLs according to the rules described in section Error! 924 Reference source not found. and start new query processes 925 for each referral at step 5.2.1.a, appending the output 926 from these searches to the current output. 928 Any additional subordinate reference referrals or 929 continuation reference referrals which are encountered from 930 any subsequent searches will need to be processed in the 931 same manner as specified above, until no additional 932 referrals are received. 934 d. Exit the query operation. 936 5.2.2. Top-Down Processing 937 The top-down model uses an input string to construct an LDAP 938 assertion value and search base, with DNS queries being used to 939 locate the LDAP servers associated with the appropriate top-level 940 delegation entity. Once this process completes, a query is issued 941 to the specified servers. This query may be subsequently 942 redirected to other servers through the use of LDAP referrals. 944 The top-down model is primarily suited for locating Internet 945 resources which are centrally managed and delegated, and where 946 information about the delegation is desired. In particular, this 947 includes resources such as DNS domain names, IP address blocks, 948 and AS numbers. 950 Note that the top-down model does not use incrementally larger 951 domain names for the bootstrap process. Instead, it is assumed 952 that the root partition in the delegation tree will be able to 953 provide any necessary redirection services. For example, if the 954 domain name of "www.example.co.uk" is used in a query, the query 955 will be sent to the "dc=uk" partition, which should provide a 956 referral for the "dc=co,dc=uk" partition, which in turn should 957 provide a referral for the "dc=example,dc=co,dc=uk" partition. 959 The steps for processing top-down queries are described below: 961 a. Determine the directory partition for the query. 963 1. Separate the input string into discrete elements where 964 this is possible. For a DNS domain name of 965 "www.example.com", this would be "www", "example" and 966 "com". For the IPv4 network number of "192.0.2.14", 967 this would be "192", "0", "2" and "14". AS numbers 968 only have a single value and require no separation. Do 969 not discard the original query string. 971 2. IP addresses and AS numbers require additional 972 conversion. For IPv4 addresses, strip off the prefix 973 and convert the input string into a reverse-lookup DNS 974 domain name by reversing the order of the octets and 975 appending "in-addr.arpa" to the right of the domain 976 name. For IPv6 addresses, strip off the prefix and 977 reverse the nibble order of the address (where each 978 nibble is represented by a single hexadecimal 979 character), and append "ip6.arpa". For AS numbers, 980 append only the "arpa" domain name. 982 b. Form the LDAP search base for the query. 984 1. If the client application allows non-ASCII input, 985 convert the domain name formed in step 5.2.2.a above 986 into its ASCII-compatible form using the "ToASCII" 987 process defined in RFC 3490. 989 2. Convert the right-most element from the domain name 990 formed in step 5.2.2.b.1 into a domainComponent DN 991 (such as "dc=com" or "dc=arpa"). This represents the 992 directory partition for the current query. 994 3. Append "cn=inetResources" to the front of the 995 domainComponent syntax ("cn=inetResources,dc=com"). 996 This will form the fully-qualified search base for the 997 LDAP query. 999 c. Locate the LDAP servers associated with the resource by 1000 processing the domain name formed in step 5.2.2.a above 1001 through the SRV query steps provided in section 5.2.4. 1003 d. If the SRV lookup succeeds: 1005 1. Choose the best LDAP server, using the weighting 1006 formula described in [RFC2782]. 1008 2. Formulate the LDAP search using the search base and 1009 search filter constructed earlier. For example, if the 1010 input query string was for "www.example.com", then the 1011 client would begin the process by submitting an 1012 inetDnsDomainMatch extensibleMatch search with the 1013 assertion value of "www.example.com", and with a 1014 search base of "dc=inetResources,dc=com". Similarly, 1015 if the input query string was "192.0.2.14", then the 1016 client would begin the process by submitting an 1017 inetIpv4NetworkMatch extensibleMatch search with the 1018 assertion value of "192.0.2.14/32", and with the 1019 search base of "cn=inetResources,dc=arpa". 1021 3. Submit the search operation to the chosen server and 1022 port number. If the operation fails, report the 1023 failure to the user and exit. Otherwise, display any 1024 answer data which is returned. 1026 4. If the answer data contains a subordinate reference 1027 referral or a continuation reference referral, new 1028 query processes MUST be spawned. 1030 For subordinate reference referrals, process the URLs 1031 according to the rules described in section Error! 1032 Reference source not found. and restart the query 1033 process at step 5.2.2.b. For each continuation 1034 reference referral, display the answer data received 1035 so far, process the LDAP URLs according to the rules 1036 described in section Error! Reference source not 1037 found. and start new query processes for each referral 1038 at step 5.2.2.b, appending the output from these 1039 searches to the current output. 1041 Any additional subordinate reference referrals or 1042 continuation reference referrals which are encountered 1043 from any subsequent searches will need to be processed 1044 in the same manner as specified above, until no 1045 additional referrals are received. 1047 e. If the SRV lookup fails (where failure is defined as any 1048 DNS response message other than an answer), report the 1049 failure to the user and exit the current search operation. 1051 f. Exit the query operation. 1053 5.2.3. Bottom-Up Processing 1054 The bottom-up model uses an input string to construct an LDAP 1055 assertion value and search base, with DNS queries being used to 1056 locate the LDAP servers which are associated with the management 1057 entity that is directly responsible for the resource in question. 1058 If no servers are available for that partition, the parent 1059 partition in the delegation hierarchy is used instead, with this 1060 process repeating until a server has been located. 1062 The bottom-up model is best used when a leaf-node partition needs 1063 to be queried directly, either because there is no direct 1064 delegation path for the resource in question, or because the user- 1065 managed partition is preferable to the centralized delegation 1066 information. For example, there is no global delegation body which 1067 assigns and manages contact identifiers, so these identifiers need 1068 to be directed towards the leaf-node partitions directly. The 1069 bottom-up model can also be used for other kinds of resources if 1070 desirable, although in most cases the bottom-down model will be 1071 more useful for those resources. 1073 The steps for processing bottom-up queries are described below: 1075 a. Determine the input type (DNS Domain, IPv4 Address, etc.) 1077 b. Determine the authoritative DNS domain for the resource. 1079 1. Separate the input string into discrete elements where 1080 this is possible. For a DNS domain name of 1081 "www.example.com", this would be "www", "example" and 1082 "com". For the IPv4 network number of "192.0.2.14", 1083 this would be "192", "0", "2" and "14". Do not discard 1084 the original query string. 1086 2. IP addresses require additional conversion. For IPv4 1087 addresses, strip off the prefix and convert the input 1088 string into a reverse-lookup DNS domain name by 1089 reversing the order of the octets and appending 1090 "in-addr.arpa" to the right of the resulting sequence. 1091 For IPv6 addresses, strip off the prefix and reverse 1092 the nibble order of the address (where each nibble is 1093 represented by a single hexadecimal character), and 1094 append "ip6.arpa" to the right of the resulting 1095 sequence. 1097 c. Form the LDAP search base for the query. 1099 1. If the client application allows non-ASCII input, 1100 convert the domain name formed in step 5.2.3.b above 1101 into its ASCII-compatible form using the "ToASCII" 1102 process defined in RFC 3490. 1104 2. Convert the domain name formed in step 5.2.3.c.1 above 1105 into a domainComponent DN (such as 1106 "dc=www,dc=example,dc=com" or "dc=0,dc=2,dc=0,dc=192, 1107 dc=in-addr,dc=arpa"). This represents the directory 1108 partition for the current query. 1110 3. Append the "cn=inetResources" RDN to the left of the 1111 domainComponent syntax (perhaps resulting in 1112 "cn=inetResources,dc=www,dc=example,dc=com"). This 1113 will become the search base for the LDAP query. 1115 d. Locate the LDAP servers associated with the resource by 1116 processing the domain name formed in step 5.2.3.b above 1117 through the SRV query steps provided in section 5.2.4. 1119 e. If the SRV lookup fails with an NXDOMAIN response code (as 1120 described in RFC 2308), then the domain name used for the 1121 SRV lookup does not exist, and a substitute LDAP server and 1122 search base must be used instead. This process involves 1123 determining the parent zone for the domain name in 1124 question, issuing an SRV lookup for that zone, and using 1125 the domain name of the zone as the new LDAP search base, 1126 with this process repeating until a search base can be 1127 located, or until a critical failure forces an exit. 1129 1. Remove the left-most label from the domain name formed 1130 in step 5.2.3.b. 1132 2. If this process has already resulted in a query domain 1133 name at a top-level domain such as "com" or "arpa", 1134 convert the query domain name to "." (to signify the 1135 root domain). 1137 3. If the queried domain name is already set to ".", the 1138 query can go no higher (this most likely indicates a 1139 malformed DNS configuration, a connectivity problem, 1140 or a typo in the query). Exit and report the failure 1141 to the user. 1143 4. Restart the process at step 5.2.2.b, using the domain 1144 name formed above. Repeat until a server is located or 1145 a critical failure forces an exit. 1147 For example, if the original input string of 1148 "www.example.com" resulted in a failed SRV lookup for 1149 "_ldap._tcp.www.example.com", then the first fallback 1150 SRV query would be for "_ldap._tcp.example.com", and 1151 the next fallback query would be for "_ldap._tcp.com", 1152 possibly being followed by "_ldap._tcp.", and possibly 1153 resulting in failure after that. 1155 f. If the SRV lookup succeeds: 1157 1. Choose the best LDAP server, using the weighting 1158 formula described in RFC 2782. 1160 2. Formulate the LDAP search using the search base and 1161 search filter constructed above. For example, if the 1162 input query string was for "www.example.com", then the 1163 client would begin the process by submitting an 1164 inetDnsDomainMatch extensibleMatch search with the 1165 assertion value of "www.example.com", with the search 1166 base of "cn=inetResources,dc=www,dc=example,dc=com". 1167 If the SRV lookups had failed (resulting in "com" 1168 being used as the authoritative directory partition), 1169 then the search base for the query would also be 1170 trimmed accordingly ("cn=inetResources,dc=com"). 1172 3. Submit the search operation to the chosen server and 1173 port number. If the operation fails, report the 1174 failure to the user and exit. Otherwise, display any 1175 answer data which is returned. 1177 4. If the answer data contains a subordinate reference 1178 referral or a continuation reference referral, new 1179 query processes MUST be spawned. 1181 For subordinate reference referrals, process the URLs 1182 according to the rules described in section Error! 1183 Reference source not found. and restart the query 1184 process at step 5.2.3.d. For each continuation 1185 reference referral, display the answer data received 1186 so far, process the LDAP URLs according to the rules 1187 described in section Error! Reference source not 1188 found. and start new query processes for each referral 1189 at step 5.2.3.d, appending the output from these 1190 searches to the current output. 1192 Any additional subordinate reference referrals or 1193 continuation reference referrals which are encountered 1194 from any subsequent queries will need to be processed 1195 in the same manner as specified above, until no 1196 additional referrals are received. 1198 g. If a fatal DNS error condition occurs, report the error to 1199 the user and stop processing the current query. A fatal DNS 1200 error is any response message with an RCODE of FORMERR, 1201 SERVFAIL, NOTIMPL, or REFUSED, or where a query results in 1202 NODATA (implying that an "_ldap._tcp" domain name exists 1203 but it doesn't have an SRV resource record associated with 1204 it, which is most likely a configuration error). 1206 h. Exit the query operation. 1208 5.2.4. SRV processing 1209 The bootstrapping models described in this document make use of 1210 DNS SRV resource records to locate the LDAP servers associated 1211 with the resource provided in the query input. 1213 The procedure for constructing this SRV lookup is as follows: 1215 a. Construct an SRV-specific label pair for the service type. 1216 For LDAP queries, this will be "_ldap._tcp". 1218 b. If the client allows non-ASCII characters to be input, then 1219 convert the domain name input into its ASCII-compatible 1220 form by using the "ToASCII" process described in [RFC3490]. 1222 c. Append the SRV label pair to the left of the input domain 1223 name from step 5.2.4.b. In the case of a query for the 1224 "example.com" domain, this would result in an SRV-specific 1225 domain name of "_ldap._tcp.example.com". 1227 d. Issue a DNS query for the SRV resource records associated 1228 with the domain name formed in step 5.2.4.b. 1230 Multiple SRV resource records may be returned in response to a 1231 query. Each resource record identifies a different connection 1232 target, including the domain name of a server, and a port number 1233 for that server. The port number specified in a SRV resource 1234 record MUST be used for any subsequent bind and search operations. 1236 SRV resource records provide "priority" and "weight" values which 1237 MUST be used to determine the preferred server. If a server is 1238 unavailable or unreachable, a connection attempt must be made to 1239 the next-best server in the answer set. 1241 Refer to [RFC2782] for a detailed explanation of SRV resource 1242 records and their handling. 1244 5.3. Query Processing 1245 Once an authoritative server for the partition in question has 1246 been located, the LDAP query can be submitted. In order to ensure 1247 interoperability, this specification defines several behavioral 1248 rules which clients and servers are encouraged to conform with. 1249 These guidelines are discussed in the following sections. 1251 5.3.1. Search Filters 1252 LDAP search filters are fairly flexible, in that they allow for a 1253 wide variety of configurable elements, such as the maximum number 1254 of entries which are returned, the type of comparison operation 1255 that needs to be performed, and other details. In order to ensure 1256 interoperability, default values are defined here for many of 1257 these elements. 1259 Section 4.5.1 of [RFC2251] defines the LDAP search request 1260 specification, although it does not provide guidelines or 1261 recommended values for the filter settings. In an effort to 1262 promote interoperability among FIRS clients and servers, this 1263 document defines some recommended and mandatory values for 1264 searches within the FIRS service. 1266 NOTE: These rules ONLY apply to the FIRS search operations 1267 in particular. Any queries for other resources (such as 1268 requests for inetOrgPerson contact entries) SHOULD NOT 1269 impose these restrictions. Also note that other documents 1270 which define additional resource types can also define 1271 different restrictions, and those definitions will take 1272 precedence over the global defaults. 1274 Servers MUST be prepared to enforce these rules independently of 1275 the client settings, and clients MUST be prepared to receive 1276 truncated search results accordingly. 1278 The default values of an LDAPv3 search filter in FIRS are: 1280 * Search base. The directory partition to be used in a search 1281 will vary for each query operation. The methodology for 1282 determining the current search base for a query is defined 1283 by the query-processing protocols described in section 5.1, 1284 although FIRS searches are normally constrained to the 1285 "cn=inetResources" container of a particular directory 1286 partition. 1288 * Scope. In order to support continuation reference referrals 1289 (which are defined as referral entries beneath a resource- 1290 specific entry), clients MUST use a sub-tree scope for FIRS 1291 searches. Servers MUST NOT arbitrarily limit the scope of 1292 search operations. 1294 * Dereference aliases. Although the FIRS service does not 1295 make direct use of alias entries, they are not prohibited. 1296 Clients SHOULD set the Dereference Aliases option to 1297 "Always" for FIRS searches. Servers SHOULD dereference any 1298 aliases which are encountered, where this is feasible (in 1299 particular, where the alias refers to another directory 1300 partition on the same server). 1302 * Size limit. The size limit field specifies the maximum 1303 number of entries that a server should return. For the FIRS 1304 service, this setting SHOULD be set to a value between 25 1305 and 100. This range ensures that the client is capable of 1306 receiving a sufficient number of entries and continuation 1307 references in a single response, but also works to prevent 1308 runaway queries that match everything (such as searches for 1309 "com", which can match every inetDnsDomain entry in the 1310 "cn=inetResources,dc=com" container). Servers MAY truncate 1311 answer sets to 100 responses if the client specifies a 1312 larger value. 1314 * Time limit. The time limit field specifies the maximum 1315 number of seconds that a server should process the search. 1317 For the FIRS service, this setting SHOULD be set to a value 1318 between 10 and 60 seconds. This range ensures that the 1319 server is able to process a sufficient number of entries, 1320 but also works to prevent runaway queries that match 1321 everything. Servers MAY stop processing queries after 60 1322 seconds if the client specifies a larger value. 1324 * Types-only. The types-only setting is a Boolean flag which 1325 controls whether or not attribute values are returned in 1326 the answer sets. Since excessive queries are likely to be 1327 more burdensome than larger answer sets, this setting 1328 SHOULD be set to FALSE. Resource-constrained clients (such 1329 as PDAs) MAY set this value to TRUE, but these clients MUST 1330 be prepared to issue the necessary subsequent queries. 1332 * Filter. The search operation will depend on the type of 1333 data being queried. For FIRS queries, the filter MUST use 1334 the matching rules defined for the relevant resource type. 1336 * Attribute list. Clients MAY restrict the list of attributes 1337 which are returned in searches, but are discouraged from 1338 doing so without cause. 1340 5.3.2. Authentication and access controls 1341 The restrictions listed in section 5.3.1 represent suggested 1342 defaults, although server operators MAY impose any kinds of usage 1343 limits they deem necessary or desirable. For example, server 1344 operators MAY restrict the number of queries that they will accept 1345 from a particular client and/or user over a given amount of time. 1347 Server operators MAY choose to restrict the amount of information 1348 provided to specific clients and/or users. For example, server 1349 operators MAY choose to withhold detailed contact information from 1350 anonymous users or non-privileged clients, as necessary or 1351 desirable. Clients SHOULD NOT equate the absence of any attributes 1352 with the absence of data, and SHOULD assume that the user is not 1353 authorized to view any data which has not been provided. 1355 Servers SHOULD allow anonymous authentication for read-only access 1356 to public delegation data. Clients SHOULD use anonymous 1357 authentication by default. Server operators MAY require any kind 1358 of authentication mechanisms they wish for any other data, 1359 although operators are encouraged to use one of the well-known 1360 mechanisms commonly used with LDAPv3. 1362 Clients MUST be prepared for connection requests and queries to be 1363 denied for any reason, and MUST treat these conditions as non- 1364 permanent failures. Clients MAY retry the operations if the error 1365 condition is corrected (such as having the user authenticate to 1366 the server), but SHOULD NOT automatically generate retry attempts 1367 for the failing partition (including any replicas). 1369 5.3.3. Protocol and schema version controls 1370 The FIRS collection of specifications are explicitly bound to the 1371 LDAPv3 protocol, as defined by [RFC2251]. If a new version of the 1372 LDAP protocol emerges, it is expected that some type of mechanism 1373 will be included for end-points to use when negotiating over the 1374 version in use. Lacking such a mechanism, FIRS is explicitly 1375 restricted to LDAPv3. 1377 LDAP attributes, object classes, syntaxes and matching filters 1378 have OIDs which uniquely identify the format of the data they 1379 provide, and which act as simple schema-version identifiers in the 1380 generic case. [RFC2251] defines standardized mechanisms for 1381 retrieving and reading the OIDs associated with object classes and 1382 attributes (among other resource types). These mechanisms MAY be 1383 used whenever a FIRS client reads an entry, and MUST be used 1384 whenever a FIRS client modifies or creates an entry (even though 1385 FIRS does not define mechanisms for updating entries, it is 1386 assumed that some clients will allow this behavior). 1388 Modifications to existing schema definitions MUST be accompanied 1389 by OID changes. 1391 5.4. Post-Query Processing 1392 As was discussed in section 3.4, FIRS supports two types of 1393 referrals, which are subordinate reference referrals and 1394 continuation reference referrals. Both referral types use URLs for 1395 the purpose of providing referral targets, using the rules 1396 described in section 3.4 of this document. 1398 Non-compliance with the requirements provided in section 3.4 1399 amounts to an error, and is sufficient cause for a client to stop 1400 processing a query. 1402 As was discussed in section 3.4, subordinate reference referrals 1403 are defined in [RFC3296], and use the SearchResultDone response 1404 with a Referral result code as defined in [RFC2251]. Subordinate 1405 reference referrals use a subset of the labeledURI syntax as 1406 defined in [RFC2079], and use the syntax definitions from 1407 [RFC2255] when LDAP URLs in particular are provided, although 1408 section 3.4 of this document also defines additional restrictions 1409 on the allowable URL syntax. This condition means that the current 1410 search operation cannot proceed past this point, and the search 1411 MUST be restarted. This will most often occur when the 1412 inetResources entry for a partition has been redirected to another 1413 directory partition. 1415 Meanwhile, continuation reference referrals use the 1416 SearchResultReference response, which is defined and described in 1417 section 4.5.3 of [RFC2251]. Continuation reference referrals use a 1418 subset of the labeledURI syntax as defined in [RFC2079], and use 1419 the syntax definitions from [RFC2255] when LDAP URLs in particular 1420 are to be provided, although section 3.4 of this document also 1421 defines additional restrictions on the allowable URL syntax. This 1422 condition means that the current search operation has partially 1423 succeeded, but that additional searches SHOULD be started in order 1424 for all of the answer data to be retrieved (in many cases, no 1425 answer data will be provided, and in those situations, new queries 1426 will be required for any data to be retrieved). This will occur 1427 whenever the assertion value of a search has matched a resource 1428 entry which is being managed by another directory partition, and 1429 can occur with any of the search operations described in this 1430 document. 1432 The procedure for processing referral URLs is as follows: 1434 a. [RFC2251] allows multiple URLs to be provided, although the 1435 URLs are not provided with any "preference" or "weighting" 1436 values. If a set of URLs are provided, only one of the URLs 1437 need to be tried (implementations MAY perform additional 1438 queries in an attempt to recover from temporary failures, 1439 although this is not required). Select one of the URLs at 1440 random ("round-robin"), and continue to the next step in 1441 the process. 1443 b. Validate the protocol label. FIRS only supports the use of 1444 the LDAP service type. URLs with other protocol identifiers 1445 are to be treated as malformed. 1447 c. Extract the port number provided with the URL, and set it 1448 aside for use with the subsequent connection attempt. If no 1449 port number has been provided in the URL, use the default 1450 port numbers associated with the protocol, as discovered in 1451 step 5.4.b as a default value. 1453 d. Determine the authoritative partition and search base 1454 specified in the referral URL. 1456 1. If no distinguished name element was provided, report 1457 the failure to the user and exit. 1459 2. Otherwise, use the distinguished name element for the 1460 search base of the subsequent search operation. 1462 3. Extract the right-most sequence of domainComponent 1463 distinguished names from the search base, and use them 1464 as the authoritative partition. 1466 e. Determine the server address and port number specified in 1467 the referral URL. 1469 1. If the host identifier is an IP address, extract it 1470 and skip to step 5.4.f. 1472 2. If no port number was provided in the URL, submit a 1473 DNS lookup for the SRV resource records associated 1474 with the domain name, as described in section 5.2.4. 1476 3. If a port number was provided or if the SRV lookup 1477 fails, submit a DNS lookup for the A resource records. 1479 4. If a host identifier was not provided, map the 1480 domainComponent elements determined in step 5.4.d to a 1481 DNS domain name and submit an SRV DNS lookup for the 1482 LDAP servers associated with that domain name. If this 1483 final step fails, report the error to the user and 1484 exit the query. 1486 f. Determine the new assertion value and/or matching filter 1487 specified in the referral URL. 1489 1. If the URL's path element does not contain a filter 1490 element, reuse the current matching filter and 1491 assertion value. 1493 2. If the URL's path element contains a filter element, 1494 use it to form the new matching filter and/or 1495 assertion value. 1497 g. Discard the remainder of the URL. 1499 h. Use the discovered parameter values to start a new query. 1501 6. Security Considerations 1502 Security considerations are discussed in [FIRS-ARCH]. 1504 7. IANA Considerations 1505 IANA considerations are discussed in [FIRS-ARCH]. 1507 8. Author's Addresses 1508 Eric A. Hall 1509 ehall@ehsco.com 1511 9. Normative References 1512 [RFC1274] Barker, P., and Kille, S. "The COSINE and 1513 Internet X.500 Schema", RFC 1274, November 1514 1991. 1516 [RFC2079] Smith, M. "Definition of an X.500 Attribute 1517 Type and an Object Class to Hold Uniform 1518 Resource Identifiers (URIs)", RFC 2079, 1519 January 1997. 1521 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 1522 and Sataluri, S. "Using Domains in LDAP/X.500 1523 DNs", RFC 2247, January 1998. 1525 [RFC2251] Wahl, M., Howes, T., and Kille, S. 1526 "Lightweight Directory Access Protocol (v3)", 1527 RFC 2251, December 1997. 1529 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 1530 S. "Lightweight Directory Access Protocol 1531 (v3): Attribute Syntax Definitions", RFC 2252, 1532 December 1997. 1534 [RFC2253] Wahl, M., Kille, S., and Howes, T. 1535 "Lightweight Directory Access Protocol (v3): 1536 UTF-8 String Representation of DNs", RFC 2253, 1537 December 1997. 1539 [RFC2254] Howes, T. "The String Representation of LDAP 1540 Search Filters", RFC 2254, December 1997. 1542 [RFC2255] Howes, T., and Smith, M. "The LDAP URL 1543 Format", RFC 2255, December 1997. 1545 [RFC2256] Wahl, M. "A Summary of the X.500(96) User 1546 Schema for use with LDAPv3", RFC 2256, 1547 December 1997. 1549 [RFC2277] Alvestrand, H. "IETF Policy on Character Sets 1550 and Languages", BCP 18, RFC 2277, January 1551 1998. 1553 [RFC2308] Andrews, M. "Negative Caching of DNS Queries 1554 (DNS NCACHE)", RFC 2308, March 1998. 1556 [RFC2596] Wahl, M., and Howes, T. "Use of Language Codes 1557 in LDAP", RFC 2596, May 1999. 1559 [RFC2782] Gulbrandsen, A., Vixie, P., and Esibov, L. "A 1560 DNS RR for specifying the location of services 1561 (DNS SRV)", RFC 2782, February 2000. 1563 [RFC2798] Smith, M. "Definition of the inetOrgPerson 1564 LDAP Object Class", RFC 2798, April 2000. 1566 [RFC3296] Zeilenga, K. "Named Subordinate References in 1567 Lightweight Directory Access Protocol (LDAP) 1568 Directories", RFC 3296, July 2002. 1570 [RFC3377] Hodges, J., and Morgan, R. "Lightweight 1571 Directory Access Protocol (v3): Technical 1572 Specification", RFC 3377, September 2002. 1574 [RFC3490] Faltstrom, P., Hoffman, P., and Costello, A. 1575 "Internationalizing Domain Names in 1576 Applications (IDNA)", RFC 3490, March 2003. 1578 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 1579 Service: Architecture and Implementation 1580 Guide", draft-ietf-crisp-firs-arch-00, May 1581 2003. 1583 [FIRS-ASN] Hall, E. "Defining and Locating Autonomous 1584 System Numbers in the Federated Internet 1585 Registry Service", draft-ietf-crisp-firs-asn- 1586 00, May 2003. 1588 [FIRS-CONTCT] Hall, E. "Defining and Locating Contact 1589 Persons in the Federated Internet Registry 1590 Service", draft-ietf-crisp-firs-contact-00, 1591 May 2003. 1593 [FIRS-CORE] Hall, E. "The Federated Internet Registry 1594 Service: Core Elements", draft-ietf-crisp- 1595 firs-core-00, May 2003. 1597 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in 1598 the Federated Internet Registry Service", 1599 draft-ietf-crisp-firs-dns-00, May 2003. 1601 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 1602 Records in the Federated Internet Registry 1603 Service", draft-ietf-crisp-firs-dnsrr-00, May 1604 2003. 1606 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 1607 Blocks in the Federated Internet Registry 1608 Service", draft-ietf-crisp-firs-ipv4-00, May 1609 2003. 1611 [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address 1612 Blocks in the Federated Internet Registry 1613 Service", draft-ietf-crisp-firs-ipv6-00, May 1614 2003. 1616 [US-ASCII] Cerf, V. "ASCII format for Network 1617 Interchange", RFC 20, October 1969. 1619 10. Acknowledgments 1620 Funding for the RFC editor function is currently provided by the 1621 Internet Society. 1623 Portions of this document were funded by Verisign Labs. 1625 The first version of this specification was co-authored by Andrew 1626 Newton of Verisign Labs, and subsequent versions continue to be 1627 developed with his active participation. 1629 11. Changes from Previous Versions 1630 draft-ietf-crisp-fir-core-00: 1632 * Restructured document set, separating the architectural 1633 discussion from the technical descriptions. Several 1634 sections were relocated to [FIRS-ARCH] as a result of this 1635 change. 1637 * "Attribute references" have been eliminated from the 1638 specification. All referential attributes now provide 1639 actual data instead of URL pointers to data. Clients that 1640 wish to retrieve these values will need to start new 1641 queries using the data values instead of URLs. 1643 * The various modified* operational attributes in the core 1644 schema have been eliminated as unnecessary. 1646 * Several attributes had their OIDs changed. NOTE THAT THIS 1647 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 1648 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 1650 draft-ietf-crisp-lw-core-00: 1652 * As a result of the formation of the CRISP working group, 1653 the original monolithic document has been broken into 1654 multiple documents, with draft-ietf-crisp-lw-core 1655 describing the core service, while related documents 1656 describe the per-resource schema and access mechanisms. 1658 * References to the ldaps: URL scheme have been removed, 1659 since there is no standards-track specification for the 1660 ldaps: scheme. 1662 * An acknowledgements section was added. 1664 draft-hall-ldap-whois-01: 1666 * The �Objectives� section has been removed. [ir-dir-req] is 1667 now being used as the guiding document for this service. 1669 * Several typographical errors have been fixed. 1671 * Some unnecessary text has been removed. 1673 * Figures changed to show complete sets of object classes, to 1674 improve inheritance visibility. 1676 * Clarified the handling of reverse-lookup domains (zones 1677 within the in-addr.arpa portion of the DNS hierarchy) in 1678 the inetDnsDomain object class reference text. 1680 * Referrals now use regular LDAP URLs (multiple responses 1681 with explicit hostnames and port numbers). Prior editions 1682 of this specification used LDAP SRV resource records for 1683 all referrals. 1685 * The delegation status codes used by the 1686 inetDnsDelegationStatus, inetIpv4DelegationStatus, 1687 inetIpv6DelegationStatus and inetAsnDelegationStatus 1688 attributes have been condensed to a more logical set. 1690 * Added an inetDnsAuthServers attribute for publishing the 1691 authoritative DNS servers associated with a domain. NOTE 1692 THAT THIS IS A TEMPORARY ATTRIBUTE THAT WILL EVENTUALLY BE 1693 REPLACED BY GENERALIZED RESOURCE-RECORD ENTRIES AND 1694 ATTRIBUTES. 1696 * Added an inetGeneralDisclaimer attribute for publishing 1697 generalized disclaimers. 1699 * Added the inetAssociatedResources auxiliary object class 1700 for defining associated resources, and moved some of the IP 1701 addressing and ASN attributes to the new object class. 1703 * Several attributes had their OIDs changed. NOTE THAT THIS 1704 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 1705 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 1707 12. Full Copyright Statement 1708 Copyright (C) The Internet Society (2003). All Rights Reserved. 1710 This document and translations of it may be copied and furnished 1711 to others, and derivative works that comment on or otherwise 1712 explain it or assist in its implementation may be prepared, 1713 copied, published and distributed, in whole or in part, without 1714 restriction of any kind, provided that the above copyright notice 1715 and this paragraph are included on all such copies and derivative 1716 works. However, this document itself may not be modified in any 1717 way, such as by removing the copyright notice or references to the 1718 Internet Society or other Internet organizations, except as needed 1719 for the purpose of developing Internet standards in which case the 1720 procedures for copyrights defined in the Internet Standards 1721 process must be followed, or as required to translate it into 1722 languages other than English. 1724 The limited permissions granted above are perpetual and will not 1725 be revoked by the Internet Society or its successors or assigns. 1727 This document and the information contained herein is provided on 1728 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1729 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1730 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1731 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1732 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.