idnits 2.17.1 draft-ietf-schema-file-list-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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (21 April 1998) is 9502 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: 'RFC2256' is mentioned on line 70, but not defined ** Obsolete undefined reference: RFC 2256 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) == Missing Reference: 'MIME' is mentioned on line 92, but not defined == Unused Reference: 'RFC1630' is defined on line 276, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'MIMEDIR' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 1630 ** Downref: Normative reference to an Historic RFC: RFC 1835 ** Obsolete normative reference: RFC 1714 (Obsoleted by RFC 2167) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT C. Apple 3 AT&T Labs 4 Expires: October 21, 1998 21 April 1998 6 Directory Schema Listing File Names 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), or ftp.isi.edu (US West Coast). 26 Abstract 28 This memo specifies a file name syntax for use by the primary listing 29 repository operator of the directory schema listing service. 31 1.0 Introduction 33 The fastest route to interoperable directory services is through 34 standard object classes and attribute types. There is a growing 35 number of places where schema for Internet Directory Services and 36 Internet Operations are being defined, with varying degrees of 37 documentation. This plethora of schema is unavoidable in the light 38 of the needs of different service communities, but makes it difficult 39 for directory service builders to find and make use of an existing 40 schema that will serve their needs and increase interoperability with 41 other systems. A listing service providing a single point of 42 discovery for directory service schema will promote schema reuse, 43 reduce duplication of effort, and thus promote directory service 44 interoperability. Schema listings will be stored in multiple files 45 based on the different types of information associated with a 46 listing: meta data and one or more syntax specifications. 48 1.1 Scope 50 A file name syntax specification intended for use during the initial 51 release of a directory schema listing service is inside the scope of 52 this document. 54 1.2 Terms and Definitions 56 Information Object - a descriptive abstraction of some real-world object 58 Object Attribute - a descriptive property of an information object; 59 typically, object attributes are defined in terms of semantic and 60 syntactic definitions 62 Schema - a collection of definitions for related information objects 64 Schema Unit - a related or grouped set of object attributes that form a 65 discrete unit within the context of a schema for a particular protocol; 66 examples include an LDAP object class or a WHOIS++ template 68 Schema Pak - a related or grouped set of schema units that collectively 69 specify a schema associated with a particular protocol; an example of a 70 schema pak is the set of LDAP object classes specified in [RFC2256] 72 Metadata - characteristics that differentiate one schema unit or schema 73 pak from another; used to catalog listing service content; structured 74 using a profile of [MIMEDIR]; also contains references to files stored 75 within and outside of a listing repository 77 Schema Unit Content - a formal specification of a schema unit using a 78 profile of [MIMEDIR] 80 Schema Unit Listing - the combination of a single schema unit content 81 file intended for use within the context of a particular protocol and a 82 file containing metadata describing the schema unit specified within 83 that schema unit content file 85 Schema Pak Listing - a single metadata file containing information 86 describing and referring to a set of related or grouped schema unit 87 content files 89 Repository - a database in which listings are stored 91 Listing Request - a proposed schema unit listing or schema pak listing 92 formatted using [MIME] constructs that is submitted for consideration as 93 a listing to be published in a repository 95 Operator - an organization that administers and maintains a repository 96 Primary Repository - the repository that masters the schema listings 97 database 99 Shadow Repository - a repository that mirrors the primary repository 101 Contact Person - the name of the individual who holds the authority to 102 update a listing and who should be contacted if questions or concerns 103 arise related to a listing or listing request 105 Listing Authority Contact - the name of the individual who holds 106 authority to replace a contact person; can be either the contact person 107 for a listing or an alternate contact within the organization to which 108 the contact person belongs (this allows one person organizations to list 109 schema) 111 The terms for specifying requirement level defined in [RFC2119] are used 112 in this document. 114 2.0 File Name Syntax 116 All file names for listing meta data and listing content MUST comply 117 with the following BNF [RFC822] grammar: 119 file-name = sequence "." listversion "." type 121 sequence = ("0" / "current") / NZDIGIT 0* 122 ; initialized to one (1) for first schema listing 123 ; increments by one (1) for each successive schema 124 ; listing name 126 type = "meta-unit" / ; these values are defined 127 "ldap" / ; for the initial release of the 128 "pak-ldap" / ; schema listing service 129 "whois++" / 130 "pak-whois++" / ; other values may be defined 131 "rwhois" / ; according to community needs in 132 "pak-rwhois" / ; the future 133 "whois" / 134 "pak-whois" ; this document will be updated or 135 ; obsoleted when additional 136 ; values are defined 138 listversion = 1* 139 NZDIGIT = 141 DIGIT = 143 Other possible values of the type component of a file name MAY be 144 defined in the future to accomodate schema listings specified using 145 [MIMEDIR] profiles other than those defined for containing LDAP 146 [RFC2251], WHOIS++ [RFC1835], and RWHOIS [RFC1714] schema listing 147 content. 149 3.0 Intended Use of File Names 151 Schema writers, implementors, and users of the schema listing service 152 SHOULD make use of the form of file names which includes descriptive 153 alphabetic tokens as the value for the part of a file name. 155 Filenames MAY be specified as an OID by prepending the OID value used 156 as a root for the service filename and swapping alphabetic tokens for 157 their numeric equivalent according to the following table: 159 Token Number 160 ----------- ------ 161 current 0 162 meta-unit 0 163 ldap 1 164 pak-ldap 2 165 whoispp 3 166 pak-whoispp 4 167 rwhois 5 168 pak-rwhois 6 169 whois 7 170 pak-whois 8 172 For the initial release of the service the behaviors documented in 173 Section 4.0 for file retrieval based on file name will be supported. 174 Schema writers, implementors, and users of the schema listing service 175 SHOULD NOT rely on future support of such file retrieval behavior for 176 the file name examples that are missing alphabetic tokens. 178 The behavior of file retrieval based on file names containing 179 alphabetic tokens MUST be preserved permanently by the schema listing 180 repository operators. 182 4.0 Example File Names 183 Generally, file names will be of the following form: 185 "sequence.listversion.type" 187 The 'sequence' part of a file name consists of a serial number 188 generated by the primary listing repository operator and is unique 189 within the context of the schema listing service. 191 When referring to a listing, a 'listversion' of "0" always represents 192 the most current version (the highest current listversion number) 193 published in the repository. Alternately, the token "current" may be 194 used to request the most current version of a listing file. 195 Otherwise, the listversion part of a file name represents the version 196 number of a listing within the context of the schema listing service. 198 The 'type' part of a file name consists of a token or number 199 representing a file type. This token is unique within the context of 200 the schema listing service and reflects the nature of file content. 202 If an OID is used to retrieve a file, the base OID used by the 203 primary listing repository operator MUST be prepended to the numeric 204 representation of the filename. 206 Retrieval of files will exhibit the following behavior for the 207 initial release of the service (NOTE: a value of 1 is used as the 208 base OID in these examples, the real base OID will be different): 210 1.12.4.0: returns schema unit metadata for version 4 of listing 12. 212 12.4.meta-unit: returns schema unit metadata for version 4 of listing 213 12 215 1.12.0.0: returns schema unit metadata for latest version of listing 216 12 218 12.current.meta-unit: returns schema unit metadata for latest version 219 of listing 12 221 1.12.4.1: returns ldap schema unit content for version 4 of listing 222 12 224 12.4.ldap: returns ldap schema unit content for version 4 of listing 225 12 227 1.12.0.1: returns ldap schema unit content for latest version of 228 listing 12 229 12.current.ldap: returns ldap schema unit content for latest version 230 of listing 12 232 1.13.2.2: returns metadata for version 4 of listing 12 234 13.2.pak-ldap: returns ldap schema pak metadata for version 2 of 235 listing 13 237 1.13.0.2: returns ldap schema pak metadata for latest version of 238 listing 13 240 13.current.pak-ldap: returns ldap schema pak metadata for latest 241 version of listing 13 243 5.0 Security Considerations 245 There are no known security concerns associated with the file name 246 syntax specified in this document. 248 6.0 Acknowledgements 250 Leslie Daigle of Bunyip Information Systems reviewed and provided 251 valuable comments on the syntax specification content in this 252 document. 254 The schema listing service engineering team: 256 Chris Apple - AT&T Labs 257 Sanjay Sain - Oracle 258 Michael Mealling - NSI 259 John Strassner - Cisco 260 Sam Sun - CNRI 261 Mark Wahl - Critical Angle 262 Chris Weider - Microsoft 264 Paul Hoffman for review and comment resulting from his effort to 265 develop a platform for the initial release of the listing service. 267 7.0 References 269 [MIMEDIR] T. Howes, M. Smith, "A MIME Content-Type for Directory 270 Information", INTERNET-DRAFT , 271 November 1997. 273 [RFC822] D. Crocker, "Standard of the Format of ARPA-Internet Text 274 Messages", STD 11, RFC 822, August 1982. 276 [RFC1630] T. Berners-Lee, "Universal Resource Identifiers in WWW", 277 RFC 1630, June 1994. 279 [RFC1835] P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider, 280 "Architecture of the WHOIS++ Service", RFC 1835, August, 1995. 282 [RFC1714] S. Williamson, M. Kosters,"Referral Whois Protocol 283 (RWhois)", RFC 1714, November 1994 285 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 286 Requirement Level", RFC 2119, March 1997. 288 [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 289 Protocol (Version 3)", RFC 2251, December 1997. 291 8.0 Author's Address 293 Chris Apple 294 AT&T Labs 295 600 - 700 Mountain Ave., Room 2F-165 296 Murray Hill, NJ 07974-0636 297 USA 299 E-Mail: capple@att.com 300 Phone: +1 908 582 2409 301 FAX: +1 908 582 3296 303 This INTERNET-DRAFT expires on October 21, 1998.