idnits 2.17.1 draft-ietf-lsd-ldapv3-wp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 75: '... other documents MAY be included in wh...' RFC 2119 keyword, line 117: '...attribute labels MAY be defined in oth...' RFC 2119 keyword, line 123: '...rintablestring ; SHOULD be based on E....' RFC 2119 keyword, line 259: '... Language tags as specified in [LANGTAGS] MAY be used for the...' RFC 2119 keyword, line 261: '... Language tags MAY also be used with...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 352 has weird spacing: '...e Phone tele...' == Line 353 has weird spacing: '... Number tele...' == Line 361 has weird spacing: '...Address post...' -- 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 (28 January 1998) is 9584 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC2045' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 466, but no explicit reference was found in the text == Unused Reference: 'RFC2047' is defined on line 469, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IOPERSON' -- Possible downref: Non-RFC (?) normative reference: ref. 'LANGTAGS' -- Possible downref: Non-RFC (?) normative reference: ref. 'LDIF' -- Possible downref: Non-RFC (?) normative reference: ref. 'LIPS' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) -- Duplicate reference: RFC2047, mentioned in 'RFC2047', was also mentioned in 'MIME'. ** 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 2256 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) -- Possible downref: Non-RFC (?) normative reference: ref. 'VPIM' -- Possible downref: Non-RFC (?) normative reference: ref. 'X500' Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT C. Apple 2 AT&T Labs 3 Expires: July 28, 1998 T. Howes 4 Netscape Communications Corp. 5 C. Weider 6 Microsoft Corp. 7 M. Wahl 8 Critical-Angle Inc. 9 28 January 1998 11 A Minimum LDAPv3 White Pages Schema 12 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 docu- ments of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 28 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Abstract 34 Many different white pages schema proposals have been published for 35 use in LDAPv3 as well as other directory service protocols. While 36 these proposals define schema elements that are indeed useful in the 37 deployment of LDAPv3-based directory services, there are a few 38 problems common to the set of such proposals currently available to 39 implementors: inconsistent semantic and syntactic definitions of 40 similar attributes across schema, little or no semantic extensibility 41 of attribute definitions without changing source code for deployed 42 implementations, lack of standard object class definitions for 43 containing white pages meta schema elements, and lack of an attribute 44 grouping method. This document defines an object class for holding 45 IWPS attributes as mapped into existing and relatively few newly 46 defined extensible attribute types. 48 1.0 Introduction 50 The X.500 standards [X500] define many basic object classes, 51 attribute types, syntaxes, and matching rules that are useful in the 52 context of white pages directory services and applications. More 53 recently, there have been a number of efforts ([LIPS], [RFC2218], 54 [RFC2256], and [RFC2252]) to define object classes, attribute types, 55 syntaxes, matching rules, and meta schema for use in building white 56 pages applications. While this plethora of schema served as catalyst 57 to early growth in a market acceptance of LDAP as a white pages 58 technology of choice, it has become a barrier to true LDAP 59 interoperability from the perspective of Intranet and Internet white 60 pages directory service implementors and users. 62 This document makes use of existing white pages schema and meta 63 schema elements and minimizes the creation of new elements to specify 64 the minimum white pages schema for LDAPv3 interoperation. 66 2.0 Background and Intended Usage 68 The wpPerson object class is a general purpose object class that 69 holds attributes about people. The attributes it holds were chosen to 70 accommodate information requirements found in Internet and Intranet 71 directory service deployments. The wpPerson object class is designed 72 to be used within directory services based on the LDAP [RFC2251] and 73 the X.500 family of protocols, and it may be useful in other contexts 74 as well. Other attributes and auxiliary object classes defined in 75 other documents MAY be included in white pages entries 77 The attribute type and object class definitions are written using the 78 BNF form of AttributeTypeDescription and ObjectClassDescription given 79 in [RFC2252]. Lines have been folded for readability. 81 Attributes that are referenced but not defined in this document are 82 included in the standard and pilot attribute definitions [RFC2256], 83 in the labeledURI object class [RFC2079], or in the inetOrgPerson 84 object class [IOPERSON]. 86 BNF productions that are used, but not defined in this document are 87 equivalent to those with the same name defined in [RFC822]. 89 3.0 New Attribute Types Used in the wpPerson Object Class 91 3.1 objectGuid Attribute 93 ( 1.2.840.113556.1.4.2 NAME 'objectGuid' 94 EQUALITY octetStringMatch 95 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 96 SINGLE-VALUE USAGE directoryOperation ) 98 3.2 mimeContent 100 The mimeContent attribute contains one or more values whose encodings 101 are MIME contents [MIME]. Examples of MIME contents include images 102 and sounds. 104 ( OID-TBD NAME 'mimeContent' EQUALITY octetStringMatch 105 SYNTAX OID-TBD ) 107 Labels for the mimeContent attribute can be provided using the 108 Content Transfer Disposition mechanism defined in [MIME]. 110 4.0 New Syntactic Grammars 112 The following paragraphs define extensible syntactic grammars for 113 specific attributes used in implementing white pages directory 114 services. The mechanism used to enable extensibility is referred to 115 as labelling. Contextual semantic labels, which may be used alone or 116 in combination, are defined for each such attribute. Other such 117 attribute labels MAY be defined in other documents. 119 4.1 telephoneNumber Attribute 121 labeled-number = telephonenumber [ "(" parameters ")" ] 123 telephonenumber = printablestring ; SHOULD be based on E.163 125 parameters = ( whsp parm whsp ) / ( parm "$" parameters ) 127 parm = numericoid / telephone-label 129 telephone-label = "home" ; a residential telephone number 130 / "work" ; a business telephone number 131 / "fax" ; a facsimile telephone number 132 / "modem" ; a telephone number answered by a MODEM 133 / "voice" ; a voice telephone number 134 / "msg" ; a telephone number with voice mail 135 / "pref" ; a preferred telephone number 136 / "pager" ; a pager telephone number 137 / "cell" ; an analog cellular telephone number 138 / "car" ; a car cellular telephone number 139 / "isdn" ; an international ISDN telephone number 140 / "pcs" ; a digital PCS telephone number 141 / "temp" ; a temporary telephone number 143 4.2 mail Attribute 145 labeled-mail = mail [ "(" parameters ")" ] 147 mail = 149 parameters = ( whsp parm whsp ) / ( parm "$" parameters ) 151 parm = vendor-specific / mail-label 153 vendor-specific = numericoid 155 mail-label = "personal" ; a personal email address 156 / "work" ; a business email address 157 / "pref" ; a preferred email address 158 / "temp" ; a temporary email address 159 / "vpim" ; an RFC822 address for a [VPIM] mailbox 160 / "internet" ; a general purpose RFC822 address 162 4.3 postalAddress Attribute 164 labeled-postal = postalAddress [ "$" "(" parameters ")" ] 166 postalAddress = 168 parameters = ( whsp parm whsp ) / ( parm "$" parameters ) 170 parm = numericoid / postal-label 172 postal-label = "home" ; a residential postal address 173 / "work" ; a business postal address 174 / "pref" ; a preferred postal address 175 / "temp" ; a temporary postal address 177 4.4 organization Attribute 179 labeled-organization = organization [ "$" "(" parameters ")" ] 181 organization = 184 parameters = ( whsp parm whsp ) / ( parm "$" parameters ) 186 parm = numericoid / org-label 188 org-label = "home" ; a personal organization name 189 / "work" ; a business or professional organization name 190 / "temp" ; a temporary organization name 192 4.5 locality Attribute 194 labeled-locality = locality [ "$" "(" parameters ")" ] 196 locality = 199 parameters = ( whsp parm whsp ) / ( parm "$" parameters ) 201 parm = numericoid / locality-label 203 locality-label = "home" ; a locality associated with a person's 204 residence 205 / "work" ; a locality associatd with a business 206 location 207 / "temp" ; a locality associated with a temporary 208 location 210 4.6 title Attribute 212 labeled-title = title [ CRLF "(" parameters ")" ] 214 title = 216 parameters = ( whsp parm whsp ) / ( parm "$" parameters ) 218 parm = numericoid / title-label 220 title-label = "personal" ; a personal title 221 / "work" ; a business title 222 / "pref" ; a preferred title 224 4.7 description Attribute 226 labeled-descr = description [ CRLF "(" parameters ")" ] 228 description = 231 parameters = ( whsp parm whsp ) / ( parm "$" parameters ) 233 parm = numericoid / descr-label 235 descr-label = "home" ; a personal description 236 / "work" ; a business description 237 / "pref" ; a preferred description 239 4.8 MIME Content Syntax 240 (This is a new syntax) 242 The MIME Content syntax has the following definition: 244 ( TBD NAME 'MIME Content' ) 246 The contents of a value of an attribute with this syntax is a MIME 247 content encoded according to [MIME]. Content Transfer Encodings may 248 be used, however transfer of LDAP values can be assumed to be 8 bit 249 clean. 251 An example value in this syntax is provided below. Lines are wrapped 252 for readability. "\r\n" is used to indicate a CRLF pair. 254 Content-Type: text/plain\r\nContent-Transfer-Encoding: 8bit\r\n\r\n 255 Hello world\r\n 257 5.0 Language Tags 259 Language tags as specified in [LANGTAGS] MAY be used for the 260 following wpPerson attributes: title, description, and postalAddress. 261 Language tags MAY also be used with other attributes. 263 6.0 Operational Attributes 265 The LDAPv3 operational attributes createTimestamp, creatorsName, 266 modifyTimestamp, and modifiersName SHOULD be used. These attributes 267 corresponding to the ancillary attributes defined in [RFC2218]. 269 7.0 Naming Attributes 271 Naming of wpPerson entries is a subject for other documents. 273 8.0 Definition of the wpPerson Object Class 275 The wpPerson object class represents people who are associated with 276 an organization, ISP, or on-line service connected to the Internet. 277 It is a structural class and is derived from the Person object class. 279 This object class definition includes the LDAP attribute types 280 required to form attributes defined in [RFC2218] and [LIPS] when used 281 in combination with the attribute labelling techniques defined above. 282 Specific attribute types that express in the attribute type name the 283 same information as that expressible using the attribute labels 284 defined above are not included in this objectclass definition; all 285 attributes fitting this description are included as allowable 286 attribute types in an auxiliary compatibility object class defined in 287 section 9.0. 289 See paragraph 8.1 for the mapping of IWPS attributes to wpPerson 290 LDAPv3 attribute types. 292 ( OID-TBP 293 NAME 'wpPerson' 294 SUP person 295 STRUCTURAL 296 MUST ( 297 objectGuid 298 ) 299 MAY ( 300 # 301 # the attribute values of the following types 302 # SHOULD be labelled using the conventions 303 # defined in section 4.0 304 # 305 mail $ 306 telephoneNumber $ 307 postalAddress $ 308 o $ 309 l $ 310 c $ 311 title $ 312 description $ 313 # 314 # the attribute values of the following types 315 # MUST NOT be labelled using the conventions 316 # in section 4.0 317 # 318 secretary $ 319 manager $ 320 ou $ 321 userCertificate $ 322 givenName $ 323 generationQualifier $ 324 initials $ 325 middleName $ 326 preferredLanguage $ 327 mimeContent $ 328 # 329 # the following attribute should be labelled 330 # according to the convention specified in [RFC2079] 331 # 332 labeledURI 333 ) 334 ) 336 8.1 IWPS to LDAPv3 wpPerson Object Class Mapping 338 IWPS Field Name wpPerson Attribute label(s) 340 Email mail see 4.1 341 Cert userCertificate N/A 342 Home Page labeledURI home AND/OR work 343 Common Name cn N/A 344 Given Name givenName N/A 345 Surname sn N/A 346 Organization o home OR work 347 Locality l home AND/OR work 348 Country c N/A 349 Language Spoken preferredLanguage N/A 350 Personal Phone telephoneNumber home AND voice 351 Personal Fax telephoneNumber home AND fax 352 Personal Mobile Phone telephoneNumber home AND mobile 353 Personal Pager Number telephoneNumber home AND pager 354 Personal Postal Address postalAddress home 355 Description description home OR work 356 Title title home OR work 357 Office Phone telephoneNumber work AND voice 358 Office Fax telephoneNumber work AND fax 359 Office Mobile Phone telephoneNumber work AND mobile 360 Office Pager telephoneNumber work AND pager 361 Office Postal Address postalAddress work 362 Creation Date createTimestamp N/A 363 Creator Name creatorsName N/A 364 Modified Date modifyTimestamp N/A 365 Modifier Name modifiersName N/A 367 8.2 LIPS to LDAPv3 wpPerson Object Class 369 TBP. 371 9.0 wpCompatible Object Class 373 The wpCompatible object class has beed defined to provide backward 374 compatibility with deployed LDAPv3 implementations that support 375 either [LIPS] or [RFC2218]. 377 ( OID-TBP 378 NAME 'wpCompatible' 379 AUXILIARY 380 MAY ( 381 personalTitle $ 382 homePhone $ 383 homeFax $ 384 homePostalAddress $ 385 facsimileTelephoneNumber $ 386 mobile $ 387 pager $ 388 MHSORAddress $ 389 roomNumber $ 390 telexNumber $ 391 thumbnailPhoto $ 392 thumbnailLogo $ 393 uid 394 ) 395 ) 397 10.0 Example of a wpPerson Entry 399 The following example is expressed using the LDIF notation defined in 400 [LDIF]. 402 dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US 403 objectClass: top 404 objectClass: person 405 objectClass: wpPerson 406 cn: Barbara Jensen 407 cn: Babs Jensen 408 sn: Jensen 409 givenName: Barbara 410 title;lang-en: manager, product development 411 mail: bjensen@aceindustry.com (work $ pref) 412 mail: bjensen@bjj.isp.net (home) 413 telephoneNumber: +1 408 555 1862 (voice $ msg $ work $ pref) 414 telephoneNumber: +1 408 555 1992 (fax $ work) 415 telephoneNumber: +1 408 555 1941 (mobile) 416 preferredLanguage: fr 417 preferredLanguage: en-gb 418 preferredLanguage: en 419 labeledURI: http://www.aceindustry.com/users/bjensen work 421 11.0 Security Considerations 423 Attributes of directory entries are used to provide descriptive 424 informa- tion about the real-world objects they represent, which can 425 be people, organizations or devices. Most countries have privacy 426 laws regarding the publication of information about people. 428 Transfer of cleartext passwords (e.g., a clear-text userPassword 429 value) are strongly discouraged where the underlying transport 430 service cannot guarantee confidentiality and may result in disclosure 431 of the password to unauthorized parties. 433 12.0 Acknowledgments 435 The engineering team for the schema specified in this document: 437 Chris Apple - AT&T Labs 438 Tim Howes - Netscape Communications Corp. 439 Mark Wahl - Critical Angle Inc. 440 Chris Weider - Microsoft Corp. 442 13.0 References 444 [IOPERSON] M. Smith, "Definition of the inetOrgPerson Object Class", 445 INTERNET-DRAFT , July 1997. 447 [LANGTAGS] M. Wahl, T. Howes, "Use of Language Codes in LDAP", 448 INTERNET-DRAFT , January 1998. 450 [LDIF] G. Good, "The LDAP Data Interchange Format (LDIF) - Technical 451 Specification" "The LDAP Data Interchange Format (LDIF)", INTERNET- 452 DRAFT , 30 July 1997. 454 [LIPS] Network Applications Consortium, "The Lightweight Internet 455 Person Schema", , May 1997. 457 [MIME] [RFC2045] [RFC2046] [RFC2047]. 459 [RFC822] D. Crocker, "Standard for the format of ARPA Interent text 460 messages", RFC 822, STD 10, August 1982. 462 [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail 463 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 464 2045, November 1996. 466 [RFC2046] N. Freed & N. Borenstein, "Multipurpose Internet Mail 467 Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. 469 [RFC2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions) 470 Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 471 November 1996. 473 [RFC2079] M. Smith, "Definition of an X.500 Attribute Type and an 474 Object Class to Hold Uniform Resource Identifiers (URIs)", RFC 2079, 475 January 1997. 477 [RFC2218] T. Genovese, B. Jennings, "A Common Schema for the Internet 478 White Pages Service", RFC 2218, October 1997. 480 [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 481 Protocol (v3)", RFC 2251, December 1997. 483 [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight 484 Directory Access Protocol (v3) Attribute Syntax Definitions", RFC 485 2252, December 1997. 487 [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use 488 with LDAPv3", RFC 2256, December 1997. 490 [VPIM] A. Brown, "VPIM Directory Schema Definition & Profile", 491 INTERNET-DRAFT , November 1997. 493 [X500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models 494 and Service", 1993. 496 14.0 Authors' Address 498 Chris Apple 499 AT&T Labs 500 600 Mountain Ave. 501 Murray Hill, NJ 07974-0636 502 USA 504 Voice: +1 908 582 2409 505 Email: capple@att.com 507 Tim Howes 508 Netscape Communications Corp. 509 501 East Middlefield Road 510 Mountain View, CA 94043 511 USA 513 Voice: +1 415 937 2600 514 Email: howes@netscape.com 515 Mark Wahl 516 Critical Angle Inc. 517 4815 W. Braker Lane #502-385 518 Austin, TX 79759 519 USA 521 Voice: +1 512 372 3160 522 Email: M.Wahl@critical-angle.com 524 Chris Weider 525 Microsoft Corp. 526 1 Microsoft Way 527 Redmond, WA 98052 528 USA 530 Voice: +1 425 703 2947 531 Email: cweider@microsoft.com 533 15.0 Appendix A - Open Issues 535 15.1 jpegPhoto, photo, and audio syntaxes are too limiting 537 We have defined a new attribute type named mimeContent that supports 538 extensible syntaxes based on MIME content-types. 540 We need to add examples to this document demonstrating how this 541 syntax can be used to construct attributes that would normally have 542 as a value image or audio data encoded according to a non-extensible 543 image or audio syntax. 545 15.2 Specifiy Meta Syntax for Labelled Attributes? 547 15.3 New Matching Rules for Labelled Attributes? 549 15.4 Use of Surname Attribute 551 The Person object class defined by X.520 requires that the surname 552 attributes be present in all entries from the person object class. 553 In some cultures, there may not be a clear distinction between name 554 components. Future versions of this document may define how to 555 represent names which do not have a surname. 557 This Internet-Draft expires on July 28, 1998.