idnits 2.17.1 draft-ietf-schema-ldap-01.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-27) 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 (August 1, 1998) is 9401 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 279 looks like a reference -- Missing reference section? '2' on line 282 looks like a reference -- Missing reference section? '4' on line 288 looks like a reference -- Missing reference section? '3' on line 305 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 Innosoft International, Inc. 3 August 1, 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 view the entire list of current Internet-Drafts, please check 21 the "1id-abstracts.txt" listing contained in the Internet-Drafts 22 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 23 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 24 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu. 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]. The schema MAY 44 have a numeric OID assigned to it by a schema listing or registration 45 service. 47 A schema may import definitions from another schema. Schema imports 48 are not, however, transitive. 50 For example, a schema contains a definition for a "modem" object 51 class, which is to be defined as a subclass of the X.521 "device" 52 object class. In this case, the schema MUST import the definitions 53 of X.521. 55 4. The "schema-ldap-0" MIME Directory Profile Registration 57 This profile is identified by the following registration template 58 information. 60 To: ietf-mime-direct@imc.org 62 Subject: Registration of text/directory MIME profile "schema-ldap-0" 64 Profile name: schema-ldap-0 66 Profile purpose: To represent a schema defined for use with 67 LDAPv3 servers. 69 Profile types: SOURCE, ldapSchemas, attributeTypes, 70 matchingRules, objectClasses, matchingRuleUse, ldapSyntaxes 72 Profile special notes: 74 The charset parameter MUST be present on the MIME content, and 75 the value of this parameter MUST be "utf-8". This ensures that 76 schema values can be used in LDAPv3 attribute values without a 77 character set translation. 79 Neither the "BEGIN" and "END" types nor type grouping are used 80 in contents of this profile. 82 All of the types in this profile with the exception of ldapSchemas 83 may be multi-valued. Each value is present on its own contentline. 84 Values may be present in any order, and need not be arranged by type. 86 The "SOURCE" type is optional, and if values are present they SHOULD 87 be URIs of the "ldap" form. If the URI is of the "ldap" form, the 88 object indicated by the URI is a subschema entry. The use of other 89 forms are reserved for future applications. 91 In this version of the profile, exactly one value of the ldapSchemas 92 type MUST be present. (Later versions of the profile may permit 93 multiple ldapSchemas values to be present in a content.) 95 Implementors should note that there will likely be values of the 96 profile types in most contents much longer than 76 bytes. In 97 addition, there may be non-ASCII characters and embedded CRLFs 98 inside of values, which could require either quoting of the value or 99 use of a content transfer encoding. 101 If a contentline in a particular content contains a "context" 102 parameter and the value of that parameter is not "ldap", then that 103 contentline SHOULD be ignored. 105 Intended usage: COMMON 107 5. MIME Directory Type Registrations 109 This document defines all the types, with the exception of "SOURCE" 110 used in the schema-ldap-0 profile. The "SOURCE" type is defined in 111 [1]. These types are primarily intended for use in the 112 "schema-ldap-0" directory profile, although they may be applicable 113 to other profiles defined in the future. 115 5.1. ldapSchemas 117 To: ietf-mime-direct@imc.org 118 Subject: Registration of text/directory MIME type ldapSchemas 120 Type name: ldapSchemas 122 Type purpose: To represent the LDAPv3 attribute "ldapSchemas", 123 defined in section A.1. 125 Type encoding: 8bit 127 Type valuetype: text, encoded according to the BNF of section A.4. 129 Type special notes: Each value of this type specifies the contents of 130 an LDAP schema definition. A definition of each object class, 131 attribute, matching rule, matching rule use and syntax referenced in 132 a value of ldapSchemas MUST either be defined in one of the schemas 133 referenced in the "IMPORTS" field, or present in the content 134 containing this value. 136 Intended usage: COMMON 138 5.2. attributeTypes 140 To: ietf-mime-direct@imc.org 141 Subject: Registration of text/directory MIME type attributeTypes 143 Type name: attributeTypes 145 Type purpose: To represent the LDAPv3 attribute "attributeTypes", 146 defined in section 5.1.6 of [4]. 148 Type encoding: 8bit 150 Type valuetype: text, encoded according to the BNF of 151 "AttributeTypeDescription" given in section 4.2 of [4]. 153 Type special notes: Each value of the type specifies one LDAPv3 154 attribute type definition. The syntax and matching rules 155 referenced in a value of attributeTypes MUST either be present in 156 this content, or defined in one of the schemas referenced in the 157 "IMPORTS" field of the ldapSchemas line. 159 Intended usage: COMMON 161 5.3. matchingRules 163 To: ietf-mime-direct@imc.org 164 Subject: Registration of text/directory MIME type matchingRules 166 Type name: matchingRules 168 Type purpose: To represent the LDAPv3 attribute "matchingRules", 169 defined in section 5.1.8 of [4]. 171 Type encoding: 8bit 173 Type valuetype: text, encoded according to the BNF of 174 "MatchingRuleDescription" given in section 4.5 of [4]. 176 Type special notes: Each value of the type specifies one matching rule 177 definition. The syntax reference in a value of matchingRules MUST 178 either be present in this content, or defined in one of the schemas 179 referenced in the "IMPORTS" field of the ldapSchemas line. 181 Intended usage: COMMON 183 5.4. objectClasses 185 To: ietf-mime-direct@imc.org 186 Subject: Registration of text/directory MIME type objectClasses 188 Type name: objectClasses 190 Type purpose: To represent the LDAPv3 attribute "objectClasses", 191 defined in section 5.1.7 of [4]. 193 Type encoding: 8bit 195 Type valuetype: text, encoded according to the BNF of 196 "ObjectClassDescription" given in section 4.4 of [4]. 198 Type special notes: Each value of the type specifies one LDAPv3 199 object class definition. The attributes and object classes 200 referenced in a value of objectClasses MUST either be present in 201 this content, or defined in one of the schema referenced in the 202 "IMPORTS" field of the ldapSchemas line. 204 Intended usage: COMMON 206 5.5. matchingRuleUse 208 To: ietf-mime-direct@imc.org 209 Subject: Registration of text/directory MIME type matchingRuleUse 210 Type name: matchingRuleUse 212 Type purpose: To represent the LDAPv3 attribute "matchingRuleUse", 213 defined in section 5.1.9 of [4]. 215 Type encoding: 8bit 217 Type valuetype: text, encoded according to the BNF of 218 "MatchingRuleUseDescription" given in section 4.5 of [4]. 220 Type special notes: Each value of the type specifies a relationship 221 between a matching rule and attribute types. The matching rule and 222 attribute types referenced in a value of matchingRuleUse MUST either 223 be present in this content, or defined in one of the schemas 224 referenced in the "IMPORTS" statement of the ldapSchemas line. 226 Intended usage: COMMON 228 5.6. ldapSyntaxes 230 To: ietf-mime-direct@imc.org 231 Subject: Registration of text/directory MIME type ldapSyntaxes 233 Type name: ldapSyntaxes 235 Type purpose: To represent the LDAPv3 attribute "ldapSyntaxes", 236 defined in section 5.3.1 of [3]. 238 Type encoding: 8bit 240 Type valuetype: text, encoded according to the BNF of 241 "SyntaxDescription" given in section 4.3.3 of [3]. 243 Type special notes: Each value of this type specifies a single LDAPv3 244 attribute value syntax. 246 Intended usage: COMMON 248 6. Example 250 From: Whomever@wherever.com 251 To: Someone@somewhere.com 252 Subject: schema information 253 MIME-Version: 1.0 254 Message-Id: 255 Content-Type: text/directory; profile="schema-ldap-0";charset="utf-8" 256 Content-Transfer-Encoding: Quoted-Printable 257 ldapSchemas: ( 1.2.3.4 NAME 'bogus schema' CLASSES ( top $ thing ) = 258 ATTRIBUTES ( objectClass $ name ) SYNTAXES ( = 259 1.3.6.1.4.1.1466.115.121.1.38 $ 1.3.6.1.4.1.1466.115.121.1.15 ) ) 260 attributeTypes: ( 2.5.4.0 NAME 'objectClass' SYNTAX = 261 1.3.6.1.4.1.1466.115.121.1.38 ) 262 objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) 263 attributeTypes: ( 2.5.4.41 NAME 'name' SYNTAX = 264 1.3.6.1.4.1.1466.115.121.1.15{32768} ) 265 objectClasses: ( 2.5.6.999 NAME 'thing' MUST name ) 266 ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'String' ) 267 ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) 269 7. Security Considerations 271 A MIME body part containing an text/directory of the schema-ldap-0 272 profile may be incorporated in a digitally signed MIME content, which 273 can be used to verify that the body part has not been modified in 274 transit. When the signer has been certified by a trusted third party 275 service, it may also be possible to verify the origin of the content. 277 8. Bibliography 279 [1] "A MIME Content-Type for Directory Information", 07/24/1997, 280 INTERNET DRAFT . 282 [2] "Lightweight Directory Access Protocol (v3)", Dec. 1997, 283 RFC 2251. 285 [3] "Lightweight Directory Access Protocol (v3): Attribute Syntax 286 Definitions", Dec. 1997, RFC 2252. 288 [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement 289 Levels", RFC 2119. 291 9. Authors Address 293 Mark Wahl 294 Innosoft International, Inc. 295 8911 Capital of Texas Hwy Suite 4140 296 Austin, TX 78759 297 USA 299 EMail: M.Wahl@innosoft.com 301 Appendix A 303 This appendix defines two new attributes which could be present in 304 an subschema entry. These attributes could be added to a future 305 revision of the LDAP attribute definition [3]. 307 A.1. ldapSchemas attribute type definition 309 ( 1.3.6.1.4.1.1466.101.120.17 NAME 'ldapSchemas' 310 SYNTAX 1.3.6.1.4.1.1466.115.121.1.56 USAGE directoryOperation ) 312 Each value of the ldapSchemas attribute defines one schema. Its 313 syntax, given in section A.2, contains the elements needed for an 314 LDAPv3 server to correctly process operations which use the 315 definitions from this syntax. 317 A.2. LDAP Schema Definition syntax definition 319 ( 1.3.6.1.4.1.1466.115.121.1.56 DESC 'LDAP Schema Definition' ) 321 Values in this syntax are represented according to the following BNF: 323 LdapSchema = "(" whsp 324 numericoid whsp 325 [ "NAME" qdescrs ] 326 [ "OBSOLETE" whsp ] 327 [ "IMPORTS" oids ] 328 [ "CLASSES" oids ] 329 [ "ATTRIBUTES" oids ] 330 [ "MATCHING-RULES" oids ] 331 [ "SYNTAXES" oids ] 332 whsp ")" 334 The numericoid field uniquely identifies the schema. A new OID 335 should be assigned if any of the fields of the schema change. It is 336 not possible to import definitions from a schema until an OID has 337 been assigned to it. 339 The "NAME" field contains optional human-readable labels for the 340 schema. 342 The "OBSOLETE" field is present if the schema is obsolete. 344 The "IMPORTS" field lists the OIDs of other schemas which are to be 345 incorporated by reference into this schema. It is an error to have 346 an attribute type or object class defined in a schema with the same 347 name but a different OID as an attribute type or object class in an 348 imported schema. It is also an error to import from two schema 349 definitions in which there are attribute types or object classes 350 with the same names but different OIDs. 352 The "CLASSES" field lists the OIDs of object classes defined in this 353 schema. A schema need not contain any object class definitions. A 354 schema must not contain two object class definitions of the same name 355 but with different OIDs. 357 The "ATTRIBUTES" field lists the OIDs of attribute types defined in 358 this schema. A schema need not contain any object class definitions. 359 A schema must not contain two attribute type definitions of the same 360 name but with different OIDs. 362 The "MATCHING-RULES" field lists the OIDs of matching rules defined 363 in this schema. A schema need not contain any matching rules. 365 The "SYNTAXES" field lists the OIDs of syntaxes defined in this 366 schema. A schema need not contain any syntaxes.