idnits 2.17.1 draft-ietf-crisp-firs-contact-01.txt: 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: ---------------------------------------------------------------------------- No issues found here. 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 abstract seems to contain references ([FIRS-CORE], [FIRS-ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 7623 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: 'RFC3490' is mentioned on line 278, but not defined ** Obsolete undefined reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) == Missing Reference: 'RFC2596' is mentioned on line 216, but not defined ** Obsolete undefined reference: RFC 2596 (Obsoleted by RFC 3866) == Unused Reference: 'RFC2247' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'RFC2251' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'RFC2252' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'RFC2254' is defined on line 433, but no explicit reference was found in the text == 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' ** 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 2254 (Obsoleted by RFC 4510, RFC 4515) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Downref: Normative reference to an Informational RFC: RFC 2798 Summary: 10 errors (**), 0 flaws (~~), 16 warnings (==), 10 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-contact-01.txt May 2003 4 Expires: December, 2003 5 Category: Standards-Track 7 Defining and Locating Contact Information 8 in the Federated Internet Registry Service 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 defines LDAP schema and searching rules for contact 39 persons, in support of the Federated Internet Registry Service 40 (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. 42 Table of Contents 44 1. Introduction...............................................2 45 2. Prerequisites and Terminology..............................2 46 3. Naming Syntax..............................................3 47 4. Object Classes and Attributes..............................5 48 5. Query Processing Rules.....................................6 49 5.1. Query Pre-Processing....................................7 50 5.2. Query Bootstrapping.....................................7 51 5.3. LDAP Matching...........................................8 52 5.4. Example Query...........................................8 53 6. Security Considerations....................................9 54 7. IANA Considerations........................................9 55 8. Author's Addresses.........................................9 56 9. Normative References.......................................9 57 10. Acknowledgments...........................................10 58 11. Changes from Previous Versions............................11 59 12. Full Copyright Statement..................................11 61 1. Introduction 63 This specification defines the naming syntax, object classes, 64 attributes, matching filters, and query processing rules for 65 storing and locating contact persons in the FIRS service. Refer to 66 [FIRS-ARCH] for information on the FIRS architecture and 67 [FIRS-CORE] for the schema definitions and rules which govern the 68 FIRS service as a whole. 70 The definitions in this specification are intended to be used with 71 FIRS. Their usage outside of FIRS is not prohibited, but any such 72 usage is beyond this specification's scope of authority. 74 2. Prerequisites and Terminology 76 The complete set of specifications in the FIRS collection 77 cumulative define a structured and distributed information service 78 using LDAPv3 for the data-formatting and transport functions. This 79 specification should be read in the context of the complete set of 80 specifications, which currently include the following: 82 draft-ietf-crisp-firs-arch-01, "The Federated Internet 83 Registry Service: Architecture and Implementation" [FIRS- 84 ARCH] 85 draft-ietf-crisp-firs-core-01, "The Federated Internet 86 Registry Service: Core Elements" [FIRS-CORE] 88 draft-ietf-crisp-firs-dns-01, "Defining and Locating DNS 89 Domains in the Federated Internet Registry Service" 90 [FIRS-DNS] 92 draft-ietf-crisp-firs-dnsrr-01, "Defining and Locating DNS 93 Resource Records in the Federated Internet Registry 94 Service" [FIRS-DNSRR] 96 draft-ietf-crisp-firs-contact-01, "Defining and Locating 97 Contact Persons in the Federated Internet Registry Service" 98 (this document) [FIRS-CONTCT] 100 draft-ietf-crisp-firs-asn-01, "Defining and Locating 101 Autonomous System Numbers in the Federated Internet 102 Registry Service" [FIRS-ASN] 104 draft-ietf-crisp-firs-ipv4-01, "Defining and Locating IPv4 105 Address Blocks in the Federated Internet Registry Service" 106 [FIRS-IPV4] 108 draft-ietf-crisp-firs-ipv6-01, "Defining and Locating IPv6 109 Address Blocks in the Federated Internet Registry Service" 110 [FIRS-IPV6] 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 113 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 114 in this document are to be interpreted as described in RFC 2119. 116 3. Naming Syntax 118 The naming syntax for contact entries in FIRS MUST follow the form 119 of "cn=,cn=inetResources,", where 120 is an email address representing a contact 121 resource, and where is a sequence of domainComponent 122 relative distinguished names which identifies the scope of 123 authority for the selected directory partition. 125 The inetContactSyntax is unstructured, in that it uses 126 standardized procedures to produce heavily-normalized email 127 addresses rather than using structured syntax rules. The principle 128 reason for this is due to conflicting syntax rules in different 129 canonical email addressing rules, with these rules preventing the 130 use of a common syntax. 132 The normalization procedure produces UTF-8 [RFC2279] email 133 addresses as output, with these domain names being suitable for 134 direct comparisons, substring searches, and other lightweight 135 comparisons. Servers tend to be more heavily-loaded than clients, 136 and requiring the data to be normalized before it is used for 137 comparison operations ensures that a broader range of comparison 138 operations can be performed with minimal impact on those servers. 140 This normalization procedure is as follows: 142 a. Email addresses MUST contain three elements, which are a 143 localpart element, an "at" sign ("@") separator character, 144 and a domain element. 146 b. The localpart element is currently unspecified, pending 147 ongoing effort to internationalize this element. Subsequent 148 versions of this specification may define specific handling 149 rules for this element. 151 c. The domain element MUST be normalized according to the 152 inetDnsDomainSyntax procedure defined in [FIRS-DNS]. 154 Once all of these steps have successfully completed, the email 155 address can be stored in the directory or used as an assertion 156 value. Any fatal error conditions encountered during these 157 conversions MUST result in a local failure; FIRS-aware 158 applications MUST NOT store or transmit non-normalized email 159 addresses for any purposes. 161 The inetContactSyntax syntax is as follows: 163 inetContactSyntax 164 ( 1.3.6.1.4.1.7161.1.7.1 NAME 'inetContactSyntax' DESC 'A 165 fully-qualified email address.' ) 167 Note that the use of the "at" separator character is illegal as 168 data in URLs, and these characters will be escaped before they are 169 stored in a URL as data. 171 Also note that UTF-8 characters use character codes which are 172 frequently illegal as data in URLs, and many of those octet values 173 will probably be escaped before they are stored in a URL as data. 175 4. Object Classes and Attributes 177 Contact entries in FIRS MUST use the inetOrgPerson object class as 178 defined in RFC 2798 [RFC2798], in addition to the mandatory object 179 classes defined in [FIRS-CORE]. Contact entries MUST be treated as 180 containers capable of holding subordinate entries. If an entry 181 exists as a referral source, the entry MUST also be defined with 182 the referral object class, in addition to the above requirements. 184 The inetOrgPerson object class is a structural object class. The 185 inetOrgPerson object class has three mandatory attributes (cn, sn, 186 and objectClass), and has several optional attributes. Contact 187 entries also inherit the attributes defined in the inetResources 188 object class when they are used with FIRS. 190 Refer to [RFC2798] for the inetOrgPerson schema definitions. 192 Note that the "mail" attribute defined for use with the 193 inetOrgPerson object class is restricted to seven-bit character 194 codes and is typically interpreted as [US-ASCII], and is therefore 195 not compatible with the inetContactSyntax rules defined in section 196 3. As such, if the mail domain uses an internationalized domain 197 name, the domain element of the mail attribute MUST be reduced to 198 its ASCII-compatible form using the ToASCII process defined in 199 [RFC3490], and MUST NOT use the UTF-8 encoding. 201 Note that International postal regulations generally require that 202 the recipient address on an envelope be provided in a language and 203 charset which is native to the recipient's country, with the 204 exception of the destination country name which should be provided 205 in a language and charset that is native to the sender's country. 206 This model ensures that the sender's post office will be able to 207 route the mail to the recipient's country, while also ensuring 208 that the destination country's post office will be able to perform 209 local delivery. In order to facilitate this usage, the country 210 attribute value MAY (encouraged) be localized to the local user's 211 nomenclature for a country, but other postal address information 212 SHOULD NOT be localized. 214 Notwithstanding the above, it is ENCOURAGED that contact names be 215 provided in English forms in order to facilitate inter-party 216 communications, using the mechanisms offered by [RFC2596]. For 217 example, the default contact entry for a person in Japan SHOULD be 218 provided in the native form for that person, but an English form 219 is also ENCOURAGED in order to allow non-Japanese users to 220 properly address that person in subsequent communications. As 221 stated in the preceding paragraph however, any postal 222 communications for that person SHOULD use the native-language 223 representation (at least on the envelope) in order to facilitate 224 the delivery of postal mail. 226 An example of the inetOrgPerson object class in use is shown in 227 Figure 1 below. The example includes attributes from the 228 inetOrgPerson, inetResources, and inetAssociatedResources object 229 classes. 231 cn=admins@example.com,cn=inetResources,dc=example,dc=com 232 [top object class] 233 [inetResources object class] 234 [inetOrgPerson object class] 235 [inetAssociatedResources object class] 236 | 237 +-attribute: description 238 | value: "Administrators for the example.com network." 239 | 240 +-attribute: givenName 241 | value: "Network" 242 | 243 +-attribute: sn 244 | value: "Administrators" 245 | 246 +-attribute: mail 247 | value: "admins@example.com" 248 | 249 +-attribute: inetAssociatedDnsDomain 250 | value: "example.com" 251 | value: "2.0.192.in-addr.arpa" 252 | 253 +-attribute: inetAssociatedIpv4Network 254 value: "192.0.2.0/24" 256 Figure 1: The entry for the admins@example.com contact in the 257 dc=netsol,dc=com partition. 259 5. Query Processing Rules 261 Queries for contact entries have several special requirements, as 262 discussed in the following sections. 264 Refer to [FIRS-CORE] for general information about FIRS queries. 266 5.1. Query Pre-Processing 268 Clients MUST ensure that the query input is normalized according 269 to the rules specified in section 3 before the input is used as 270 the assertion value to the resulting LDAP query. 272 The authoritative partition for a contact entry is determined by 273 mapping the domain element of a normalized email address to a 274 sequence of domainComponent labels. 276 Since the domainComponent attribute is restricted to seven-bit 277 characters, the domain element MUST be converted to its IDNA form 278 using the "ToASCII" conversion operation specified in [RFC3490], 279 with the "UseSTD3ASCIIRules" flag disabled (FIRS applications MAY 280 reuse the output from the conversion performed in step 3.c if the 281 entire conversion process is known to have completed 282 successfully). The resulting sequence of ASCII labels are used to 283 form the domainComponent sequence which represents the 284 authoritative partition for the email address. 286 As a simple example, "admins@example.com" would be mapped to the 287 "dc=example,dc=com" authoritative partition, with this partition 288 being used to seed the query process. 290 5.2. Query Bootstrapping 292 FIRS clients MUST use the bottom-up bootstrap model by default for 293 contact queries. As such, the search base for default queries 294 would be set to the complete sequence of domainComponent relative 295 distinguished names of the authoritative partition. 297 FIRS clients MAY use the targeted or top-down bootstrap models for 298 queries if necessary or desirable. However, it is not likely that 299 entries will be found for all possible contacts using these models 300 (the "dc=com" partition is not likely to have entries for all of 301 the possible contacts with mailboxes in the "com" hierarchy, for 302 example). As such, the bottom-up bootstrap model will be the most 303 useful in most cases, and MUST be used by default. 305 Note that registration bodies can allocate email addresses within 306 their own managed portion of the DNS namespace if predictability 307 is at a premium. For example, a registrar could assign 308 "user@registrar.com" email addresses to the contact entries that 309 it creates, thereby ensuring that the contact entries are always 310 locatable and managed. 312 5.3. LDAP Matching 314 FIRS clients MUST specify equalityMatch matching filters in LDAP 315 searches for contact entries. 317 In order to ensure that all of the relevant entries are found 318 (including any referrals), the search filters for these resources 319 MUST specify the inetOrgPerson object class and the naming element 320 of the resource as a distinguished name attribute. For example, 321 "(&(objectclass=inetOrgPerson)(cn:dn:admins@example.com))" with a 322 search base of "cn=inetResources,dc=netsol,dc=com" would find all 323 of the inetOrgPerson object class entries with a relative 324 distinguished name of "cn=admins@example.com" in the 325 "dc=netsol,dc=com" partition. 327 The matching filters defined in this specification MUST be 328 supported by FIRS clients and servers. FIRS servers MAY support 329 additional sub-string filters, soundex filters, or any other 330 filters they wish (these may be required to support generic LDAP 331 clients), although FIRS clients MUST NOT expect any additional 332 filters to be available. 334 5.4. Example Query 336 The following example assumes that the user has specified 337 "admins@example.com" as the query value: 339 a. Normalize the input, which is "admins@example.com" in this 340 case. 342 b. Determine the authoritative partition, which is 343 "dc=example,dc=com" in this case. By default, queries for 344 contacts use the bottom-up model, meaning that the fully- 345 qualified distinguished name of "dc=example,dc=com" will be 346 used. 348 c. Determine the search base for the query, which will be 349 "cn=inetResources,dc=example,dc=com" if the defaults are 350 used. 352 d. Initiate a DNS lookup for the SRV resource records 353 associated with "_ldap._tcp.example.com." For the purpose 354 of this example, assume that this lookup succeeds, with the 355 DNS response message indicating that "firs.example.com" is 356 the preferred LDAP server. 358 e. Submit an LDAPv3 query to the specified server, using 359 "(&(objectClass=inetOrgPerson)(cn:dn:admins@example.com))" 360 as the matching filter, 361 "cn=inetResources,dc=example,dc=com" as the search base, 362 and the global query defaults defined in [FIRS-CORE]. 364 f. Assume that no referrals are received. Display the answer 365 data which has been received and exit the query. 367 6. Security Considerations 369 Security considerations are discussed in [FIRS-ARCH]. 371 7. IANA Considerations 373 IANA considerations are discussed in [FIRS-ARCH]. 375 8. Author's Addresses 377 Eric A. Hall 378 ehall@ehsco.com 380 9. Normative References 382 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 383 Service: Architecture and Implementation 384 Guide", draft-ietf-crisp-firs-arch-01, May 385 2003. 387 [FIRS-ASN] Hall, E. "Defining and Locating Autonomous 388 System Numbers in the Federated Internet 389 Registry Service", draft-ietf-crisp-firs-asn- 390 01, May 2003. 392 [FIRS-CONTCT] Hall, E. "Defining and Locating Contact 393 Persons in the Federated Internet Registry 394 Service", draft-ietf-crisp-firs-contact-01, 395 May 2003. 397 [FIRS-CORE] Hall, E. "The Federated Internet Registry 398 Service: Core Elements", draft-ietf-crisp- 399 firs-core-01, May 2003. 401 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in 402 the Federated Internet Registry Service", 403 draft-ietf-crisp-firs-dns-01, May 2003. 405 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 406 Records in the Federated Internet Registry 407 Service", draft-ietf-crisp-firs-dnsrr-01, May 408 2003. 410 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 411 Blocks in the Federated Internet Registry 412 Service", draft-ietf-crisp-firs-ipv4-01, May 413 2003. 415 [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address 416 Blocks in the Federated Internet Registry 417 Service", draft-ietf-crisp-firs-ipv6-01, May 418 2003. 420 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 421 and Sataluri, S. "Using Domains in LDAP/X.500 422 DNs", RFC 2247, January 1998. 424 [RFC2251] Wahl, M., Howes, T., and Kille, S. 425 "Lightweight Directory Access Protocol (v3)", 426 RFC 2251, December 1997. 428 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 429 S. "Lightweight Directory Access Protocol 430 (v3): Attribute Syntax Definitions", RFC 2252, 431 December 1997. 433 [RFC2254] Howes, T. "The String Representation of LDAP 434 Search Filters", RFC 2254, December 1997. 436 [RFC2279] Yergeau, F. "UTF-8, a transformation format of 437 ISO 10646", RFC 2279, January 1998. 439 [RFC2798] Smith, M. "Definition of the inetOrgPerson 440 LDAP Object Class", RFC 2798, April 2000. 442 [US-ASCII] Cerf, V. "ASCII format for Network 443 Interchange", RFC 20, October 1969. 445 10. Acknowledgments 447 Funding for the RFC editor function is currently provided by the 448 Internet Society. 450 Portions of this document were funded by Verisign Labs. 452 The first version of this specification was co-authored by Andrew 453 Newton of Verisign Labs, and subsequent versions continue to be 454 developed with his active participation. 456 11. Changes from Previous Versions 458 draft-ietf-crisp-firs-contact-01: 460 * Several clarifications and corrections have been made. 462 draft-ietf-crisp-firs-contact-00: 464 * Restructured the document set. 466 * "Attribute references" have been eliminated from the 467 specification. All referential attributes now provide 468 actual data instead of URL pointers to data. Clients that 469 wish to retrieve these values will need to start new 470 queries using the data values instead of URLs. 472 draft-ietf-crisp-lw-user-01: 474 * Removed references to LDAPS (LDAP-over-SSL), which is not a 475 standards-track protocol. 477 * Added a discussion on localization considerations. 479 * Moved attribute-specific security requirements to the 480 Security section. 482 12. Full Copyright Statement 484 Copyright (C) The Internet Society (2003). All Rights Reserved. 486 This document and translations of it may be copied and furnished 487 to others, and derivative works that comment on or otherwise 488 explain it or assist in its implementation may be prepared, 489 copied, published and distributed, in whole or in part, without 490 restriction of any kind, provided that the above copyright notice 491 and this paragraph are included on all such copies and derivative 492 works. However, this document itself may not be modified in any 493 way, such as by removing the copyright notice or references to the 494 Internet Society or other Internet organizations, except as needed 495 for the purpose of developing Internet standards in which case the 496 procedures for copyrights defined in the Internet Standards 497 process must be followed, or as required to translate it into 498 languages other than English. 500 The limited permissions granted above are perpetual and will not 501 be revoked by the Internet Society or its successors or assigns. 503 This document and the information contained herein is provided on 504 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 505 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 506 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 507 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 508 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.