idnits 2.17.1 draft-zeilenga-ldap-cosine-02.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 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1127. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1098. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1105. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1111. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1115), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** 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. 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 is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == 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 abstract seems to indicate that this document obsoletes RFC1274, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document updates RFC2798, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1029 has weird spacing: '...eNumber mobi...' == Line 1030 has weird spacing: '...eNumber pag...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (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 (6 February 2006) is 6653 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: 'RFC1487' is mentioned on line 120, but not defined ** Obsolete undefined reference: RFC 1487 (Obsoleted by RFC 1777, RFC 3494) == Missing Reference: 'RFC2251' is mentioned on line 121, but not defined ** Obsolete undefined reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) == Missing Reference: 'RFC2822' is mentioned on line 779, but not defined ** Obsolete undefined reference: RFC 2822 (Obsoleted by RFC 5322) == Missing Reference: 'Historic' is mentioned on line 1035, but not defined == Missing Reference: 'RFC1279' is mentioned on line 1062, but not defined == Missing Reference: 'QoS' is mentioned on line 1068, but not defined == Unused Reference: 'RFC2247' is defined on line 964, but no explicit reference was found in the text == Unused Reference: 'NamingPlan' is defined on line 998, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2822 (ref. 'RFC2821') (Obsoleted by RFC 5322) ** 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-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Models' -- 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-user-schema-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Schema' -- No information found for draft-ietf-ldapbis-authmeth-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'AuthMeth' -- No information found for draft-zeilenga-ldap-namingplan-xx - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 1274 (Obsoleted by RFC 4524) -- No information found for draft-ietf-ldapbis-bcp64-xx - is the name correct? Summary: 10 errors (**), 0 flaws (~~), 14 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Editor: Kurt D. Zeilenga 3 Intended Category: Standard Track OpenLDAP Foundation 4 Expires in six months 6 February 2006 5 Obsoletes: RFC 1274 6 Updates: RFC 2247, RFC 2798 8 COSINE LDAP/X.500 Schema 9 11 Status of this Memo 13 This document is intended to be, after appropriate review and 14 revision, submitted to the RFC Editor as a Standard Track document. 15 Distribution of this memo is unlimited. Technical discussion of this 16 document will take place on the IETF LDAPEXT mailing list 17 . Please send editorial comments directly to the 18 author . 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware have 22 been or will be disclosed, and any of which he or she becomes aware 23 will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering Task 26 Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference material 32 or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright (C) The Internet Society (2006). All Rights Reserved. 42 Please see the Full Copyright section near the end of this document 43 for more information. 45 Abstract 46 This document provides a collection of schema elements for use with 47 the Lightweight Directory Access Protocol (LDAP) from the COSINE and 48 Internet X.500 pilot projects. 50 This document obsoletes RFC 1274 and updates RFC 2247 and RFC 2798. 52 Table of Contents 54 Status of this Memo 1 55 Abstract 2 56 Table of Contents 57 1. Background and Intended Use 3 58 1.1. Relationship with Other Documents 59 1.2. Terminology and Conventions 60 2. COSINE Attribute Types 4 61 2.1. associatedDomain 62 2.2. associatedName 63 2.3. buildingName 64 2.3. co 65 2.5. documentAuthor 66 2.6. documentIdentifier 67 2.7. documentLocation 68 2.8. documentPublisher 69 2.9. documentTitle 70 2.10. documentVersion 71 2.11. drink 72 2.12. homePhone 73 2.13. homePostalAddress 74 2.14. host 75 2.16. info 76 2.17. mail 77 2.18. manager 78 2.19. mobile 79 2.20. organizationalStatus 80 2.21. pager 81 2.22. personalTitle 82 2.23. roomNumber 83 2.24. secretary 84 2.26. uniqueIdentifier 85 2.27. userClass 86 3. COSINE Object Classes 14 87 3.1. account 88 3.2. document 89 3.3. documentSeries 90 3.4. domain 91 3.5. domainRelatedObject 92 3.6. friendlyCountry 93 3.7. rFC822LocalPart 94 3.8. room 95 3.9. simpleSecurityObject 96 4. Security Considerations 19 97 5. IANA Considerations 20 98 6. Acknowledgments 21 99 7. Editor's Address 100 8. References 101 A. Changes Since RFC 1274 23 102 Intellectual Property Rights 24 103 Full Copyright 105 1. Background and Intended Use 107 In the late 1980s, X.500 Directory Services were standardised by the 108 CCITT (Commite' Consultatif International de Telegraphique et 109 Telephonique), now a part of the ITU (International Telephone Union). 110 This lead to Directory Service piloting activities in the early 1990s, 111 including the COSINE (Co-operation and Open Systems Interconnection in 112 Europe) PARADISE Project pilot [COSINEpilot] in Europe. Motivated by 113 needs large scale directory pilots, RFC 1274 was published to 114 standardize directory schema and naming architecture for use in the 115 COSINE and other Internet X.500 pilots [RFC1274]. 117 In the years that followed, X.500 Directory Services have evolved to 118 incorporate new capabilities and even new protocols. In particular, 119 the Lightweight Directory Access Protocol (LDAP) [Roadmap] was 120 introduced in the early 1990s [RFC1487], with Version 3 of LDAP 121 introduced in the late 1990s [RFC2251] and subsequently revised in the 122 2005 [Roadmap]. 124 While much of the material in RFC 1274 has been superceed by 125 subsequently published ITU-T Recommendations and IETF RFCs, many of 126 the schema elements lack standardized schema descriptions for use in 127 modern X.500 and LDAP directory services despite the fact that these 128 schema elements are in wide use today. As the old schema descriptions 129 cannot be used without adaptation, interoperabilty issues may arise 130 due to lack of standardized modern schema descriptions. 132 This document addresses these issues by offering standardized schema 133 descriptions, where needed, for widely-used COSINE schema elements. 135 1.1. Relationship to Other Documents 137 This document, together with [Schema] and [Syntaxes], obsoletes RFC 138 1274 in its entirety. [Schema] replaces sections 9.3.1 (Userid) and 139 9.3.21 (Domain Component) of RFC 1274. [Syntaxes] replaces section 140 9.4 (Generally useful syntaxes) of RFC 1274. 142 This document replaces the remainder of RFC 1274. Appendix A. 143 discusses changes since RFC 1274, as well as why certain schema 144 elements were not brought forward in this revision of the COSINE 145 schema. All elements not brought are to be regarded as Historic. 147 The description of the 'domain' object class provided in this document 148 supercedes that found in RFC 2247. That is, section 3.4 of this 149 document replaces section 5.2 of RFC 2247. 151 Some of schema elements specified here were described in RFC 2798 152 (inetOrgPerson schema). This document supersedes these descriptions. 153 This document, together with [Schema], replaces section 9.1.3 of RFC 154 2798. 156 1.2. Terminology and Conventions 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in BCP 14 [RFC2119]. 162 DIT stands for Directory Information Tree. 163 DN stands for Distinguished Name. 164 DSA stands for Directory System Agent, a server. 165 DSE stands for DSA-Specific Entry. 166 DUA stands for Directory User Agent, a client. 168 These terms are discussed in [Models]. 170 Schema definitions are provided using LDAP description formats 171 [Models]. Definitions provided here are formatted (line wrapped) for 172 readability. 174 2. COSINE Attribute Types 176 This section details COSINE attribute types for use in LDAP. 178 2.1. associatedDomain 180 The 'associatedDomain' attribute specifies DNS [RFC1034][RFC2181] host 181 names [RFC1123] which are associated with an object. That is, values 182 of this attribute should conform to the following ABNF: 184 domain = root / label *( DOT label ) 185 root = SPACE 186 label = LETDIG [ *61( LETDIG / HYPHEN ) LETDIG ] 187 LETDIG = %x30-39 / %x41-5A / %x61-7A ; "0" - "9" / "A"-"Z" / "a"-"z" 188 SPACE = %x20 ; space (" ") 189 HYPHEN = %x2D ; hyphen ("-") 190 DOT = %x2E ; period (".") 192 For example, the entry in the DIT with a DN might 193 have an associated domain of "example.com". 195 ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain' 196 EQUALITY caseIgnoreIA5Match 197 SUBSTR caseIgnoreIA5SubstringsMatch 198 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 200 The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the 201 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are 202 described in [Syntaxes]. 204 It is noted that the directory will not ensure that values of this 205 attribute conform to the production provided above. It is 206 the application responsibility to ensure domains it stores in this 207 attribute are appropriately represented. 209 It is also noted that applications supporting Internationalized Domain 210 Names SHALL use the ToASCII method [RFC3490] to produce