idnits 2.17.1 draft-howes-x500-schema-03.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-25) 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 an Introduction 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 1995) is 10542 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) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF X.500 Schema Task Force Tim Howes 2 INTERNET-DRAFT University of Michigan 3 Ken Rossen 4 SHL Systemhouse 5 Srinivas Sataluri 6 AT&T Bell Laboratories 7 Russ Wright 8 Lawrence Berkeley Laboratory 9 June 1995 11 Procedures for Formalizing, Evolving, and Maintaining 12 the Internet X.500 Directory Schema 13 Filename: draft-howes-x500-schema-03.txt 15 1. Status of this Memo 17 The goal of the X.500 schema task force is to specify a set of pro- 18 cedures for reviewing, publicizing, and maintaining schema elements for 19 use in Internet applications using OSI Directory Services (X.500). 21 This document is an Internet-Draft. Internet-Drafts are working docu- 22 ments of the Internet Engineering Task Force (IETF), its areas, and its 23 working groups. Note that other groups may also distribute working 24 documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months. 27 Internet-Drafts may be updated, replaced, or obsoleted by other docu- 28 ments at any time. It is not appropriate to use Internet-Drafts as 29 reference material or to cite them other than as a ``working draft'' or 30 ``work in progress.'' 32 To learn the current status of any Internet-Draft, please check the 33 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Direc- 34 tories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. 36 This Internet Draft expires December 10th, 1995. 38 Distribution of this memo is unlimited. Comments and critiques of this 39 document, and new or updated schema definitions should be sent to x500- 40 schema@internic.net. Discussion about the Internet X.500 schema should 41 be carried out on the OSI-DS mailing list (osi-ds@cs.ucl.ac.uk). 43 2. Abstract 45 The IETF Schema Task Force proposes a set of procedures for reviewing, 46 publicizing, and maintaining schema elements for use in Internet appli- 47 cations using OSI Directory Services (X.500). 49 3. Goals of the Internet Schema Procedures 51 The goals embodied in the procedures documented in this memo are four- 52 fold: 54 - To identify a repository and appropriate useful formats for publi- 55 cizing and distributing schema elements (object classes and attri- 56 butes) to the Internet community. 58 - To facilitate broad-based experimentation with new applications of 59 X.500 by publicizing experimental schema elements. 61 - To maintain a stable production schema for the Internet, including 62 definitions both for common core of elements and application- 63 specific subschemas 65 - To avoid the overlap of schema element functionality where possi- 66 ble. 68 4. Collection of Schema Elements 70 The Internet Directory Schema will evolve from the status quo as 71 represented in a forthcoming RFC documenting the current "baseline" 72 schema elements. This baseline is expected to include both those object 73 classes and attributes with applicability to a wide variety of applica- 74 tions (the Core Schema), and certain elements arising from specific 75 applications (subschemas), some of which have been developed in other 76 IETF WGs. 78 In general, within the IETF, the X.500 schema group will concern itself 79 with evolving the Core schema while encouraging application-specific 80 subschemas to be developed by experts in the respective applications. 82 The schema group aims to align schema element definitions where 83 appropriate between the Internet schema and others within the Directory 84 community. The publicizing of the Internet schema for external consump- 85 tion is one avenue for this, and consideration of schema elements docu- 86 mented in external sources is another. Two such external sources are: 88 - Standing documents of the North American Directory Forum 90 - "F" series International Standard Profiles (ISPs) for use of the 91 Directory, developed by the Regional Workshops (AOW, EWOS, OIW) and 92 published in ISO/IEC 10616. 94 5. Publication of Schema Elements 96 The schema group recognizes short-term and long-term mechanisms for dis- 97 tributing definitions of Internet schema elements. Both mechanisms 98 involve the use of the InterNIC Directory and Database Services as a 99 repository: 101 Short-term:Element definitions will be made available from the InterNIC 102 via anonymous ftp (ftp://ds.internic.net/pub/src/x500/schema), via 103 Gopher (gopher://ds.internic.net/1pub/src/x500/schema), and via the 104 WWW (http://www.internic.net/pub/src/x500/schema). The FTP archive 105 will include ASN.1 definitions accompanied by text describing the 106 semantics and use of each object class or attribute. In addition, 107 native formats for widely deployed X.500 implementations, particu- 108 larly the QUIPU OID Table format, will be included where practical. 110 Long-term:When 1993 schema publication extensions to the Directory stan- 111 dard are implemented widely in the Internet, these facilities will 112 be used to distribute element definitions from the InterNIC DSA. 113 If slow progress of deployment of schema publication extensions 114 impedes this transition, consideration will be given to defining a 115 1988-compatible directory schema for interim publication of schema 116 elements. In this case, a migration path to the 1993 format for 117 schema publication operational attributes will be a priority. 119 In addition to the on-line publicizing and maintainance of schema ele- 120 ments, an informational RFC documenting the Internet schema will be 121 issued on a six-month update cycle. This RFC will reflect the state of 122 the InterNIC schema repository at the time of publication. The publica- 123 tion of the current Internet X.500 Schema in the RFC will indicate that 124 the published version is baselined and an on-line copy of the published 125 schema will be held on the InterNIC schema repository. This version 126 will be available in the directory /pub/src/x500/schema.RFCxxxx on the 127 InterNIC machine(s) representing the baselined schema and the on-line 128 version will be in the directory /pub/src/x500/schema.RFC and will 129 represent the temporary evolving Internet X.500 schema. 131 Subschemas defined by other IETF WGs or external groups in the Directory 132 community should be submitted to the schema group for inclusion in the 133 on-line repository. However, these schema elements should be published 134 as RFCs using the regular RFC publication process. Once such RFCs are 135 published, the schema group will accept these definitions as stable and 136 will not reproduce them in the regularly updated schema RFC. Rather, 137 the schema RFC will contain pointers to documents produced by these 138 other groups which include the definitions. 140 Wherever possible, external groups will be encouraged to submit docu- 141 ments containing their subschemas for publication as RFCs, in order to 142 allow interested parties to derive the Internet schema entirely from a 143 reading of the X.500 standard and selected RFCs. 145 6. Procedures for Expanding the Internet Schema 147 The schema group will make available a template for submission of schema 148 elements for publication and consideration. The template, to be defined 149 in a later edition of this document, will request a definition for the 150 syntax of the object class or attribute, sufficient details on the 151 schema elements including information about the submitter, date of sub- 152 mission, mailing-list where discussion is being held, status of the 153 schema segment, etc. The template will be simple and will be processed 154 to produce an ASN.1 definition for the elements. 156 The completed template will be submitted by e-mail to the alias "x500- 157 schema@internic.net". 159 Advancement of an experimental schema element to production status will 160 follow a period of experimentation and acceptance by the submitting WG, 161 and acceptance by the schema group. In particular, authors who submit 162 new schema elements (initially assigned experimental classification) 163 will be expected to make a good faith effort to progress the schema 164 using appropriate working-groups and other standards procedures towards 165 an Internet standard. Results from the period of experimentation, schema 166 group and WG consensus will be the basis for decisions on advancement of 167 candidate subschemas. 169 If it becomes apparent that there is no active experimentation with an 170 experimental status schema element and/or no efforts to progress them as 171 Internet standards, the schema elements may be retired after appropriate 172 notification. 174 In some circumstances, more than one subschema aimed at addressing the 175 requirements of the same application may be developed. The schema group 176 will accept and publicize such overlapping subschemas as experimental. 177 However, only one competing schema proposal for an application will be 178 advanced by the schema group to production status. As with decisions on 179 advancement to production status, results from the period of experimen- 180 tation, schema group and WG consensus will be the basis for identifying 181 the preferred among competing subschemas. 183 7. Object Identifiers 185 The schema group does not aim to align all Internet schema elements 186 under a single OID arc. It is appropriate for other groups already hav- 187 ing registered attributes and object classes under their own respective 188 OID arcs to retain ownership of those definitions, and advancement of 189 schema elements from experimental to production status does not imply a 190 change of OID. The schema group will advance the registration process 191 under an Internet arc for elements defined by external groups not wish- 192 ing to maintain OIDs in the long term. 194 8. Security Considerations 196 Security considerations are not discussed in this memo. 198 9. Authors' Addresses 200 Tim Howes 201 University of Michigan 202 ITD Research Systems 203 535 W William St. 204 Ann Arbor, MI 48103-4943, USA 205 (313) 747-4454 206 tim@umich.edu 208 Ken Rossen 209 SHL Systemhouse 210 10 Williamsville Road 211 Hubbardston Center, MA 212 01452-1311 USA 213 +1 508 928 5368 (voice) 5399 (fax) 5116 (alt fax) 214 kenr@shl.com 216 Srinivas R. Sataluri 217 AT&T Bell Laboratories 218 Room 1C-429, 101 Crawfords Corner Road 219 P.O. Box 3030 220 Holmdel, NJ 07733-3030, USA 221 (908) 949-7782 222 sri@qsun.att.com 224 Russ Wright 225 Lawrence Berkeley Laboratory 226 1 Cyclotron Road 227 Mail Stop 50B-2258 228 Berkeley, CA 94720, USA 229 (510) 486-6965 230 wright@lbl.gov 232 This Internet Draft expires December 10th, 1995.