idnits 2.17.1 draft-ietf-schema-proc-list-00.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-24) 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 11 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** 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 213: '...ma unit listings MUST include two diff...' RFC 2119 keyword, line 222: '...ema unit content MUST be limited to th...' RFC 2119 keyword, line 227: '... All listings MUST have a valid OID ...' RFC 2119 keyword, line 229: '...ository operator MUST provide schema w...' RFC 2119 keyword, line 243: '... All listings MUST employ a common d...' (39 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An analysis of security issues for listed schema SHOULD be performed prior to submitting a listing request. However, regardless of what security analysis has or has not been done, all descriptions of security issues MUST be as accurate as possible. In particular, a statement that there are "no security issues associated with this type" MUST not be confused with "the security issues associates with this type have not been assessed". -- 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 (31 January 1998) is 9580 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: 'RFC225X' is mentioned on line 111, but not defined == Missing Reference: 'MIMEDIR' is mentioned on line 566, but not defined == Missing Reference: 'MIME' is mentioned on line 133, but not defined == Missing Reference: 'RFC2119' is mentioned on line 154, but not defined == Missing Reference: 'MIMEXML' is mentioned on line 383, but not defined == Unused Reference: 'FILESYN' is defined on line 660, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FILESYN' -- Possible downref: Non-RFC (?) normative reference: ref. 'LISTRQMT' -- Possible downref: Non-RFC (?) normative reference: ref. 'METASYN' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIMELDAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIMEWHOISPP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIMEWHOIS' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIMERWHOIS' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIMERXML' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2223 (Obsoleted by RFC 7322) Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 11 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: July 31, 1998 M. Mealling 5 Network Solutions, Inc. 6 31 January 1998 8 Directory Schema Listing Procedures 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 25 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 This memo documents procedures for listing directory service schemas 32 in a centrally operated, administered, and maintained repository. 33 This repository will be available as a resource to directory protocol 34 and service implementors to facilitate schema discovery. 36 Table of Contents 38 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 39 1.1 Terms and Definitions. . . . . . . . . . . . . . . . . . . . 3 40 2.0 Directory Schema Listing . . . . . . . . . . . . . . . . . . 5 41 2.1 Schema Listing Request Architecture Diagram. . . . . . . . . 5 42 2.2 Listing Requirements . . . . . . . . . . . . . . . . . . . . 6 43 2.2.1 Functionality Requirements . . . . . . . . . . . . . . . . 6 44 2.2.2 Naming Requirements. . . . . . . . . . . . . . . . . . . . 6 45 2.2.3 Content Formatting and Transfer Encoding Requirements. . . 6 46 2.2.4 Security Requirements. . . . . . . . . . . . . . . . . . . 7 47 2.2.5 Usage and Implementation Non-requirements. . . . . . . . . 8 48 2.2.6 Publication Requirements . . . . . . . . . . . . . . . . . 8 49 2.3 Listing Procedure. . . . . . . . . . . . . . . . . . . . . . 9 50 2.3.1 Announcement and Community Review. . . . . . . . . . . . . 9 51 2.3.2 Community Review and Assessment. . . . . . . . . . . . . . 10 52 2.3.3 Primary Repository Operator Listing. . . . . . . . . . . . 10 53 2.4 Comments on Schema Listings. . . . . . . . . . . . . . . . . 10 54 2.5 Location of List of Available Schema . . . . . . . . . . . . 10 55 2.6 Primary Repository Operator Procedures for Listing Schemas . 10 56 2.7 Change Control . . . . . . . . . . . . . . . . . . . . . . . 12 57 2.8 Listing Request Formats. . . . . . . . . . . . . . . . . . . 13 58 2.8.1 Schema Unit Listing Request Format . . . . . . . . . . . . 13 59 2.8.2 Schema Pak Listing Request Format. . . . . . . . . . . . . 14 60 2.9 Primary Repository Operator Responsibilities and Constraints 14 61 3.0 Security Considerations. . . . . . . . . . . . . . . . . . . 14 62 4.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 63 5.0 References . . . . . . . . . . . . . . . . . . . . . . . . . 15 64 6.0 Authors' Address . . . . . . . . . . . . . . . . . . . . . . 16 66 1.0 Introduction 68 There is a growing number of places where schema for Internet 69 Directory Services are being defined, with varying degrees of 70 documentation. This plethora of schemas is unavoidable in the light 71 of the needs of different service communities, but it makes it 72 difficult for directory service builders to find and make use of an 73 existing schema that will serve their needs and increase 74 interoperability with other systems. A listing service providing a 75 single point of discovery for directory service schema will promote 76 schema reuse, reduce duplication of effort, and thus promote 77 directory service interoperability. Listed schema will be assiged a 78 permanent, unique listing listing name as a part of the creating 79 schema listing requests; which starts the schema listing process. 80 This listing process was defined to ensure that directory service 81 schema writers can publish their schema in a public forum so that 82 they will be re-used. 84 The IETF schema listing service has public read access and 85 restricted, moderated write access. Currently, this listing service 86 is centrally operated, administered, and maintained by TBD. The 87 schema listing repository is mirrored to ensure some level of 88 redundancy for read access. 90 This document defines schema listing procedures which use TBD as the 91 primary listing repository operator. 93 1.1 Terms and Definitions 95 Information Object - a descriptive abstraction of some real-world 96 object 98 Object Attribute - a descriptive property of an information object; 99 typically, object attributes are defined in terms of semantic and 100 syntactic definitions 102 Schema - a collection of definitions for related information objects 104 Schema Unit - a related or grouped set of object attributes that form 105 a discrete unit within the context of a schema for a particular 106 protocol; examples include an LDAP object class or a WHOIS++ template 108 Schema Pak - a related or grouped set of schema units that 109 collectively specify a schema associated with a particular protocol; 110 an example of a schema pak is the set of LDAP object classes 111 specified in [RFC225X] 113 Metadata - characteristics that differentiate one schema unit or 114 schema pak from another; used to catalog listing service content; 115 structured using a profile of [MIMEDIR]; also contains references to 116 files stored within and outside of a listing repository 118 Schema Unit Content - a formal specification of a schema unit using a 119 profile of [MIMEDIR] 121 Schema Unit Listing - the combination of a single schema unit content 122 file intended for use within the context of a particular protocol and 123 a file containing metadata describing the schema unit specified 124 within that schema unit content file 126 Schema Pak Listing - a single metadata file containing information 127 describing and referring to a set of related or grouped schema unit 128 content files 130 Repository - a database in which listings are stored 132 Listing Request - a proposed schema unit listing or schema pak 133 listing formatted using [MIME] constructs that is submitted for 134 consideration as a listing to be published in a repository 136 Operator - an organization that administers and maintains a 137 repository 139 Primary Repository - the repository that masters the schema listings 140 database 142 Shadow Repository - a repository that mirrors the primary repository 144 Contact Person - the name of the individual who holds the authority 145 to update a listing and who should be contacted if questions or 146 concerns arise related to a listing or listing request 148 Listing Authority Contact - the name of the individual who holds 149 authority to replace a contact person; can be either the contact 150 person for a listing or an alternate contact within the organization 151 to which the contact person belongs (this allows one person 152 organizations to list schema) 154 The terms for specifying requirement level defined in [RFC2119] are 155 used in this document. 157 2.0 Directory Schema Listing 159 2.1 Schema Listing Request Architecture Diagram 161 Schema Writer 162 | <-----------------schema listing request with 163 | a permanent, unique listing 164 | name obtained from the primary 165 V repository operator 166 Schema Listing Request Review List 167 | 168 V 169 +-----------------------+ 170 |Significant objections | YES 171 |raised within 2 weeks? |----> Back to the drawing board.... 172 +-----------------------+ 173 | NO (List Moderator recommends that listing 174 Schema Listing-->| be published subject to comments on list.) 175 Request V 176 +-----------------+ 177 |Request meets | NO 178 |all requirements?| ----> Back to the drawing board.... 179 +-----------------+ 180 | YES 181 | <-----------------metadata/listing content 182 V 183 Repository Mirroring Agent 184 | | ... | 185 V V V 186 +----------+ +----------+ +----------+ 187 |Repository| |Repository| |Repository| where: 1 is the primary 188 | 1 | | 2 | | n | 2..n are replicas 189 +----------+ +----------+ +----------+ 191 Listing of a new schema starts with the construction of a listing 192 request. Schema writers obtain a unique listing name and include it 193 in the schema listing request sent to a moderated request review 194 list. Following a comment period of 2 weeks, if no significant 195 objections are raised (determined by the moderator), the moderator 196 sends the listing request to the primary listing repository operator, 197 subject to incorporation of relevant comments by the schema writer. 198 Listing requests are checked to verify compliance with the 199 requirements and conditions discussed below and the listing will be 200 published in the primary listing repository if appropriate. A 201 mirroring agent replicates the new listing across the primary and 202 mirrored copies of the listing repository database. 204 The following sections describe the requirements and procedure. 206 2.2 Listing Requirements 208 Listing requests are all expected to conform to various requirements 209 laid out in the following sections. 211 2.2.1 Functionality Requirements 213 Schema unit listings MUST include two different types of information: 215 (1) metadata 217 (2) schema unit content 219 Metadata will be used to catalog repository files by characteristics 220 that differentiate listings. 222 Schema unit content MUST be limited to the specification of a single 223 schema unit. 225 2.2.2 Naming Requirements 227 All listings MUST have a valid OID as their name. 229 The primary listing repository operator MUST provide schema writers 230 with a name for each listing request based on the combination of 232 + a root OID obtained from IANA specifically 233 for use in the schema listing service 235 + a sequence number assigned to each 236 listing by the primary repository operator 238 + a version number assigned to each 239 listing by the primary repository operator 241 2.2.3 Content Formatting and Transfer Encoding Requirements 243 All listings MUST employ a common data format. 245 Metadata and schema unit content format and transfer encoding MUST 246 utilize appropriate [MIMEDIR] profiles. 248 Currently, six [MIMEDIR] profiles have been defined for use in the 249 schema listing service: 251 [MIMELDAP] MUST be used to format and encode LDAPv3 schema unit 252 content. 254 [MIMEWHOISPP] MUST be used to format and encode WHOIS++ schema 255 unit content. 257 [MIMEWHOIS] MUST be used to format and encode WHOIS schema unit 258 content. 260 [MIMERWHOIS] MUST be used to format and encode RWHOIS schema unit 261 content. 263 [MIMEXML] MUST be used to format and encode XML schema unit 264 content. 266 [METASYN] MUST be used to format and encode metadata for all 267 schema unit listings, schema pak listings, and listing requests. 269 Other [MIMEDIR] profiles MAY be defined for use in the schema listing 270 service; this procedures document will be updated reflect such 271 changes. 273 2.2.4 Security Requirements 275 An analysis of security issues for listed schema SHOULD be performed 276 prior to submitting a listing request. However, regardless of what 277 security analysis has or has not been done, all descriptions of 278 security issues MUST be as accurate as possible. In particular, a 279 statement that there are "no security issues associated with this 280 type" MUST not be confused with "the security issues associates with 281 this type have not been assessed". 283 There is absolutely NO REQUIREMENT that listed schema be secure or 284 completely free from risks. Nevertheless, all known security risks 285 SHOULD be identified in the listing request. 287 The security considerations section of all requests is subject to 288 continuing evaluation and modification, and in particular MAY be 289 extended by use of the "comments on schema listings" mechanism 290 described in subsequent sections. 292 Some of the issues that SHOULD be looked at in a security analysis of 293 a schema listing are: 295 (1) A listing might include specifications mandating 296 exposure of certain attributes which would result in 297 compromising the privacy of an organization or 298 individual. 300 (2) A listing might be intended for use by 301 applications requiring some sort of security 302 assurances not provided by the schema specified 303 in the schema unit content or in the schema unit 304 content files referenced in a schema pak listing. 306 2.2.5 Usage and Implementation Non-requirements 308 In the directory services environment, where information on the 309 embedded schema knowledge of a directory client is frequently not 310 available to a server, maximum interoperability is attained by 311 restricting the schema used to those agreed upon by the large 312 community of directory service technology developers and users. This 313 was asserted in the past as a reason to limit the number of possible 314 schema to one via standards processes and resulted in a change 315 process with a significant hurdle and delay for those seeking to 316 modify and extend standard schema to better suite their needs. 317 Eventually, various individuals and organizations began using non- 318 standard schema, making interoperability difficult to achieve. 320 The need for "common" or "meta" schema listings does not require 321 limiting the publication of new listings. If a set of schema unit 322 listings is recommended for a particular application, that should be 323 asserted by an intended use statement specific for that application 324 and/or environment withing a schema pak listing metadata file. If a 325 set of schema pak listings is recommended for a particular 326 application, that should be asserted by a separate intended use 327 statement specific for the application and/or environment; or an 328 additional schema pak listing containing references to all of the 329 relevant schema unit listings should be created, reviewed, and 330 published. 332 As such, universal support and implementation of a schema is NOT a 333 requirement for listing it. If, however, a schema is explicitly 334 intended for limited use, this should be noted in its listing(s). 336 2.2.6 Publication Requirements 338 Requests for schema listed in the IETF schema listing service MAY be 339 published as RFCs. The primary listing repository operator will 340 retain copies of all schema listing requests that meet the 341 requirements specified below and "publish" them as part of the schema 342 listing repository. 344 The listing of a schema does not imply endorsement, approval, or 345 recommendation by the IETF or even certification that the 346 specification is adequate for the intended use of the schema. To 347 become Internet Standards, protocol, data objects, or whatever must 348 go through the IETF standards process. This is too difficult and too 349 lengthy a process for the convenient listing of schema. 351 It is expected that applicability statements for particular 352 applications will be published from time to time that recommend 353 implementation of, and support for, schema that have proven 354 particularly useful in those contexts. 356 2.3 Listing Procedure 358 The following procedure has been implemented by the primary listing 359 repository operator for review and approval of new listings. This is 360 not a formal standards process, but rather an administrative 361 procedure intended to foster re-use of directory services schema and 362 to provide a method for collecting schema in a publicly accessible 363 repository. 365 Submitting listing requests can be done via mail, treating posting of 366 a formatted request containing the specification of schema unit 367 content for a particular protocol and/or metadata to the ietf- 368 schema-review@TBD list, as a first step. 370 2.3.1 Announcement and Community Review 372 While listed schema are NOT REQUIRED to be published as RFCs, listing 373 requests documenting them MUST be posted to the ietf-schema- 374 review@TBD list, allowing a review and comment period of at least 2 375 weeks. This is necessary to prevent the malicious as well as 376 unintended introduction of obviously bogus or frivolous schema into 377 the listing repository. 379 Schema writers wishing to have their schema listed by the primary 380 listing repository operator, MUST specify any such schema (may 381 require the creation/submission of more than one request) according 382 to one of the following [MIMEDIR] profiles: [MIMELDAP], 383 [MIMEWHOISPP], [MIMEWHOIS], [MIMERWHOIS], or [MIMEXML]. Other such 384 profiles may be defined elsewhere and this procedures document will 385 be update to reflect such process changes. 387 Metadata, as specified in [METASYN], MUST also be included in this 388 request. A template for listing requests is specified in paragraph 389 2.8. Schema writers MUST use this template. 391 Schema writers MUST also obtain a unique listing name for each 392 request being constructed. The method of obtaining such listing names 393 is TBD. 395 Once constructed, the request should be sent to ietf-schema- 396 review@TBD. 398 2.3.2 Community Review and Assessment 400 Moderated discussions on the ietf-schema-review@TBD mailing list will 401 enable a means of gauging concensus as to whether or not the schema 402 being proposed is bogus. If there is no significant reason to believe 403 that a schema is useful or if it appears to be a bogus or malicious 404 request, the moderator will not submit a listing request to the 405 primary listing repository operator; otherwise, they may do so. 407 2.3.3 Primary Repository Operator Listing 409 Provided that the schema listing request meets the requirements 410 defined in paragraph 2.1, the ietf-schema-review@TBD list moderator 411 will send that listing request to the primary repository operator, 412 which will check this listing request for validity, and make the 413 listing available to the community. 415 2.4 Comments on Schema Listings 417 Comments on listings may be submitted by members of the IETF 418 community to for consideration by the rest of the community and the 419 primary listing repository operator. These comments will be passed on 420 to the contact person for the listing if possible. Submitters of 421 comments may request that their comment be attached to the listing 422 itself. If the ietf-schema-review@TBD list moderator is able to gauge 423 concensus affirming the inclusion of such a comment, it will be made 424 accessible in conjunction with the listing itself. 426 2.5 Location of List of Available Schema 428 Listings will be posted in the anonymous FTP directory 429 "ftp://TBD.host.name/schema/" and all listings will be summarized in 430 a periodically issued RFC. Schema unit content, schema pak listings, 431 and/or other supporting material may also be published as an 432 Informational RFC by sending it to "rfc-editor@isi.edu" (please 433 follow the instructions to RFC authors [RFC2223]). 435 2.6 Primary Repository Operator Procedures for Listing Schemas 437 Listings will be published by the primary repository operator 438 automatically and without any formal review as long as the following 439 minimal conditions are met: 441 (1) All listings MUST have a valid OID as their name. 443 (2) All schema unit listing requests MUST include both 444 metadata and schema unit content. 446 (3) All schema pak listing requests MUST be limited to 447 metadata. 449 (4) Metadata MUST comply with [METASYN]. 451 (5) Schema unit content MUST be compliant with at one 452 of the following [MIMEDIR] profiles: 454 + [MIMELDAP] (for LDAPv3 schema specifications) 455 + [MIMEWHOISPP] (for WHOIS++ schema specifications) 456 + [MIMEWHOIS] (for WHOIS schema specifications) 457 + [MIMERWHOIS] (for RWHOIS schema specifications) 458 + [MIMERXML] (for XML schema specifications) 460 Other [MIMEDIR] profiles may be defined in the future and this 461 document will be updated to reflect such additional profiles. 463 (6) Any security considerations given must not be obviously 464 bogus. It is neither possible nor necessary for the 465 primary listing repository operator to conduct a 466 comprehensive security review of listings. 467 However, the listing request review committee 468 (the members of the listing request review 469 mailing list) has the authority and expertise 470 to identify obviously incompetent material 471 and exclude it. 473 (7) Schema listing requests MAY be signed using PGP/MIME 474 as described in [RFC2015]. The primary listing repository 475 operator MUST be able to accept listing requests 476 in PGP/MIME messages, although they are NOT REQUIRED 477 to validate or retain the signatures. 479 (8) Listing request MUST be formatted according to 480 paragraph 2.8. 482 (9) If a listing request includes one or more 483 URI-based references to information that would not be 484 included in a resulting listing, but is associated with 485 the schema or schema unit specified by the request, 486 a fingerprint of this information MUST be included with 487 each such reference as specified in [METASYN]. The schema 488 writer MUST also include a special caveat metadata element 489 (as specified in [METASYN]) if at least one such 490 reference is included in the request. 492 2.7 Change Control 494 Once a listing has been published by the primary repository operator, 495 the contact person may request a change to its definition. The 496 contact person for a listed schema is defined to be the person or 497 organizational role or entity who submitted the original listing 498 request. 500 The change request follows the same procedure as the listing request 502 (1) Publish the revised listing request on the 503 ietf-schema-review@TBD list. 505 (2) Leave at least two weeks for comments. 507 (3) Publish using the primary listing repository 508 operator after formal review if required. 510 Changes MAY be requested when there are serious omissions or errors 511 in the published listing or when other factors which would justify a 512 change request, such as an emerging need of the user community for a 513 listed schema which cannot be addressed by that listed schema in its 514 present form. When review is required, a change request MAY be denied 515 if it renders entities that were valid under the previous definition 516 invalid under the new definition. 518 The primary listing repository provider SHOULD attempt to verify the 519 authority of a person claiming to be the contact for a listing, prior 520 to implementing such changes. 522 The contact person for a listing MAY pass responsibility for that 523 listing to another person or agency by informing the primary listing 524 repository operator and the ietf-schema-announce@TBD list; this can 525 be done without discussion or review. 527 The IESG may reassign responsibility for a listing. The most common 528 case of this will be to enable changes to be made to types where the 529 contact person for the listing has died, moved out of contact, or is 530 otherwise unable to make changes that are important to the community. 532 Listings will not be deleted; listings which are no longer believed 533 appropriate for use can be declared OBSOLETE by a change to their 534 "intended use" field; such listings will be clearly marked in 535 repository content summary RFCs published by the primary listing 536 repository operator. 538 2.8 Listing Request Formats 540 2.8.1 Schema Unit Listing Request Format 542 To: ietf-schema-review@TBD 543 Subject: schema unit listing request 544 MIME-Version: 1.0 545 Message-Id: 546 Content-Type: multipart/related; start=3@foo.com; boundary="boundary" 547 Content-ID: top@foo.com 549 --boundary 550 Content-Type: text/directory; 551 profile="schema-metadata-0"; 552 charset="utf-8" 553 Content-Transfer-Encoding: Quoted-Printable 554 Content-ID: 3@foo.com 556 (metadata elements and values as specified in [METASYN] and embedded 557 in a text/directory MIME component of profile "schema-meta-0") 559 --boundary 560 Content-Type: text/directory; 561 profile=""; 562 charset="utf-8" 563 Content-Transfer-Encoding: Quoted-Printable 564 Content-ID: 3@foo.com 566 (a schema specification compliant with a profile of [MIMEDIR] 567 corresponding to the value of ) 569 --boundary 571 Where: 573 = "schema-ldap-0" / "schema-whois++-0" / 574 "schema-whois-0" / "schema-rwhois-0" / 575 "schema-xml-0" 577 2.8.2 Schema Pak Listing Request Format 579 To: ietf-schema-review@TBD 580 Subject: schema pak listing request 581 MIME-Version: 1.0 582 Message-Id: 583 Content-Type: text/directory; 584 profile="schema-metadata-0"; 585 charset="utf-8" 586 Content-Transfer-Encoding: Quoted-Printable 588 (metadata elements and values as specified in [METASYN] and embedded 589 in a text/directory MIME component of profile "schema-meta-0") 591 2.9 Primary Repository Operator Responsibilities and Constraints 593 The data residing in the repository is not the property of the 594 repository operator. Since the schema actually listed are the 595 intellectual property of the entities creating the listing, the 596 repository operator cannot claim them as intellectual property. All 597 metadata surrounding the system is considered to be either in the 598 public domain or is owned by the IANA (or some other suitable 599 entity). The repository operator can make no claims whatsoever of 600 ownership over any data in the repository. 602 The repository operator can also make no determinations of 603 appropriateness or suitability of a schema to be listed. This 604 responsibility rests solely with the members of the listing request 605 review committee (the members of the listing request review mailing 606 list). If the list coordinator requests that the repository operator 607 publish a schema listing, the repository operator MUST include the 608 schema listing or be relieved of the reponsibility of running the 609 repository. 611 Currently, the ability to advertise products and services on the 612 repository web site to recoup monies used in operating the service is 613 allowed. At any time, the review committee make make a policy 614 decision on the appropriateness of ads on the repository pages. 616 3.0 Security Considerations 618 As described in [LISTRQMT], the subject of trust with respect to most 619 aspects of the service involving the exchange of information 620 (submitting a listing request, updating an existing listing, or 621 retrieving a listing) is not addressed in this document. However, the 622 primary schema listing repository operator will take reasonable steps 623 to ensure that information associated with the service is as accurate 624 and authentic as possible. 626 If users of the schema listing service obtain and use listings from 627 the repository, they SHOULD verify that any fingerprints contained as 628 a part of metadata for references to related content hosted outside 629 of the repository are valid. This can be verified by computing the 630 MD5 checksum [RFC1321] of the referenced content and comparing it 631 with the fingerprint value. If this verification fails, the user of 632 this schema information can assume that this external content has 633 changed after the listing was published. In any case, no repository 634 operator has control over external content referenced by URIs in the 635 metadata. Thus the establishment of trust as it relates to the 636 validity of fingerprints and the content which they represent is 637 solely the user's responsibility and is OPTIONAL. 639 4.0 Acknowledgements 641 The format and much of the content in this document is based on 642 [RFC2048]. 644 The engineering team for listing service requirements: 646 Chris Apple - AT&T Labs 647 Michael Mealling - NSI 648 Sanjay Jain - Oracle 649 John Strassner - Cisco 650 Sam Sun - CNRI 651 Mark Wahl - Critical Angle 652 Chris Weider - Microsoft 654 Paul Hoffman for review and comments resulting from his effort to 655 develop a platform for the initial release of the schema listing 656 service. 658 5.0 References 660 [FILESYN] C. Apple, "Directory Schema Listing File Name Syntax", 661 INTERNET-DRAFT , January 1998. 663 [LISTRQMT] C. Apple, "Requirements for the Initial Release of a 664 Directory Schema Listing Service", INTERNET-DRAFT , January 1998. 667 [METASYN] C. Apple, "A MIME Directory Profile for Schema Listing Meta 668 Data", INTERNET-DRAFT , 669 January 1998. 671 [MIMELDAP] M. Wahl, "A MIME Directory Profile for LDAP Schema", 672 INTERNET-DRAFT , January 1998. 674 [MIMEWHOISPP] TBP. 676 [MIMEWHOIS] TBP. 678 [MIMERWHOIS] TBP. 680 [MIMERXML] TBP. 682 [RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, 683 April 1992. 685 [RFC2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)", 686 RFC 2015, October 1996. 688 [RFC2048] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet 689 Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, 690 November 1997. 692 [RFC2223] J. Postel, J. Reynolds, "Instructions to RFC Authors", RFC 693 2223, October 1997. 695 6.0 Authors' Address 697 Chris Apple 698 Room 2F-165 699 AT&T Labs 700 600 Mountain Ave 701 Murray Hill, NJ 07974 702 US 704 Phone: +1 908 582 2409 705 Fax: +1 908 582 3296 706 Email: capple@att.com 708 Michael Mealling 709 505 Huntmar Park Drive 710 Herndon, VA 22070 711 US 713 Phone: +1 703 742 0400 714 Fax: +1 703 742 9552 715 Email: michaelm@rwhois.net 717 This Internet-Draft expires on July 31, 1998.