idnits 2.17.1 draft-ietf-crisp-firs-contact-03.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 (August 2003) is 7558 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: 'RFC2247' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'RFC2251' is defined on line 401, but no explicit reference was found in the text == Unused Reference: 'RFC2252' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'RFC2254' is defined on line 410, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'FIRS-ARCH' -- Possible downref: Normative reference to a draft: ref. 'FIRS-ASN' -- Possible downref: Normative reference to a draft: ref. 'FIRS-CORE' -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNS' -- Unexpected draft version: The latest known version of draft-ietf-crisp-firs-dnsrr is -02, but you're referring to -03. -- Possible downref: Normative reference to a draft: ref. 'FIRS-DNSRR' -- Possible downref: Normative reference to a draft: ref. 'FIRS-IPV4' -- 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 (~~), 6 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-03.txt August 2003 4 Expires: March, 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.....................................6 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.0 136 NAME 'inetContactSyntax' 137 DESC 'A fully-qualified email address.' ) 139 Note that the use of the "at" separator character is illegal as 140 data in URLs, and these characters will be escaped before they are 141 stored in a URL as data. 143 Also note that UTF-8 characters use character codes which are 144 frequently illegal as data in URLs, and many of those octet values 145 will probably be escaped before they are stored in a URL as data. 147 4. Object Classes and Attributes 149 Contact entries in FIRS MUST use the inetOrgPerson object class as 150 defined in RFC 2798 [RFC2798], in addition to the mandatory object 151 classes defined in [FIRS-CORE]. Contact entries MUST be treated as 152 containers capable of holding subordinate entries. 154 If an entry exists as a referral source, the entry MUST be defined 155 with the referral object class, in addition to the other object 156 classes defined above. Referral sources MUST NOT contain 157 subordinate entries. Refer to section 3.5 of [FIRS-CORE] for more 158 information on referral entries in FIRS. 160 The inetOrgPerson object class is a structural object class. The 161 inetOrgPerson object class has three mandatory attributes (cn, sn, 162 and objectClass), and has several optional attributes. Contact 163 entries also inherit the attributes defined in the inetResources 164 object class when they are used with FIRS. 166 Refer to [RFC2798] for the inetOrgPerson schema definitions. 168 Note that the "mail" attribute defined for use with the 169 inetOrgPerson object class is restricted to seven-bit character 170 codes and is typically interpreted as [US-ASCII], and is therefore 171 not compatible with the inetContactSyntax rules defined in section 172 3. As such, if the mail domain uses an internationalized domain 173 name, the domain element of the mail attribute MUST be reduced to 174 its ASCII-compatible form using the ToASCII process defined in 175 [RFC3490], and MUST NOT use the UTF-8 encoding. 177 Note that International postal regulations generally require that 178 the recipient address on an envelope be provided in a language and 179 charset which is native to the recipient's country, with the 180 exception of the destination country name which should be provided 181 in a language and charset that is native to the sender's country. 182 This model ensures that the sender's post office will be able to 183 route the mail to the recipient's country, while also ensuring 184 that the destination country's post office will be able to perform 185 local delivery. In order to facilitate this usage, the country 186 attribute value MAY (encouraged) be localized to the local user's 187 nomenclature for a country, but other postal address information 188 SHOULD NOT be localized. 190 Notwithstanding the above, it is ENCOURAGED that contact names be 191 provided in English forms in order to facilitate inter-party 192 communications, using the mechanisms offered by [RFC2596]. For 193 example, the default contact entry for a person in Japan SHOULD be 194 provided in the native form for that person, but an English form 195 is also ENCOURAGED in order to allow non-Japanese users to 196 properly address that person in subsequent communications. As 197 stated in the preceding paragraph however, any postal 198 communications for that person SHOULD use the native-language 199 representation (at least on the envelope) in order to facilitate 200 the delivery of postal mail. 202 An example of the inetOrgPerson object class in use is shown in 203 Figure 1 below. The example includes attributes from the 204 inetOrgPerson, inetResources, and inetAssociatedResources object 205 classes. 207 cn=admins@example.com,cn=inetResources,dc=example,dc=com 208 [top object class] 209 [inetResources object class] 210 [inetOrgPerson object class] 211 [inetAssociatedResources object class] 212 | 213 +-attribute: mail 214 | value: "admins@example.com" 215 | 216 +-attribute: inetAssociatedIpv4Network 217 value: "192.0.2.0/24" 219 Figure 1: The entry for the admins@example.com contact in the 220 dc=netsol,dc=com partition. 222 5. Query Processing Rules 224 Queries for contact entries have several special requirements, as 225 discussed in the following sections. 227 Refer to [FIRS-CORE] for general information about FIRS queries. 229 5.1. Query Pre-Processing 231 Clients MUST ensure that the query input is normalized according 232 to the rules specified in section 3 before the input is used as 233 the assertion value to the resulting LDAP query. 235 The authoritative partition for a contact entry is determined by 236 mapping the domain element of a normalized email address to a 237 sequence of domainComponent labels. 239 Since the domainComponent attribute is restricted to seven-bit 240 characters, the domain element MUST be converted to its IDNA form 241 using the "ToASCII" conversion operation specified in [RFC3490], 242 with the "UseSTD3ASCIIRules" flag disabled (FIRS applications MAY 243 reuse the output from the conversion performed in step 3.c if the 244 entire conversion process is known to have completed 245 successfully). The resulting sequence of ASCII labels are used to 246 form the domainComponent sequence which represents the 247 authoritative partition for the email address. 249 As a simple example, "admins@example.com" would be mapped to the 250 "dc=example,dc=com" authoritative partition, with this partition 251 being used to seed the query process. 253 5.2. Query Bootstrapping 255 FIRS clients MUST use the bottom-up bootstrap model by default for 256 contact queries. As such, the search base for default queries 257 would be set to the complete sequence of domainComponent relative 258 distinguished names of the authoritative partition. 260 FIRS clients MAY use the targeted or top-down bootstrap models for 261 queries if necessary or desirable. However, it is not likely that 262 entries will be found for all possible contacts using these models 263 (the "dc=com" partition is not likely to have entries for all of 264 the possible contacts with mailboxes in the "com" hierarchy, for 265 example). As such, the bottom-up bootstrap model will be the most 266 useful in most cases, and MUST be used by default. 268 Note that registration bodies can allocate email addresses within 269 their own managed portion of the DNS namespace if predictability 270 is at a premium. For example, a registrar could assign 271 "user@registrar.com" email addresses to the contact entries that 272 it creates, thereby ensuring that the contact entries are always 273 locatable and managed. 275 5.3. LDAP Matching 277 If the server advertises the inetOrgPerson object class and the 278 inetContactMatch matching filter in the inetResourcesControl 279 server control, FIRS clients MUST use the inetDnsDomainMatch 280 matching filter in LDAP searches for contact entries. 282 The inetContactMatch filter provides an identifier and search 283 string format which collectively inform a queried server that a 284 specific contact identifier should be searched for, and that any 285 inetOrgPerson object class entries which match the assertion value 286 should be returned. 288 The inetContactMatch filter is defined as follows: 290 inetContactMatch 291 ( 1.3.6.1.4.1.7161.1.4.0.1 292 NAME 'inetDnsDomainMatch' 293 SYNTAX 1.3.6.1.4.1.7161.1.4.0 ) 295 Clients MUST ensure that the query input is normalized according 296 to the rules specified in section 3 before the input is used as 297 the assertion value to the resulting LDAP query. 299 A FIRS server MUST compare the assertion value against the 300 distinguished name of all entries within and beneath the container 301 specified by the search base of the query. Any entry in that 302 hierarchy with an object class of inetOrgPerson and a 303 distinguished name component that is equal to the assertion value 304 MUST be returned to the client (this specifically includes any 305 child entries, such as referral stubs). Entries which do not have 306 an object class of inetOrgPerson MUST NOT be returned. 308 The matching filters defined in this specification MUST be 309 supported by FIRS clients and servers. FIRS servers MAY support 310 additional matching filters, although FIRS clients MUST NOT expect 311 any additional filters to be available. 313 If the server does not advertise support for the inetContactMatch 314 matching filter in the inetResourcesControl server control, the 315 client MAY choose to emulate the matching filter through the use 316 of locally-constructed equalityMatch filters. However, this 317 process can result in incomplete answers in some cases, so if the 318 server advertises support for the inetContactMatch matching filter 319 in the inetResourcesControl control, the client MUST use it. 321 5.4. Example Query 323 The following example assumes that the user has specified 324 "admins@example.com" as the query value: 326 a. Normalize the input, which is "admins@example.com" in this 327 case. 329 b. Determine the canonical authoritative partition, which is 330 "dc=example,dc=com" in this case. By default, queries for 331 contacts use the bottom-up model, meaning that the fully- 332 qualified distinguished name of "dc=example,dc=com" will be 333 used. 335 c. Determine the search base for the query, which will be 336 "cn=inetResources,dc=example,dc=com" if the defaults are 337 used. 339 d. Initiate a DNS lookup for the SRV resource records 340 associated with "_ldap._tcp.example.com." For the purpose 341 of this example, assume that this lookup succeeds, with the 342 DNS response message indicating that "firs.example.com" is 343 the preferred LDAP server. 345 e. Submit an LDAPv3 query to the specified server, using 346 "(1.3.6.1.4.1.7161.1.4.0.1:=admins@example.com)" as the 347 matching filter, "cn=inetResources,dc=example, dc=com" as 348 the search base, and the global query defaults defined in 349 [FIRS-CORE]. 351 f. Assume that no referrals are received. Display the answer 352 data which has been received and exit the query. 354 6. Security Considerations 356 Security considerations are discussed in [FIRS-ARCH]. 358 7. IANA Considerations 360 IANA considerations are discussed in [FIRS-ARCH]. 362 8. Normative References 364 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 365 Service: Architecture and Implementation 366 Guide", draft-ietf-crisp-firs-arch-03, August 367 2003. 369 [FIRS-ASN] Hall, E. "Defining and Locating Autonomous 370 System Numbers in the Federated Internet 371 Registry Service", draft-ietf-crisp-firs-asn- 372 03, August 2003. 374 [FIRS-CORE] Hall, E. "The Federated Internet Registry 375 Service: Core Elements", draft-ietf-crisp- 376 firs-core-03, August 2003. 378 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in 379 the Federated Internet Registry Service", 380 draft-ietf-crisp-firs-dns-03, August 2003. 382 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 383 Records in the Federated Internet Registry 384 Service", draft-ietf-crisp-firs-dnsrr-03, July 385 2003. 387 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 388 Blocks in the Federated Internet Registry 389 Service", draft-ietf-crisp-firs-ipv4-03, 390 August 2003. 392 [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address 393 Blocks in the Federated Internet Registry 394 Service", draft-ietf-crisp-firs-ipv6-03, 395 August 2003. 397 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 398 and Sataluri, S. "Using Domains in LDAP/X.500 399 DNs", RFC 2247, January 1998. 401 [RFC2251] Wahl, M., Howes, T., and Kille, S. 402 "Lightweight Directory Access Protocol (v3)", 403 RFC 2251, December 1997. 405 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 406 S. "Lightweight Directory Access Protocol 407 (v3): Attribute Syntax Definitions", RFC 2252, 408 December 1997. 410 [RFC2254] Howes, T. "The String Representation of LDAP 411 Search Filters", RFC 2254, December 1997. 413 [RFC2279] Yergeau, F. "UTF-8, a transformation format of 414 ISO 10646", RFC 2279, January 1998. 416 [RFC2596] Wahl, M., and Howes, T. "Use of Language Codes 417 in LDAP", RFC 2596, May 1999. 419 [RFC2798] Smith, M. "Definition of the inetOrgPerson 420 LDAP Object Class", RFC 2798, April 2000. 422 [RFC3490] Faltstrom, P., Hoffman, P., and Costello, A. 423 "Internationalizing Domain Names in 424 Applications (IDNA)", RFC 3490, March 2003. 426 [US-ASCII] Cerf, V. "ASCII format for Network 427 Interchange", RFC 20, October 1969. 429 9. Changes from Previous Versions 431 draft-ietf-crisp-firs-contact-03: 433 * Several clarifications and corrections have been made. 435 * The inetContactMatch matching filter was defined. The use 436 of equalityMatch and extensibleMatch has been deprecated. 438 draft-ietf-crisp-firs-contact-02: 440 * Several clarifications and corrections have been made. 442 draft-ietf-crisp-firs-contact-01: 444 * Several clarifications and corrections have been made. 446 * Several attributes had their OIDs changed. NOTE THAT THIS 447 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 448 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 450 draft-ietf-crisp-firs-contact-00: 452 * Restructured the document set. 454 * "Attribute references" have been eliminated from the 455 specification. All referential attributes now provide 456 actual data instead of URL pointers to data. Clients that 457 wish to retrieve these values will need to start new 458 queries using the data values instead of URLs. 460 draft-ietf-crisp-lw-user-01: 462 * Removed references to LDAPS (LDAP-over-SSL), which is not a 463 standards-track protocol. 465 * Added a discussion on localization considerations. 467 * Moved attribute-specific security requirements to the 468 Security section. 470 10. Author's Addresses 472 Eric A. Hall 473 ehall@ehsco.com 475 11. Acknowledgments 477 Funding for the RFC editor function is currently provided by the 478 Internet Society. 480 Portions of this document were funded by VeriSign Labs. 482 The first version of this specification was co-authored by Andrew 483 Newton of Verisign Labs, and subsequent versions continue to be 484 developed with his active participation. 486 12. Full Copyright Statement 488 Copyright (C) The Internet Society (2003). All Rights Reserved. 490 This document and translations of it may be copied and furnished 491 to others, and derivative works that comment on or otherwise 492 explain it or assist in its implementation may be prepared, 493 copied, published and distributed, in whole or in part, without 494 restriction of any kind, provided that the above copyright notice 495 and this paragraph are included on all such copies and derivative 496 works. However, this document itself may not be modified in any 497 way, such as by removing the copyright notice or references to the 498 Internet Society or other Internet organizations, except as needed 499 for the purpose of developing Internet standards in which case the 500 procedures for copyrights defined in the Internet Standards 501 process must be followed, or as required to translate it into 502 languages other than English. 504 The limited permissions granted above are perpetual and will not 505 be revoked by the Internet Society or its successors or assigns. 507 This document and the information contained herein is provided on 508 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 509 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 510 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 511 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 512 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.