idnits 2.17.1 draft-ietf-schema-ldap-00.txt: ** The Abstract section seems to be numbered 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-23) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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.) ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([2], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (January 6, 1998) is 9604 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 section? '1' on line 280 looks like a reference -- Missing reference section? '2' on line 283 looks like a reference -- Missing reference section? '4' on line 289 looks like a reference -- Missing reference section? '3' on line 307 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Wahl 2 Request for Comments: DRAFT Critical Angle Inc. 3 January 6, 1998 5 MIME Directory Profile for LDAP Schema 6 8 1. Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working docu- 11 ments of the Internet Engineering Task Force (IETF), its areas, and its 12 working groups. Note that other groups may also distribute working 13 documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference material 18 or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 2. Abstract 28 This document defines a MIME directory profile [1] for holding an 29 LDAP [2] schema. It is intended for communication with the Internet 30 schema listing service. 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 34 this document are to be interpreted as described in RFC 2119 [4]. 36 3. Overview 38 This document defines how a MIME type may be used to transfer a 39 single LDAPv3 schema definition. 41 A schema for use with LDAPv3 consists of any number of object class, 42 attribute type, matching rule and syntax definitions. These concepts 43 are defined in the LDAPv3 protocol definition [2]. 45 The schema may have a numeric OID assigned to it by a schema listing 46 or registration service. 48 A schema may import definitions from another schema. Schema imports 49 are not, however, transitive. 51 For example, a schema contains a definition for a "modem" object 52 class, which is to be defined as a subclass of the X.521 "device" 53 object class. In this case, the schema MUST import the definitions 54 of X.521. 56 4. The "schema-ldap-0" MIME Directory Profile Registration 58 This profile is identified by the following registration template 59 information. 61 To: ietf-mime-direct@imc.org 63 Subject: Registration of text/directory MIME profile "schema-ldap-0" 65 Profile name: schema-ldap-0 67 Profile purpose: To represent a schema defined for use with 68 LDAPv3 servers. 70 Profile types: SOURCE, ldapSchemas, attributeTypes, 71 matchingRules, objectClasses, matchingRuleUse, ldapSyntaxes 73 Profile special notes: 75 The charset parameter MUST be present on the MIME content, and 76 the value of this parameter MUST be "utf-8". This ensures that 77 schema values can be used in LDAPv3 attribute values without a 78 character set translation. 80 Neither the "BEGIN" and "END" types nor type grouping are used 81 in contents of this profile. 83 All of the types in this profile with the exception of ldapSchemas 84 may be multi-valued. Each value is present on its own contentline. 85 Values may be present in any order, and need not be arranged by type. 87 The "SOURCE" type is optional, and if values are present they SHOULD 88 be URIs of the "ldap" form. If the URI is of the "ldap" form, the 89 object indicated by the URI is a subschema entry. The use of other 90 forms are reserved for future applications. 92 In this version of the profile, exactly one value of the ldapSchemas 93 type MUST be present. (Later versions of the profile may permit 94 multiple ldapSchemas values to be present in a content.) 96 Implementors should note that there will likely be values of the 97 profile types in most contents much longer than 76 bytes. In 98 addition, there may be non-ASCII characters and embedded CRLFs 99 inside of values, which could require either quoting of the value or 100 use of a content transfer encoding. 102 If a contentline in a particular content contains a "context" 103 parameter and the value of that parameter is not "ldap", then that 104 contentline SHOULD be ignored. 106 Intended usage: COMMON 108 5. MIME Directory Type Registrations 110 This document defines all the types, with the exception of "SOURCE" 111 used in the schema-ldap-0 profile. The "SOURCE" type is defined in 112 [1]. These types are primarily intended for use in the 113 "schema-ldap-0" directory profile, although they may be applicable 114 to other profiles defined in the future. 116 5.1. ldapSchemas 118 To: ietf-mime-direct@imc.org 119 Subject: Registration of text/directory MIME type ldapSchemas 121 Type name: ldapSchemas 123 Type purpose: To represent the LDAPv3 attribute "ldapSchemas", 124 defined in section A.1. 126 Type encoding: 8bit 128 Type valuetype: text, encoded according to the BNF of section A.4. 130 Type special notes: Each value of this type specifies the contents of 131 an LDAP schema definition. A definition of each object class, 132 attribute, matching rule, matching rule use and syntax referenced in 133 a value of ldapSchemas MUST either be defined in one of the schemas 134 referenced in the "IMPORTS" field, or present in the content 135 containing this value. 137 Intended usage: COMMON 139 5.2. attributeTypes 141 To: ietf-mime-direct@imc.org 142 Subject: Registration of text/directory MIME type attributeTypes 144 Type name: attributeTypes 146 Type purpose: To represent the LDAPv3 attribute "attributeTypes", 147 defined in section 5.1.6 of [4]. 149 Type encoding: 8bit 151 Type valuetype: text, encoded according to the BNF of 152 "AttributeTypeDescription" given in section 4.2 of [4]. 154 Type special notes: Each value of the type specifies one LDAPv3 155 attribute type definition. The syntax and matching rules 156 referenced in a value of attributeTypes MUST either be present in 157 this content, or defined in one of the schemas referenced in the 158 "IMPORTS" field of the ldapSchemas line. 160 Intended usage: COMMON 162 5.3. matchingRules 164 To: ietf-mime-direct@imc.org 165 Subject: Registration of text/directory MIME type matchingRules 167 Type name: matchingRules 169 Type purpose: To represent the LDAPv3 attribute "matchingRules", 170 defined in section 5.1.8 of [4]. 172 Type encoding: 8bit 174 Type valuetype: text, encoded according to the BNF of 175 "MatchingRuleDescription" given in section 4.5 of [4]. 177 Type special notes: Each value of the type specifies one matching rule 178 definition. The syntax reference in a value of matchingRules MUST 179 either be present in this content, or defined in one of the schemas 180 referenced in the "IMPORTS" field of the ldapSchemas line. 182 Intended usage: COMMON 184 5.4. objectClasses 186 To: ietf-mime-direct@imc.org 187 Subject: Registration of text/directory MIME type objectClasses 189 Type name: objectClasses 191 Type purpose: To represent the LDAPv3 attribute "objectClasses", 192 defined in section 5.1.7 of [4]. 194 Type encoding: 8bit 196 Type valuetype: text, encoded according to the BNF of 197 "ObjectClassDescription" given in section 4.4 of [4]. 199 Type special notes: Each value of the type specifies one LDAPv3 200 object class definition. The attributes and object classes 201 referenced in a value of objectClasses MUST either be present in 202 this content, or defined in one of the schema referenced in the 203 "IMPORTS" field of the ldapSchemas line. 205 Intended usage: COMMON 207 5.5. matchingRuleUse 209 To: ietf-mime-direct@imc.org 210 Subject: Registration of text/directory MIME type matchingRuleUse 212 Type name: matchingRuleUse 213 Type purpose: To represent the LDAPv3 attribute "matchingRuleUse", 214 defined in section 5.1.9 of [4]. 216 Type encoding: 8bit 218 Type valuetype: text, encoded according to the BNF of 219 "MatchingRuleUseDescription" given in section 4.5 of [4]. 221 Type special notes: Each value of the type specifies a relationship 222 between a matching rule and attribute types. The matching rule and 223 attribute types referenced in a value of matchingRuleUse MUST either 224 be present in this content, or defined in one of the schemas 225 referenced in the "IMPORTS" statement of the ldapSchemas line. 227 Intended usage: COMMON 229 5.6. ldapSyntaxes 231 To: ietf-mime-direct@imc.org 232 Subject: Registration of text/directory MIME type ldapSyntaxes 234 Type name: ldapSyntaxes 236 Type purpose: To represent the LDAPv3 attribute "ldapSyntaxes", 237 defined in section 5.3.1 of [3]. 239 Type encoding: 8bit 241 Type valuetype: text, encoded according to the BNF of 242 "SyntaxDescription" given in section 4.3.3 of [3]. 244 Type special notes: Each value of this type specifies a single LDAPv3 245 attribute value syntax. 247 Intended usage: COMMON 249 6. Example 251 From: Whomever@wherever.com 252 To: Someone@somewhere.com 253 Subject: schema information 254 MIME-Version: 1.0 255 Message-Id: 256 Content-Type: text/directory; profile="schema-ldap-0";charset="utf-8" 257 Content-Transfer-Encoding: Quoted-Printable 258 ldapSchemas: ( 1.2.3.4 NAME 'bogus schema' CLASSES ( top $ thing ) = 259 ATTRIBUTES ( objectClass $ name ) SYNTAXES ( = 260 1.3.6.1.4.1.1466.115.121.1.38 $ 1.3.6.1.4.1.1466.115.121.1.15 ) ) 261 attributeTypes: ( 2.5.4.0 NAME 'objectClass' SYNTAX = 262 1.3.6.1.4.1.1466.115.121.1.38 ) 263 objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) 264 attributeTypes: ( 2.5.4.41 NAME 'name' SYNTAX = 265 1.3.6.1.4.1.1466.115.121.1.15{32768} ) 266 objectClasses: ( 2.5.6.999 NAME 'thing' MUST name ) 267 ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'String' ) 268 ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) 270 7. Security Considerations 272 A MIME body part containing an text/directory of the schema-ldap-0 273 profile may be incorporated in a digitally signed MIME content, which 274 can be used to verify that the body part has not been modified in 275 transit. When the signer has been certified by a trusted third party 276 service, it may also be possible to verify the origin of the content. 278 8. Bibliography 280 [1] "A MIME Content-Type for Directory Information", 07/24/1997, 281 INTERNET DRAFT . 283 [2] "Lightweight Directory Access Protocol (v3)", Dec. 1997, 284 RFC 2251. 286 [3] "Lightweight Directory Access Protocol (v3): Attribute Syntax 287 Definitions", Dec. 1997, RFC 2252. 289 [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement 290 Levels", RFC 2119. 292 9. Authors Address 294 Mark Wahl 295 Critical Angle Inc. 296 4815 West Braker Lane #502-385 297 Austin, TX 78759 298 USA 300 Phone: +1 512 372-3160 301 EMail: M.Wahl@critical-angle.com 303 Appendix A 305 This appendix defines two new attributes which could be present in 306 an subschema entry. These attributes could be added to a future 307 revision of the LDAP attribute definition [3]. 309 A.1. ldapSchemas attribute type definition 311 ( 1.3.6.1.4.1.1466.101.120.17 NAME 'ldapSchemas' 312 SYNTAX 1.3.6.1.4.1.1466.115.121.1.56 USAGE directoryOperation ) 314 Each value of the ldapSchemas attribute defines one schema. Its 315 syntax, given in section A.2, contains the elements needed for an 316 LDAPv3 server to correctly process operations which use the 317 definitions from this syntax. 319 A.2. LDAP Schema Definition syntax definition 321 ( 1.3.6.1.4.1.1466.115.121.1.56 DESC 'LDAP Schema Definition' ) 323 Values in this syntax are represented according to the following BNF: 325 LdapSchema = "(" whsp 326 numericoid whsp 327 [ "NAME" qdescrs ] 328 [ "OBSOLETE" whsp ] 329 [ "IMPORTS" oids ] 330 [ "CLASSES" oids ] 331 [ "ATTRIBUTES" oids ] 332 [ "MATCHING-RULES" oids ] 333 [ "SYNTAXES" oids ] 334 whsp ")" 336 The numericoid field uniquely identifies the schema. A new OID 337 should be assigned if any of the fields of the schema change. It is 338 not possible to import definitions from a schema until an OID has 339 been assigned to it. 341 The "NAME" field contains optional human-readable labels for the 342 schema. 344 The "OBSOLETE" field is present if the schema is obsolete. 346 The "IMPORTS" field lists the OIDs of other schemas which are to be 347 incorporated by reference into this schema. It is an error to have 348 an attribute type or object class defined in a schema with the same 349 name but a different OID as an attribute type or object class in an 350 imported schema. It is also an error to import from two schema 351 definitions in which there are attribute types or object classes 352 with the same names but different OIDs. 354 The "CLASSES" field lists the OIDs of object classes defined in this 355 schema. A schema need not contain any object class definitions. A 356 schema must not contain two object class definitions of the same name 357 but with different OIDs. 359 The "ATTRIBUTES" field lists the OIDs of attribute types defined in 360 this schema. A schema need not contain any object class definitions. 361 A schema must not contain two attribute type definitions of the same 362 name but with different OIDs. 364 The "MATCHING-RULES" field lists the OIDs of matching rules defined 365 in this schema. A schema need not contain any matching rules. 367 The "SYNTAXES" field lists the OIDs of syntaxes defined in this 368 schema. A schema need not contain any syntaxes.