idnits 2.17.1 draft-ietf-crisp-firs-contact-02.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 (July 2003) is 7588 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) == Unused Reference: 'FIRS-CONTCT' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'RFC2247' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'RFC2251' is defined on line 389, but no explicit reference was found in the text == Unused Reference: 'RFC2252' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'RFC2254' is defined on line 398, 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) ** Obsolete normative reference: RFC 2596 (Obsoleted by RFC 3866) ** Downref: Normative reference to an Informational RFC: RFC 2798 ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) Summary: 10 errors (**), 0 flaws (~~), 15 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-02.txt July 2003 4 Expires: February, 2004 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..............................4 48 5. Query Processing Rules.....................................6 49 5.1. Query Pre-Processing....................................6 50 5.2. Query Bootstrapping.....................................7 51 5.3. LDAP Matching...........................................7 52 5.4. Example Query...........................................8 53 6. Security Considerations....................................8 54 7. IANA Considerations........................................9 55 8. Normative References.......................................9 56 9. Changes from Previous Versions............................10 57 10. Author's Addresses........................................11 58 11. Acknowledgments...........................................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 that set, which 80 currently includes [FIRS-ARCH], [FIRS-CORE], [FIRS-DNS], 81 [FIRS-DNSRR], [FIRS-ASN], [FIRS-IPV4] and [FIRS-IPV6]. 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 84 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 85 in this document are to be interpreted as described in RFC 2119. 87 3. Naming Syntax 89 The naming syntax for contact entries in FIRS MUST follow the form 90 of "cn=,cn=inetResources,", where 91 is an email address representing a contact 92 resource, and where is a sequence of domainComponent 93 relative distinguished names which identifies the scope of 94 authority for the selected directory partition. 96 The inetContactSyntax is unstructured, in that it uses 97 standardized procedures to produce heavily-normalized email 98 addresses rather than using structured syntax rules. The principle 99 reason for this is due to conflicting syntax rules in different 100 canonical email addressing rules, with these rules preventing the 101 use of a common syntax. 103 The normalization procedure produces UTF-8 [RFC2279] email 104 addresses as output, with these domain names being suitable for 105 direct comparisons, substring searches, and other lightweight 106 comparisons. Servers tend to be more heavily-loaded than clients, 107 and requiring the data to be normalized before it is used for 108 comparison operations ensures that a broader range of comparison 109 operations can be performed with minimal impact on those servers. 111 This normalization procedure is as follows: 113 a. Email addresses MUST contain three elements, which are a 114 localpart element, an "at" sign ("@") separator character, 115 and a domain element. 117 b. The localpart element is currently unspecified, pending 118 ongoing effort to internationalize this element. Subsequent 119 versions of this specification may define specific handling 120 rules for this element. 122 c. The domain element MUST be normalized according to the 123 inetDnsDomainSyntax procedure defined in [FIRS-DNS]. 125 Once all of these steps have successfully completed, the email 126 address can be stored in the directory or used as an assertion 127 value. Any fatal error conditions encountered during these 128 conversions MUST result in a local failure; FIRS-aware 129 applications MUST NOT store or transmit non-normalized email 130 addresses for any purposes. 132 The inetContactSyntax syntax is as follows: 134 inetContactSyntax 135 ( 1.3.6.1.4.1.7161.1.4.1 NAME 'inetContactSyntax' DESC 'A 136 fully-qualified email address.' ) 138 Note that the use of the "at" separator character is illegal as 139 data in URLs, and these characters will be escaped before they are 140 stored in a URL as data. 142 Also note that UTF-8 characters use character codes which are 143 frequently illegal as data in URLs, and many of those octet values 144 will probably be escaped before they are stored in a URL as data. 146 4. Object Classes and Attributes 148 Contact entries in FIRS MUST use the inetOrgPerson object class as 149 defined in RFC 2798 [RFC2798], in addition to the mandatory object 150 classes defined in [FIRS-CORE]. Contact entries MUST be treated as 151 containers capable of holding subordinate entries. If an entry 152 exists as a referral source, the entry MUST also be defined with 153 the referral object class, in addition to the above requirements. 155 The inetOrgPerson object class is a structural object class. The 156 inetOrgPerson object class has three mandatory attributes (cn, sn, 157 and objectClass), and has several optional attributes. Contact 158 entries also inherit the attributes defined in the inetResources 159 object class when they are used with FIRS. 161 Refer to [RFC2798] for the inetOrgPerson schema definitions. 163 Note that the "mail" attribute defined for use with the 164 inetOrgPerson object class is restricted to seven-bit character 165 codes and is typically interpreted as [US-ASCII], and is therefore 166 not compatible with the inetContactSyntax rules defined in section 167 3. As such, if the mail domain uses an internationalized domain 168 name, the domain element of the mail attribute MUST be reduced to 169 its ASCII-compatible form using the ToASCII process defined in 170 [RFC3490], and MUST NOT use the UTF-8 encoding. 172 Note that International postal regulations generally require that 173 the recipient address on an envelope be provided in a language and 174 charset which is native to the recipient's country, with the 175 exception of the destination country name which should be provided 176 in a language and charset that is native to the sender's country. 178 This model ensures that the sender's post office will be able to 179 route the mail to the recipient's country, while also ensuring 180 that the destination country's post office will be able to perform 181 local delivery. In order to facilitate this usage, the country 182 attribute value MAY (encouraged) be localized to the local user's 183 nomenclature for a country, but other postal address information 184 SHOULD NOT be localized. 186 Notwithstanding the above, it is ENCOURAGED that contact names be 187 provided in English forms in order to facilitate inter-party 188 communications, using the mechanisms offered by [RFC2596]. For 189 example, the default contact entry for a person in Japan SHOULD be 190 provided in the native form for that person, but an English form 191 is also ENCOURAGED in order to allow non-Japanese users to 192 properly address that person in subsequent communications. As 193 stated in the preceding paragraph however, any postal 194 communications for that person SHOULD use the native-language 195 representation (at least on the envelope) in order to facilitate 196 the delivery of postal mail. 198 An example of the inetOrgPerson object class in use is shown in 199 Figure 1 below. The example includes attributes from the 200 inetOrgPerson, inetResources, and inetAssociatedResources object 201 classes. 203 cn=admins@example.com,cn=inetResources,dc=example,dc=com 204 [top object class] 205 [inetResources object class] 206 [inetOrgPerson object class] 207 [inetAssociatedResources object class] 208 | 209 +-attribute: description 210 | value: "Administrators for the example.com network." 211 | 212 +-attribute: givenName 213 | value: "Network" 214 | 215 +-attribute: sn 216 | value: "Administrators" 217 | 218 +-attribute: mail 219 | value: "admins@example.com" 220 | 221 +-attribute: inetAssociatedDnsDomain 222 | value: "example.com" 223 | value: "2.0.192.in-addr.arpa" 224 | 225 +-attribute: inetAssociatedIpv4Network 226 value: "192.0.2.0/24" 228 Figure 1: The entry for the admins@example.com contact in the 229 dc=netsol,dc=com partition. 231 5. Query Processing Rules 233 Queries for contact entries have several special requirements, as 234 discussed in the following sections. 236 Refer to [FIRS-CORE] for general information about FIRS queries. 238 5.1. Query Pre-Processing 240 Clients MUST ensure that the query input is normalized according 241 to the rules specified in section 3 before the input is used as 242 the assertion value to the resulting LDAP query. 244 The authoritative partition for a contact entry is determined by 245 mapping the domain element of a normalized email address to a 246 sequence of domainComponent labels. 248 Since the domainComponent attribute is restricted to seven-bit 249 characters, the domain element MUST be converted to its IDNA form 250 using the "ToASCII" conversion operation specified in [RFC3490], 251 with the "UseSTD3ASCIIRules" flag disabled (FIRS applications MAY 252 reuse the output from the conversion performed in step 3.c if the 253 entire conversion process is known to have completed 254 successfully). The resulting sequence of ASCII labels are used to 255 form the domainComponent sequence which represents the 256 authoritative partition for the email address. 258 As a simple example, "admins@example.com" would be mapped to the 259 "dc=example,dc=com" authoritative partition, with this partition 260 being used to seed the query process. 262 5.2. Query Bootstrapping 264 FIRS clients MUST use the bottom-up bootstrap model by default for 265 contact queries. As such, the search base for default queries 266 would be set to the complete sequence of domainComponent relative 267 distinguished names of the authoritative partition. 269 FIRS clients MAY use the targeted or top-down bootstrap models for 270 queries if necessary or desirable. However, it is not likely that 271 entries will be found for all possible contacts using these models 272 (the "dc=com" partition is not likely to have entries for all of 273 the possible contacts with mailboxes in the "com" hierarchy, for 274 example). As such, the bottom-up bootstrap model will be the most 275 useful in most cases, and MUST be used by default. 277 Note that registration bodies can allocate email addresses within 278 their own managed portion of the DNS namespace if predictability 279 is at a premium. For example, a registrar could assign 280 "user@registrar.com" email addresses to the contact entries that 281 it creates, thereby ensuring that the contact entries are always 282 locatable and managed. 284 5.3. LDAP Matching 286 FIRS clients MUST specify equalityMatch matching filters in LDAP 287 searches for contact entries. 289 In order to ensure that all of the relevant entries are found 290 (including any referrals), the search filters for these resources 291 MUST specify the inetOrgPerson object class and the cn attribute. 292 For example, "(&(objectclass=inetOrgPerson) 293 (cn=admins@example.com))" with a search base of 294 "cn=inetResources,dc=netsol,dc=com" would find all of the 295 inetOrgPerson object class entries of "cn=admins@example.com" in 296 the "dc=netsol,dc=com" partition. 298 The matching filters defined in this specification MUST be 299 supported by FIRS clients and servers. FIRS servers MAY support 300 additional sub-string filters, soundex filters, or any other 301 filters they wish (these may be required to support generic LDAP 302 clients), although FIRS clients MUST NOT expect any additional 303 filters to be available. 305 5.4. Example Query 307 The following example assumes that the user has specified 308 "admins@example.com" as the query value: 310 a. Normalize the input, which is "admins@example.com" in this 311 case. 313 b. Determine the canonical authoritative partition, which is 314 "dc=example,dc=com" in this case. By default, queries for 315 contacts use the bottom-up model, meaning that the fully- 316 qualified distinguished name of "dc=example,dc=com" will be 317 used. 319 c. Determine the search base for the query, which will be 320 "cn=inetResources,dc=example,dc=com" if the defaults are 321 used. 323 d. Initiate a DNS lookup for the SRV resource records 324 associated with "_ldap._tcp.example.com." For the purpose 325 of this example, assume that this lookup succeeds, with the 326 DNS response message indicating that "firs.example.com" is 327 the preferred LDAP server. 329 e. Submit an LDAPv3 query to the specified server, using 330 "(&(objectClass=inetOrgPerson)(cn:dn:admins@example.com))" 331 as the matching filter, "cn=inetResources,dc=example, 332 dc=com" as the search base, and the global query defaults 333 defined in [FIRS-CORE]. 335 f. Assume that no referrals are received. Display the answer 336 data which has been received and exit the query. 338 6. Security Considerations 339 Security considerations are discussed in [FIRS-ARCH]. 341 7. IANA Considerations 343 IANA considerations are discussed in [FIRS-ARCH]. 345 8. Normative References 347 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 348 Service: Architecture and Implementation 349 Guide", draft-ietf-crisp-firs-arch-01, July 350 2003. 352 [FIRS-ASN] Hall, E. "Defining and Locating Autonomous 353 System Numbers in the Federated Internet 354 Registry Service", draft-ietf-crisp-firs-asn- 355 01, July 2003. 357 [FIRS-CONTCT] Hall, E. "Defining and Locating Contact 358 Persons in the Federated Internet Registry 359 Service", draft-ietf-crisp-firs-contact-01, 360 July 2003. 362 [FIRS-CORE] Hall, E. "The Federated Internet Registry 363 Service: Core Elements", draft-ietf-crisp- 364 firs-core-01, July 2003. 366 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in 367 the Federated Internet Registry Service", 368 draft-ietf-crisp-firs-dns-01, July 2003. 370 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 371 Records in the Federated Internet Registry 372 Service", draft-ietf-crisp-firs-dnsrr-01, July 373 2003. 375 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 376 Blocks in the Federated Internet Registry 377 Service", draft-ietf-crisp-firs-ipv4-01, July 378 2003. 380 [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address 381 Blocks in the Federated Internet Registry 382 Service", draft-ietf-crisp-firs-ipv6-01, July 383 2003. 385 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 386 and Sataluri, S. "Using Domains in LDAP/X.500 387 DNs", RFC 2247, January 1998. 389 [RFC2251] Wahl, M., Howes, T., and Kille, S. 390 "Lightweight Directory Access Protocol (v3)", 391 RFC 2251, December 1997. 393 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 394 S. "Lightweight Directory Access Protocol 395 (v3): Attribute Syntax Definitions", RFC 2252, 396 December 1997. 398 [RFC2254] Howes, T. "The String Representation of LDAP 399 Search Filters", RFC 2254, December 1997. 401 [RFC2279] Yergeau, F. "UTF-8, a transformation format of 402 ISO 10646", RFC 2279, January 1998. 404 [RFC2596] Wahl, M., and Howes, T. "Use of Language Codes 405 in LDAP", RFC 2596, May 1999. 407 [RFC2798] Smith, M. "Definition of the inetOrgPerson 408 LDAP Object Class", RFC 2798, April 2000. 410 [RFC3490] Faltstrom, P., Hoffman, P., and Costello, A. 411 "Internationalizing Domain Names in 412 Applications (IDNA)", RFC 3490, March 2003. 414 [US-ASCII] Cerf, V. "ASCII format for Network 415 Interchange", RFC 20, October 1969. 417 9. Changes from Previous Versions 419 draft-ietf-crisp-firs-contact-01: 421 * Several clarifications and corrections have been made. 423 * Several attributes had their OIDs changed. NOTE THAT THIS 424 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 425 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 427 draft-ietf-crisp-firs-contact-00: 429 * Restructured the document set. 431 * "Attribute references" have been eliminated from the 432 specification. All referential attributes now provide 433 actual data instead of URL pointers to data. Clients that 434 wish to retrieve these values will need to start new 435 queries using the data values instead of URLs. 437 draft-ietf-crisp-lw-user-01: 439 * Removed references to LDAPS (LDAP-over-SSL), which is not a 440 standards-track protocol. 442 * Added a discussion on localization considerations. 444 * Moved attribute-specific security requirements to the 445 Security section. 447 10. Author's Addresses 449 Eric A. Hall 450 ehall@ehsco.com 452 11. Acknowledgments 454 Funding for the RFC editor function is currently provided by the 455 Internet Society. 457 Portions of this document were funded by VeriSign Labs. 459 The first version of this specification was co-authored by Andrew 460 Newton of Verisign Labs, and subsequent versions continue to be 461 developed with his active participation. 463 12. Full Copyright Statement 465 Copyright (C) The Internet Society (2003). All Rights Reserved. 467 This document and translations of it may be copied and furnished 468 to others, and derivative works that comment on or otherwise 469 explain it or assist in its implementation may be prepared, 470 copied, published and distributed, in whole or in part, without 471 restriction of any kind, provided that the above copyright notice 472 and this paragraph are included on all such copies and derivative 473 works. However, this document itself may not be modified in any 474 way, such as by removing the copyright notice or references to the 475 Internet Society or other Internet organizations, except as needed 476 for the purpose of developing Internet standards in which case the 477 procedures for copyrights defined in the Internet Standards 478 process must be followed, or as required to translate it into 479 languages other than English. 481 The limited permissions granted above are perpetual and will not 482 be revoked by the Internet Society or its successors or assigns. 484 This document and the information contained herein is provided on 485 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 486 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 487 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 488 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 489 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.