idnits 2.17.1 draft-ietf-ldapbis-user-schema-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 1249. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1260. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1267. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 5) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 29 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([ROADMAP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 106 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2247, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2247, updated by this document, for RFC5378 checks: 1996-08-01) -- 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 2004) is 7224 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) -- Looks like a reference, but probably isn't: '2798' on line 202 == Missing Reference: 'AuthMeth' is mentioned on line 1121, but not defined == Unused Reference: 'RFC2234' is defined on line 1167, but no explicit reference was found in the text == Unused Reference: 'AUTHMETH' is defined on line 1194, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166' -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Models' ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ROADMAP' -- No information found for draft-ietf-ldapbis-syntaxes-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Syntaxes' -- No information found for draft-ietf-ldapbis-authmeth-xx - is the name correct? -- No information found for draft-klasen-ldap-x509certificate-schema-xx - is the name correct? -- No information found for draft-ietf-pkix-ldap-crl-schema-xx - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 1274 (Obsoleted by RFC 4524) -- Obsolete informational reference (is this intentional?): RFC 3377 (Obsoleted by RFC 4510) -- No information found for draft-ietf-sasl-saslprep-xx - is the name correct? Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT K. Dally, Editor 2 Intended Category: Standard Track The MITRE Corp. 3 Expires: January 2005 July 2004 4 Updates: RFC 2247, RFC 2798 5 Obsoletes: RFC 2256 7 LDAP: Schema for User Applications 8 10 Status of this Memo 12 This document is intended to be, after appropriate review and 13 revision, submitted to the RFC Editor as a Standard Track document. 14 Distribution of this memo is unlimited. Technical discussion of 15 this document will take place on the IETF LDAP Revision Working 16 Group (LDAPbis) mailing list . Please 17 send editorial comments directly to the author . 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.html. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 36 Copyright 2004, The Internet Society. All Rights Reserved. 38 Abstract 40 This document is a integral part of the Lightweight Directory Access 41 Protocol (LDAP) technical specification [ROADMAP]. It provides a 42 technical specification of attribute types and object classes 43 intended for use by LDAP directory clients for many directory 44 services, such as, White Pages. These objects are widely used as a 45 basis for the schema in many LDAP directories. This document does 46 not cover attributes used for the administration of directory 47 servers, nor does it include directory objects defined for specific 48 uses in other documents. 50 Table of Contents 52 Status of this Memo 1 54 Copyright Notice 1 56 Abstract 1 58 Table of Contents 2 60 1. Introduction 4 61 1.1 Situation 4 62 1.2 Conventions 4 63 1.3 General Issues 4 64 1.4 Source 5 66 2. Attribute Types 5 67 2.1 businessCategory 5 68 2.2 c 6 69 2.3 cn 6 70 2.4 dc 6 71 2.5 description 7 72 2.6 destinationIndicator 7 73 2.7 distinguishedName 7 74 2.8 dnQualifier 8 75 2.9 enhancedSearchGuide 8 76 2.10 facsimileTelephoneNumber 8 77 2.11 generationQualifier 8 78 2.12 givenName 9 79 2.13 houseIdentifier 9 80 2.14 initials 9 81 2.15 internationalISDNNumber 9 82 2.16 l 10 83 2.17 member 10 84 2.18 name 10 85 2.19 o 10 86 2.20 ou 11 87 2.21 owner 11 88 2.22 physicalDeliveryOfficeName 11 89 2.23 postalAddress 11 90 2.24 postalCode 12 91 2.25 postOfficeBox 12 92 2.26 preferredDeliveryMethod 12 93 2.27 registeredAddress 13 94 2.28 roleOccupant 13 95 2.29 searchGuide 13 96 2.30 seeAlso 13 97 2.31 serialNumber 14 98 2.32 sn 14 99 2.33 st 14 100 2.34 street 14 101 2.35 telephoneNumber 15 102 2.36 teletexTerminalIdentifier 15 103 2.37 telexNumber 15 104 2.38 title 15 105 2.39 uid 15 106 2.40 uniqueMember 16 107 2.41 userPassword 16 108 2.42 x121Address 17 109 2.43 x500UniqueIdentifier 17 111 3. Object Classes 18 112 3.1 applicationProcess 18 113 3.2 country 18 114 3.3 device 18 115 3.4 groupOfNames 19 116 3.5 groupOfUniqueNames 19 117 3.6 locality 19 118 3.7 organization 20 119 3.8 organizationalPerson 20 120 3.9 organizationalRole 20 121 3.10 organizationalUnit 21 122 3.11 person 21 123 3.12 residentialPerson 21 125 4. IANA Considerations 22 127 5. Security Considerations 23 129 6. Acknowledgements 24 131 7. References 24 132 7.1 Normative 24 133 7.2 Informative 25 135 8. Author's Address 26 137 9. Intellectual Property Rights (IPR) Disclosure 26 139 10. IPR Notice 26 141 11. Copyright Notice and Disclaimer 27 142 1. Introduction 144 This document provides an overview of attribute types and object 145 classes intended for use by Lightweight Directory Access Protocol 146 directory clients for many directory services, such as, White Pages. 147 Originally specified in the X.500 [X.500] documents, these objects 148 are widely used as a basis for the schema in many LDAP directories. 149 This document does not cover attributes used for the administration 150 of directory servers, nor does it include directory objects defined 151 for specific uses in other documents. 153 1.1 Situation 155 This document is a integral part of the LDAP technical specification 156 [ROADMAP] which obsoletes the previously defined LDAP technical 157 specification [RFC3377] in its entirety. In terms of RFC 2256, 158 Sections 6 and 8 of RFC 2256 are obsoleted by [Syntaxes]. Sections 159 5.1, 5.2, 7.1 and 7.2 of RFC 2256 are obsoleted by [Models]. The 160 remainder of RFC 2256 is obsoleted by this document. Section 2.4 of 161 this document supercedes the technical specification for the 'dc' 162 attribute type found in RFC 2247. The remainder of RFC 2247 remains 163 in force. 165 This document updates RFC 2798 by replacing the informative 166 description of the 'uid' attribute type, with the definitive 167 description provided in Section 2.39 of this document. 169 A number of schema elements which were included in the previous 170 revision of the LDAP Technical Specification are not included in this 171 revision of LDAP. PKI-related schema elements are now specified in 172 [LDAP-CERT] and [LDAP-CRL]. Unless reintroduced in future technical 173 specifications, the remainder are to be considered Historic. 175 1.2 Conventions 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC 2119 [RFC2119]. 181 1.3 General Issues 183 This document references Syntaxes given in Section 3 of [Syntaxes] 184 and Matching Rules specified in Section 4 of [Syntaxes]. 186 The definitions of Attribute Types and Object Classes are written 187 using the ABNF form of AttributeTypeDescription and 188 ObjectClassDescription given in [Models]. Lines have been folded 189 for readability. 191 1.4 Source 193 The schema definitions in this document are based on those found in 194 the X.500-series [X.520] and [X.521], RFC 2798 [RFC2798] and 195 RFC 2247 [RFC2247], specifically: 197 Sections Source 198 ============ ================== 199 2.1 - 2.3 X.520 [X.520] 200 2.4 RFC 2247 [RFC2247] 201 2.5 - 2.38 X.520 [X.520] 202 2.39 RFC 2798 [2798] 203 2.40 - 2.43 X.520 [X.520] 204 3.1 - 3.12 X.521 [X.521] 206 However, the descriptions in this document SHALL be considered 207 definitive for use in LDAP. 209 2. Attribute Types 211 The Attribute Types contained in this section hold user information. 213 There is no requirement that servers implement the following 214 attribute types: 216 searchGuide 217 teletexTerminalIdentifier 219 In fact, their use is greatly discouraged. 221 An LDAP server implementation SHOULD recognize the rest of the 222 attribute types described in this section. 224 2.1 businessCategory 226 The businessCategory attribute type describes the kinds of business 227 performed by an organization (e.g., "banking", "transportation"). 228 Each kind is one value of this multi-valued attribute. 230 ( 2.5.4.15 NAME 'businessCategory' 231 EQUALITY caseIgnoreMatch 232 SUBSTR caseIgnoreSubstringsMatch 233 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 235 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String 236 syntax [Syntaxes]. 238 2.2 c 240 The c (countryName) attribute type contains a two-letter ISO 3166 241 [ISO3166] country code (e.g., "DE"). (Source: X.520) 243 ( 2.5.4.6 NAME 'c' 244 SUP name 245 SINGLE-VALUE ) 247 2.3 cn 249 The cn (commonName) attribute type contains names of an object 250 (e.g., "Martin K Smith", "Marty Smith", "printer12"). Each name is 251 one value of this multi-valued attribute. If the object corresponds 252 to a person, it is typically the person's full name. 253 (Source: X.520) 255 ( 2.5.4.3 NAME 'cn' 256 SUP name ) 258 2.4 dc 260 The dc (short for domainComponent) attribute type is a string 261 holding one component, a