idnits 2.17.1 draft-ietf-asid-schema-01.txt: 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-26) 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 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 a Security Considerations section. ** 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 103 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** 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 246: '... MUST CONTAIN {...' RFC 2119 keyword, line 254: '... MUST CONTAIN {...' RFC 2119 keyword, line 260: '... MAY CONTAIN {...' RFC 2119 keyword, line 276: '... MUST CONTAIN {...' RFC 2119 keyword, line 279: '... MAY CONTAIN {...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 16 has weird spacing: '...ment is an I...' == Line 17 has weird spacing: '...cuments of t...' == Line 18 has weird spacing: '...ups may also ...' == Line 22 has weird spacing: '... and may be...' == Line 23 has weird spacing: '...opriate to u...' == (98 more instances...) -- 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 (March 1995) is 10635 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 405 looks like a reference -- Missing reference section? '2' on line 408 looks like a reference -- Missing reference section? '5' on line 417 looks like a reference -- Missing reference section? '3' on line 411 looks like a reference -- Missing reference section? '4' on line 414 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ASID Working Group Glenn Mansfield 2 INTERNET DRAFT AIC Laboratories 3 draft-ietf-asid-schema-01.txt P.V. Rajeev 4 Hughes Software Systems 5 S. V. Raghavan 6 Indian Institute of Technology, Madras 7 Tim Howes 8 University of Michigan 10 March 1995 12 Schema Publishing in X.500 Directory 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 28 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 29 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 30 Rim). 32 Abstract 34 The X.500 directory provides a powerful mechanism for storing and 35 retrieving information about objects of interest. To interpret the 36 information stored in the directory, the schema must be known to all the 37 components of the directory. Presently, there are no means other than 38 ftp to distribute schema information across the Internet. This is 39 proving to be a severe constraint as the Directory is growing. This 40 document presents a solution to the schema distribution problem using 41 the existing mechanisms of the directory. A naming scheme for naming 42 schema objects and a meta-schema for storing schema objects is 43 presented. The procedures for fetching unknown schema from the directory 44 at runtime are described. 46 Contents 47 ======== 48 1. Introduction 3 49 2. Schema Management 3 50 3. Storage of Schema Information in the Directory 4 51 4. Retrieval of Schema from the Directory 5 52 5. The Meta-Schema 6 53 6. References 11 54 7. Authors' Addresses 11 56 1. Introduction 58 The X.500 Directory [1] is now used for a wide range of applications 59 from name/address lookup to network management, from restaurant 60 information to bibliographic information services. This information is 61 distributed and managed across a network of many autonomous sites. In 62 order to interpret the information stored in the directory, the 63 components of the directory must have knowledge about the structure and 64 representation (schema) of the information held within the directory. 66 The distributed nature of the network and the relatively slow process 67 of standardization have given rise to the challenging task of making 68 accessible the information about the schema rules themselves. A 69 mechanism for making the schema accessible to the functional components 70 of the directory is urgently required. 72 The 1993 X.500 Directory Standard [2] has attempted to address the 73 problem of schema management and distribution. The 1993 framework does 74 provide the means for storing and retrieving schema information in the 75 directory. But, the DUA procedure for looking up an unknown object by 76 OID, has not been discussed. 78 In this document we propose a solution using the existing mechanisms of 79 the directory [1] itself. We present a naming scheme for naming schema 80 objects and a meta-schema for storing schema objects in the directory. 81 The proposal allows the algorithmic resolution of unknown objects in the 82 directory and in the absence of 1993 X.500 Directory Standard 83 implementations provides an interim solution to the schema publishing 84 problem. 86 2. Schema Management: 88 The storage and retrieval mechanism provided by the directory is 89 powerful and flexible. However, the key to the directory is the 90 knowledge of the schema rules defined for the objects represented in the 91 directory. To facilitate the diffusion of this knowledge appropriate 92 schema management mechanisms need to be designed. Schema management 93 involves : 95 o Storage of schema information in the directory 96 o Algorithmic access to and retrieval of schema information 97 in the directory 98 o Definition of rules for schema modification 99 o Propagation of schema information from one component of the 100 directory to other components of directory 102 In this document we concentrate on the aspect of schema access/retrieval 103 from the directory. Since schema objects are defined and employed, the 104 modification , addition and deletion of schema objects can be carried 105 out using existing directory mechanisms. But the operational issue of 106 synchronizing the schema with the DIB will require further attention. 107 Similarly the issue of schema propagation requires further work and is 108 outside the scope of this document. The strategy proposed in this 109 document has a very simple and workable approach. No added DAP/DSP 110 functionality is envisaged. At the same time by using the directory's 111 distributed framework scalability problems are avoided. In essence, it 112 allows the distributed storage of schema objects and proposes a naming 113 scheme which allows algorithmic schema retrieval. Of course, on the down 114 side, more than one directory read operation may be required to 115 retrieve the information about an object and its attributes, as objects 116 and attributes are stored as separate entries in the directory. 118 As schema information of all objects in a naming context are stored 119 below the root entry of that naming context, the same DSA will be able 120 to supply the schema information stored in that DSA. Thus there is no 121 need to contact another DSA for resolving the schema of an object stored 122 in the local DSA. 124 3. Storage of Schema Information in the Directory 126 The schema information may be stored and distributed using mechanisms 127 external to the X.500 directory standard[5]. This document proposes 128 storing schema information in the directory. It has the following 129 advantages: 131 o The components of the directory can access the schema 132 information using the standard directory protocols. 134 o The nature of the directory naturally allows the schema 135 to be distributed. Schema used locally can be kept in the 136 local DSA itself whereas schema for general objects like 137 person, organization etc can be made available to all 138 components of the directory by publishing it. 140 In the operational model, the schema information in the directory is 141 expected to complement the schema information held in central 142 repositories. 144 3.1 Naming Scheme for the Schema 146 The schema information is stored in a distributed manner. We propose a 147 model in which each naming context stores the schema relevant to it. 148 Schema of objects which are commonly used will be stored in first 149 level DSAs and will be replicated to DSAs below. (This results in all 150 DSAs having a copy of the schema of objects that are commonly used.) 151 Schema defined in any naming context will be replicated to all 152 subordinate naming contexts. Thus a DSA at the lowest level will have a 153 replicated copy of schema stored in all its superior DSAs. Schema is 154 propagated to lower level DSAs, thus local schema will not be propagated 155 outside the naming context in which it is defined. 157 Root 158 \ 159 \ 160 +-------------\----------------------+ 161 | C=IN DSA-1 | 162 | / \ | 163 | / \ | 164 | / \ | 165 | / \ | 166 | / cn=subschema | 167 | / / / | \ \ \ | 168 | / / / | \ \ \ | 169 | / oid= oid= | 170 +--/---------------------------------+ 171 / 172 +----------------------/----------------------+ 173 | o=IIT, Madras DSA-2 | 174 | / \ | 175 | / \ | 176 | / \ | 177 | / \ | 178 | ou=CSE cn=subschema | 179 | / \ / /| \ \ \ | 180 | / \ / / | \ \ \ | 181 |ipni=spark cn=Rajeev oid=ipni oid= | 182 +---------------------------------------------+ 184 Figure 1: DIT with schema objects 186 To store the schema information, an object called subschema object is 187 defined. This object can come anywhere in the Directory Information Tree 188 (DIT). The subschema is defined as a subclass of Top. The subschema 189 entry is stored below the root entry of a naming context. The root entry 190 of a naming context must contain a subschema subentry, named {CN= 191 Subschema}. This standard naming methodology is necessary so that the 192 components of the directory can easily and algorithmically locate the 193 schema entries. All schema information relevant to that naming context 194 is stored below the subschema entry. Children of the subschema entry 195 store information about objects, attribute types, attribute syntaxes 196 or matching rules. The DIT structure for storing schema information is 197 shown in Figure 1. Schema for these objects are given in section 5. 199 4. Retrieval of Schema from the Directory 201 When an unknown object is encountered by any component of directory 202 during a directory operation, it proceeds the following way to resolve 203 the schema. 205 The RDN component at the leaf-end of the name of the object whose schema 206 is to be resolved is replaced by the RDNs "oid=, CN=subschema" and a read request is initiated for the newly 208 formed name. If the entry is not found, two RDN components from the 209 leaf-end of the name of the object are replaced by the RDNs "oid=, CN=subschema" and another read is 211 attempted. The process continues until the read succeeds. For example, 212 while resolving the schema of the object "IPNI=spark, OU=Department of 213 Computer Science, O=Indian Institute of Technology, Madras , C=IN", if 214 the schema of the object IPNI (IP Node Image) is not known to a 215 component of the directory, the following procedure will be adopted. 217 Let the object id for the object IPNI be ipni. The RDN "IPNI=spark" 218 is removed from the distinguished name of the entry and the RDNs 219 "oid=ipni, CN= Subschema" is appended. The name thus formed is 220 "oid=ipni, CN=subschema, OU=Department of Computer Science, O=Indian 221 Institute of Technology, Madras, C=IN" A read request is initiated on 222 this name. If the distinguished name "OU= Department of Computer 223 Science, O=Indian Institute of Technology, Madras, C=IN" is the context 224 prefix of a naming context, this read request will result in the 225 directory returning the schema for the object IPNI. If it is not, the 226 read operation will fail. In that case, a read operation is initiated 227 with distinguished name "oid=ipni, CN= subschema, O=Indian Institute of 228 Technology, Madras, C=IN". For the DIT structure shown in Figure-1, this 229 query will succeed and the schema information will be returned. The 230 schema for the requested object will always be located below the 231 starting entry of the naming context in which the entry is located. 233 5. The Meta-Schema. 235 schema OBJECT IDENTIFIER 236 ::= {experimental XX} -- XX will be assigned by IANA 238 schemaObjectClass OBJECT IDENTIFIER 239 ::= {schema.1} 241 schemaAttribute OBJECT IDENTIFIER 242 ::= {schema.2} 244 subschema OBJECT CLASS 245 Subclass of TOP 246 MUST CONTAIN { 247 commonName 248 - - For naming 249 } 250 ::= {schemaObjectClass.1} 252 objectClass OBJECT CLASS 253 Subclass of TOP 254 MUST CONTAIN { 255 objectIdentifier 256 - - This field stores the object identifier of object 257 - - represented by an object class entry. This attribute 258 - - is used for naming an object class entry. 259 } 260 MAY CONTAIN { 261 commonName, 262 - - This field is used to store the name of the object 264 mandatoryNamingAttributes, 265 mandatoryAttributes, 266 optionalNamingAttibutes, 267 optionalAttributes, 268 obsolete, 269 description, 270 subClassOf 271 } 272 ::= {schemaObjectClass.2} 274 attributeType OBJECT CLASS 275 Subclass of Top 276 MUST CONTAIN { 277 objectIdentifier 278 } 279 MAY CONTAIN { 280 commonName, 281 - - used to store the name of the attribute type 282 constraint, 283 attributeSyntax, 284 multivalued, 285 obsolete, 286 matchRules, 287 description 288 } 289 ::= {schemaObjectClass.3} 291 attributeSyntax OBJECT CLASS 292 Subclass of Top 293 MUST CONTAIN { 294 objectIdentifier 295 } 296 MAY CONTAIN { 297 commonName, - - Name of the attribute syntax 298 dataType, 299 description, 300 obsolete 301 } 302 ::= {schemaObjectClass.4} 304 matchingRule OBJECT CLASS 305 Subclass of Top 306 MUST CONTAIN { 307 objectIdentifier 308 } 309 MAY CONTAIN { 310 commonName, 311 matchtype, 312 description, 313 obsolete 314 } 315 ::= {schemaObjectClass.5} 317 objectIdentifier ATTRIBUTE 318 WITH ATTRIBUTE-SYNTAX 319 objectIdentifierSyntax 320 ::= {schemaAttribute.1} 322 mandatoryNamingAttributes ATTRIBUTE 323 WITH ATTRIBUTE-SYNTAX 324 SET OF OBJECT IDENTIFIER 325 ::= {schemaAttribute.2} 326 mandatoryAttributes ATTRIBUTE 327 WITH ATTRIBUTE-SYNTAX 328 SET OF OBJECT IDENTIFIER 329 ::= {schemaAttribute.3} 331 optionalNamingAttibutes ATTRIBUTE 332 WITH ATTRIBUTE-SYNTAX 333 SET OF OBJECT IDENTIFIER 334 ::= {schemaAttribute.4} 336 optionalAttibutes ATTRIBUTE 337 WITH ATTRIBUTE-SYNTAX 338 SET OF OBJECT IDENTIFIER 339 ::= {schemaAttribute.5} 341 obsolete ATTRIBUTE 342 WITH ATTRIBUTE-SYNTAX 343 BOOLEAN 344 -- DEFAULT FALSE 345 ::= {schemaAttribute.6} 347 subClassOf ATTRIBUTE 348 WITH ATTRIBUTE-SYNTAX 349 SET OF OBJECT IDENTIFIER 350 ::= {schemaAttribute.7} 352 constraint ATTRIBUTE 353 WITH ATTRIBUTE-SYNTAX 354 Constraint 355 ::= {schemaAttribute.8} 357 Constraint ::=Choice { 358 StringConstraint, 359 IntegerConstraint 360 } 362 StringConstraint ::= SEQUENCE { 363 shortest INTEGER, 364 longest INTEGER 365 } 367 IntegerConstraint ::= SEQUENCE { 368 lowerbound INTEGER, 369 upperbound INTEGER OPTIONAL 370 } 372 attributeSyntax ATTRIBUTE 373 WITH ATTRIBUTE-SYNTAX 374 OBJECT IDENTIFIER 375 ::= {schemaAttribute.9} 377 multivalued ATTRIBUTE 378 WITH ATTRIBUTE-SYNTAX 379 BOOLEAN -- DEFAULT FALSE 380 ::= {schemaAttribute.10} 382 matchRules ATTRIBUTE 383 WITH ATTRIBUTE-SYNTAX 384 SET OF OBJECT IDENTIFIER 385 ::= {schemaAttribute.11} 387 dataType ATTRIBUTE 388 WITH ATTRIBUTE-SYNTAX 389 ASN1DataType 390 ::= {schemaAttribute.12} 392 matchtype ATTRIBUTE 393 WITH ATTRIBUTE-SYNTAX 394 INTEGER { 395 PRESENT (0), 396 EQUALITY (1), 397 ORDERING (2), 398 CASESENSITIVEMATCH (3), 399 CASEINSENSITIVEMATCH (4) 400 } 401 ::= {schemaAttribute.13} 403 6. References. 405 [1] CCITT. "Data Communication Networks: Directory", 406 Recommendations X.500 - X.521 1988. 408 [2] CCITT. "Data Communication Networks: Directory", 409 Recommendations X.500 - X.525 1993. 411 [3] Barker, P., Kille, S., "The COSINE and Internet X.500 Schema", 412 RFC 1274, November 1991. 414 [4] Howes,T., "Schema Information in the X.500 Directory", Internet 415 Draft, University of Michigan, July 1992. 417 [5] Howes, T., Rossen, K., Sataluri, S., Wright, R., "Procedures for 418 Formalization, Evolution, and Maintenance of the Internet X.500 419 Directory Schema", work in progress, Internet-Draft, 420 draft-howes-x500-schema-00.txt, April, 1994. 422 7. Authors' Addresses. 424 Glenn Mansfield 425 AIC Systems Laboratories, 426 6-6-3, Minami Yoshinari, Aoba-Ku, Sendai, 427 Japan. 428 Phone: +81-22-279-3310. Fax: +81-22-279-3640 429 glenn@aic.co.jp 431 P. V. Rajeev 432 Hughes Software Systems, 433 2nd Floor, International Trade Tower, 434 Nehru Place, New Delhi, 435 India. 436 rajeev%hss@lando.hns.com 438 S. V. Raghavan 439 Department of Computer Science and Engineering, 440 Indian Institute of Technology, Madras 600 036, 441 India 442 svr@iitm.ernet.in 444 Tim Howes 445 University of Michigan 446 ITD Research Systems 447 535 W William St. 448 Ann Arbor, MI 48103-4943, USA 449 (313) 747-4454 450 tim@umich.edu