idnits 2.17.1 draft-wahl-mime-schema-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-19) 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 == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 1) being 60 lines 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 16 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 71: '...harset parameter MUST be present on th...' RFC 2119 keyword, line 72: '...f this parameter MUST be "utf-8". Thi...' RFC 2119 keyword, line 83: '... and if values are present they SHOULD...' RFC 2119 keyword, line 89: '... type MUST be present. (Later vers...' RFC 2119 keyword, line 100: '... contentline SHOULD be ignored....' (7 more instances...) 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 (October 10, 1997) is 9688 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 297 looks like a reference -- Missing reference section? '2' on line 300 looks like a reference -- Missing reference section? '3' on line 303 looks like a reference -- Missing reference section? '4' on line 328 looks like a reference -- Missing reference section? '5' on line 310 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 October 10, 1997 5 A 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 [3]. 32 3. Overview 34 This document defines how a MIME type may be used to transfer a 35 single LDAPv3 schema definition. 37 A schema for use with LDAPv3 consists of any number of object class, 38 attribute type, matching rule and syntax definitions. These concepts 39 are defined in the LDAPv3 protocol definition [2]. 41 The schema may have a numeric OID assigned to it by a schema listing 42 or registration service. 44 A schema may import definitions from another schema. Schema imports 45 are not, however, transitive. 47 For example, a schema may contain a definition for a "modem" object 48 class, which is to be defined as a subclass of the X.521 "device" 49 object class. In this case, the schema must import the definitions 50 of X.521. 52 4. The "schema-ldap-0" MIME Directory Profile Registration 54 This profile is identified by the following registration template 55 information. 57 To: ietf-mime-direct@imc.org 59 Subject: Registration of text/directory MIME profile "schema-ldap-0" 61 Profile name: schema-ldap-0 63 Profile purpose: To represent a schema defined for use with 64 LDAPv3 servers. 66 Profile types: SOURCE, ldapSchemas, schemaDesc, attributeTypes, 67 matchingRules, objectClasses, matchingRuleUse, ldapSyntaxes 69 Profile special notes: 71 The charset parameter MUST be present on the MIME content, and 72 the value of this parameter MUST be "utf-8". This ensures that 73 schema values can be used in LDAPv3 attribute values without a 74 character set translation. 76 Neither the "BEGIN" and "END" types nor type grouping are used 77 in contents of this profile. 79 All of the types in this profile with the exception of ldapSchemas 80 may be multi-valued. Each value is present on its own contentline. 81 Values may be present in any order, and need not be arranged by type. 83 The "SOURCE" type is optional, and if values are present they SHOULD 84 be URIs of the "ldap" or "http" forms. If the URI is of the "ldap" 85 form, the object indicated by the URI is a subschema entry. The use 86 of the "http" form is reserved for future applications. 88 In this version of the profile, exactly one value of the ldapSchemas 89 type MUST be present. (Later versions of the profile may permit 90 multiple ldapSchemas values to be present in a content.) 92 Implementors should note that there will likely be values of the 93 profile types in most contents much longer than 76 bytes. In 94 addition, there may be non-ASCII characters and embedded CRLFs 95 inside of values, which could require either quoting of the value or 96 use of a content transfer encoding. 98 If a contentline in a particular content contains a "context" 99 parameter and the value of that parameter is not "ldap", then that 100 contentline SHOULD be ignored. 102 Intended usage: COMMON 104 5. MIME Directory Type Registrations 106 This document defines all the types, with the exception of "SOURCE" 107 used in the schema-ldap-0 profile. The "SOURCE" type is defined in 108 [1]. These types are primarily intended for use in the "schema-ldap-0" 109 directory profile, although they may be applicable to other profiles 110 to be defined in the future. 112 5.1. ldapSchemas 114 To: ietf-mime-direct@imc.org 115 Subject: Registration of text/directory MIME type ldapSchemas 117 Type name: ldapSchemas 119 Type purpose: To represent the LDAPv3 attribute "ldapSchemas", 120 defined in section A.1. 122 Type encoding: 8bit 124 Type valuetype: text, encoded according to the BNF of section A.4. 126 Type special notes: Each value of this type specifies the contents of 127 an LDAP schema definition. A definition of each object class, 128 attribute, matching rule, matching rule use and syntax referenced in a 129 value of ldapSchemas MUST either be defined in one of the schemas 130 referenced in the "IMPORTS" field, or present in the content containing 131 this value. 133 Intended usage: COMMON 135 5.2. attributeTypes 137 To: ietf-mime-direct@imc.org 138 Subject: Registration of text/directory MIME type attributeTypes 140 Type name: attributeTypes 142 Type purpose: To represent the LDAPv3 attribute "attributeTypes", 143 defined in section 5.1.6 of [4]. 145 Type encoding: 8bit 147 Type valuetype: text, encoded according to the BNF of 148 "AttributeTypeDescription" given in section 4.2 of [4]. 150 Type special notes: Each value of the type specifies one LDAPv3 151 attribute type definition. The syntax and matching rules 152 referenced in a value of attributeTypes MUST either be present in 153 this content, or defined in one of the schemas referenced in the 154 "IMPORTS" field of the ldapSchemas line. 156 Intended usage: COMMON 158 5.3. matchingRules 160 To: ietf-mime-direct@imc.org 161 Subject: Registration of text/directory MIME type matchingRules 163 Type name: matchingRules 165 Type purpose: To represent the LDAPv3 attribute "matchingRules", 166 defined in section 5.1.8 of [4]. 168 Type encoding: 8bit 170 Type valuetype: text, encoded according to the BNF of 171 "MatchingRuleDescription" given in section 4.5 of [4]. 173 Type special notes: Each value of the type specifies one matching rule 174 definition. The syntax reference in a value of matchingRules MUST 175 either be present in this content, or defined in one of the schemas 176 referenced in the "IMPORTS" field of the ldapSchemas line. 178 Intended usage: COMMON 180 5.4. objectClasses 182 To: ietf-mime-direct@imc.org 183 Subject: Registration of text/directory MIME type objectClasses 185 Type name: objectClasses 187 Type purpose: To represent the LDAPv3 attribute "objectClasses", 188 defined in section 5.1.7 of [4]. 190 Type encoding: 8bit 192 Type valuetype: text, encoded according to the BNF of 193 "ObjectClassDescription" given in section 4.4 of [4]. 195 Type special notes: Each value of the type specifies one LDAPv3 196 object class definition. The attributes and object classes referenced 197 in a value of objectClasses MUST either be present in this content, 198 or defined in one of the schema referenced in the "IMPORTS" field 199 of the ldapSchemas line. 201 Intended usage: COMMON 203 5.5. matchingRuleUse 205 To: ietf-mime-direct@imc.org 206 Subject: Registration of text/directory MIME type matchingRuleUse 208 Type name: matchingRuleUse 210 Type purpose: To represent the LDAPv3 attribute "matchingRuleUse", 211 defined in section 5.1.9 of [4]. 213 Type encoding: 8bit 215 Type valuetype: text, encoded according to the BNF of 216 "MatchingRuleUseDescription" given in section 4.5 of [4]. 218 Type special notes: Each value of the type specifies a relationship 219 between a matching rule and attribute types. The matching rule and 220 attribute types referenced in a value of matchingRuleUse MUST either 221 be present in this content, or defined in one of the schemas 222 referenced in the "IMPORTS" statement of the ldapSchemas line. 224 Intended usage: COMMON 226 5.6. ldapSyntaxes 228 To: ietf-mime-direct@imc.org 229 Subject: Registration of text/directory MIME type ldapSyntaxes 231 Type name: ldapSyntaxes 233 Type purpose: To represent the LDAPv3 attribute "ldapSyntaxes", 234 defined in section 5.3.1 of [4]. 236 Type encoding: 8bit 238 Type valuetype: text, encoded according to the BNF of 239 "SyntaxDescription" given in section 4.3.3 of [4]. 241 Type special notes: Each value of this type specifies a single LDAPv3 242 attribute value syntax. 244 Intended usage: COMMON 246 5.7. schemaDesc 248 To: ietf-mime-direct@imc.org 249 Subject: Registration of text/directory MIME type schemaDesc 251 Type name: schemaDesc 253 Type purpose: To represent the LDAPv3 attribute "schemaDesc", 254 defined in section A.3 below. 256 Type encoding: 8bit 258 Type valuetype: text, encoded according to the BNF of section A.4. 260 Type special notes: Each value of this type specifies the descriptive 261 information associated with a schema. 263 Intended usage: COMMON 265 6. Example 267 From: Whomever@wherever.com 268 To: Someone@somewhere.com 269 Subject: schema information 270 MIME-Version: 1.0 271 Message-Id: 272 Content-Type: text/directory; profile="schema-ldap-0", charset="utf-8" 273 Content-Transfer-Encoding: Quoted-Printable 275 ldapSchemas: ( NAME 'bogus schema' CLASSES ( top $ thing ) = 276 ATTRIBUTES ( objectClass $ name ) SYNTAXES ( = 277 1.3.6.1.4.1.1466.115.121.1.38 $ 1.3.6.1.4.1.1466.115.121.1.15 ) ) 278 attributeTypes: ( 2.5.4.0 NAME 'objectClass' SYNTAX = 279 1.3.6.1.4.1.1466.115.121.1.38 ) 280 objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) 281 attributeTypes: ( 2.5.4.41 NAME 'name' SYNTAX = 282 1.3.6.1.4.1.1466.115.121.1.15{32768} ) 283 objectClasses: ( 2.5.6.999 NAME 'thing' MUST name ) 284 ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'String' ) 285 ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) 287 7. Security Considerations 289 A MIME body part containing an text/directory of the schema-ldap-0 290 profile may be incorporated in a digitally signed MIME content, which 291 can be used to verify that the body part has not been modified in 292 transit. When the signer has been certified by a trusted third party 293 service, it may also be possible to verify the origin of the content. 295 8. Bibliography 297 [1] "A MIME Content-Type for Directory Information", 07/24/1997, 298 INTERNET DRAFT . 300 [2] "Lightweight Directory Access Protocol (v3)", 08/21/1997, 301 INTERNET DRAFT . 303 [3] "Directory Schema Listing Requirements", 08/28/1997, 304 INTERNET DRAFT . 306 [4] "Lightweight Directory Access Protocol (v3): Attribute Syntax 307 Definitions", 08/21/1997, INTERNET DRAFT 308 . 310 [5] "The LDAP Data Interchange Format (LDIF) - Technical Specification", 311 07/25/1997, INTERNET DRAFT . 313 9. Authors Address 315 Mark Wahl 316 Critical Angle Inc. 317 4815 West Braker Lane #502-385 318 Austin, TX 78759 319 USA 321 Phone: +1 512 372-3160 322 EMail: M.Wahl@critical-angle.com 324 Appendix A 326 This appendix defines two new attributes which could be present in 327 an subschema entry. These attributes could be added to a future 328 revision of the LDAP attribute definition [4]. 330 A.1. ldapSchemas attribute type definition 332 ( 1.3.6.1.4.1.1466.101.120.17 NAME 'ldapSchemas' 333 SYNTAX 1.3.6.1.4.1.1466.115.121.1.56 USAGE directoryOperation ) 335 Each value of the ldapSchemas attribute defines one schema. Its 336 syntax, given in section A.2, contains the elements needed for an 337 LDAPv3 server to correctly process operations which use the 338 definitions from this syntax. 340 A.2. LDAP Schema Definition syntax definition 342 ( 1.3.6.1.4.1.1466.115.121.1.56 DESC 'LDAP Schema Definition' ) 344 Values in this syntax are represented according to the following BNF: 346 LdapSchema = "(" whsp 347 [numericoid whsp] 348 [ "NAME" qdescrs ] 349 [ "OBSOLETE" whsp ] 350 [ "IMPORTS" oids ] 351 [ "CLASSES" oids ] 352 [ "ATTRIBUTES" oids ] 353 [ "MATCHING-RULES" oids ] 354 [ "SYNTAXES" oids ] 355 whsp ")" 357 The numericoid field, if present, uniquely identifies the schema. A 358 new OID should be assigned if any of the fields of the schema change. 359 It is not possible to import definitions from a schema until an 360 OID has been assigned to it. 362 The "NAME" field contains optional human-readable labels for the 363 schema. 365 The "OBSOLETE" field is present if the schema is obsolete. 367 The "IMPORTS" field lists the OIDs of other schemas which are to be 368 incorporated by reference into this schema. It is an error to have 369 an attribute type or object class defined in a schema with the same 370 name but a different OID as an attribute type or object class in an 371 imported schema. It is also an error to import from two schema 372 definitions in which there are attribute types or object classes 373 with the same names but different OIDs. 375 The "CLASSES" field lists the OIDs of object classes defined in this 376 schema. A schema need not contain any object class definitions. A 377 schema must not contain two object class definitions of the same name 378 but with different OIDs. 380 The "ATTRIBUTES" field lists the OIDs of attribute types defined in 381 this schema. A schema need not contain any object class definitions. 382 A schema must not contain two attribute type definitions of the same 383 name but with different OIDs. 385 The "MATCHING-RULES" field lists the OIDs of matching rules defined 386 in this schema. A schema need not contain any matching rules. 388 The "SYNTAXES" field lists the OIDs of syntaxes defined in this schema. 389 A schema need not contain any matching rules. 391 A.3. schemaDesc attribute type description 393 ( 1.3.6.1.4.1.1466.101.120.18 NAME 'schemaDesc' 394 SYNTAX 1.3.6.1.4.1.1466.115.121.1.57 USAGE directoryOperation ) 396 The schemaDesc attribute associates descriptive and meta-data 397 information with a schema definition. This information conveyed 398 by this attribute is intended for use by readers of the schema and 399 by schema manipulation tools, and need not be interpreted by directory 400 servers. 402 A.4. Schema Description syntax definition 404 ( 1.3.6.1.4.1.1466.115.121.1.57 DESC 'LDAP Schema Description' ) 406 Values in this syntax are represented according to the following BNF: 408 SchemaInfo = "(" whsp 409 [numericoid whsp] 410 [ "DESC" qdstring ] 411 whsp ")" 413 Additional fields will be added in future versions of this document, 414 as required by the schema listing service.