idnits 2.17.1 draft-howard-namedobject-01.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: ---------------------------------------------------------------------------- ** 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. == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 67: '... STRUCTURAL MAY cn )...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (1 June 2003) is 7634 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2252' is defined on line 109, but no explicit reference was found in the text ** 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) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Application Working Group L. Howard 3 INTERNET-DRAFT PADL Software 4 Expires in six months from 1 June 2003 5 Intended Category: Informational 7 A Structural Object Class for Arbitrary Auxiliary Object Classes 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 This document is an Internet-Draft. Internet-Drafts are working docu- 16 ments of the Internet Engineering Task Force (IETF), its areas, and its 17 working groups. Note that other groups may also distribute working docu- 18 ments as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months. 21 Internet-Drafts may be updated, replaced, or made obsolete by other doc- 22 uments at any time. It is not appropriate to use Internet-Drafts as ref- 23 erence material or to cite them other than as a "working draft" or "work 24 in progress". 26 To learn the current status of any Internet-Draft, please check the 1id- 27 abstracts.txt listing contained in the Internet-Drafts Shadow Directo- 28 ries on ds.internic.net (US East Coast), nic.nordu.net (Europe), 29 ftp.isi.edu (US West Coast), or munnari.oz.au (PacificRim). 31 Distribution of this document is unlimited. 33 Abstract 35 The Lightweight Directory Access Protocol (LDAP) supports auxiliary 36 object classes for adding additional attributes to a directory entry. 38 This document defines a structural object class that may be used when no 39 other structural object class is available. 41 1. Background 42 Schema for LDAP directories often define auxiliary object classes that 43 are intended to be used with a specific structural object class. 45 For example, the posixGroup object class [RFC2307bis] is an auxiliary 46 object class that may be used to overlay POSIX group identification on 47 an existing group of distinguished names. In this case, it is suggested 48 that the groupOfUniqueNames object class be used as a structural object 49 class. However, this may sometimes be inappropriate: that groupOfUnique- 50 Names requires at least one member may make it impossible to migrate 51 existing group information. [RFC2307bis] could define a specific struc- 52 tural object class for this case (say, structuralPosixGroup), but this 53 would unnecessarily add to the proliferation of redundant schema. 55 This document defines a structural object class, namedObject, that man- 56 dates no attributes other than a common name. Arbitrary auxiliary object 57 classes may be thus associated with entries which have this as a struc- 58 tural object class. 60 2. Object Class Definitions 62 The namedObject object class defines one mandatory attribute, a common 63 name. The OID arc is iso(1) org(3) dod(6) internet(1) private(4) enter- 64 prise(1) padl(5322) namedObjectSchema(13) objectClasses(1). 66 ( 1.3.6.1.4.1.5322.13.1.1 NAME 'namedObject' SUP top 67 STRUCTURAL MAY cn ) 69 Other attributes allowed by auxiliary classes may be used for naming 70 purposes. 72 An example entry would be: 74 dn: cn=Sample Entry,dc=padl,dc=com 75 objectClass: top 76 objectClass: namedObject 77 cn: Sample Entry 79 An example entry with an auxiliary class from [RFC2307bis] would be: 81 dn: cn=wheel,ou=Groups,dc=padl,dc=com 82 objectClass: top 83 objectClass: namedObject 84 objectClass: posixGroup 85 cn: wheel 86 gidNumber: 0 87 memberUid: root 89 3. Security Considerations 91 The introduction of this schema element does not impact the security of 92 the Internet. See [RFC2251] for general LDAP security considerations. 94 4. IANA Considerations 96 No IANA assignments are requested. 98 This document uses the OID 1.3.6.1.4.1.5322.13.1.1 to identity the name- 99 dObject schema element. This OID was assigned by PADL Software Pty Ltd 100 under its IANA assigned private enterprise allocation for use in this 101 specification. 103 5. References 105 [RFC2251] 106 M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol 107 (v3)", RFC 2251, December 1997. 109 [RFC2252] 110 Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight 111 Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 112 2252, December 1997. 114 [RFC2307bis] 115 L. Howard, M. Ansari, "An Approach for Using LDAP as a Network 116 Information Service", draft-howard-rfc2307bis-02.txt (a work in 117 progress). 119 6. Author's Address 121 Luke Howard 122 PADL Software Pty. Ltd. 123 PO Box 59 124 Central Park Vic 3145 125 Australia 126 EMail: lukeh@padl.com 128 7. Full Copyright Statement 130 Copyright (C) The Internet Society (2002). All Rights Reserved. 132 This document and translations of it may be copied and furnished to oth- 133 ers, and derivative works that comment on or otherwise explain it or 134 assist in its implementation may be prepared, copied, published and dis- 135 tributed, in whole or in part, without restriction of any kind, provided 136 that the above copyright notice and this paragraph are included on all 137 such copies and derivative works. However, this document itself may not 138 be modified in any way, such as by removing the copyright notice or ref- 139 erences to the Internet Society or other Internet organizations, except 140 as needed for the purpose of developing Internet standards in which case 141 the procedures for copyrights defined in the Internet Standards process 142 must be followed, or as required to translate it into languages other 143 than English. 145 The limited permissions granted above are perpetual and will not be 146 revoked by the Internet Society or its successors or assigns. 148 This document and the information contained herein is provided on an "AS 149 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 150 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 151 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 152 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT- 153 NESS FOR A PARTICULAR PURPOSE.