idnits 2.17.1 draft-ietf-schema-proc-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-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 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 10 instances of too long lines in the document, the longest one being 7 characters in excess of 72. 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 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 (21 April 1998) is 9501 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 111, but not defined ** Obsolete undefined reference: RFC 2256 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) == Missing Reference: 'MIMEDIR' is mentioned on line 568, but not defined == Missing Reference: 'MIME' is mentioned on line 132, but not defined == Unused Reference: 'FILESYN' is defined on line 661, but no explicit reference was found in the text == Unused Reference: 'RFC1630' is defined on line 689, 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' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 1630 ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2223 (Obsoleted by RFC 7322) Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 10 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 M. Mealling 5 Network Solutions, Inc. 6 21 April 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), or ftp.isi.edu (US West Coast). 28 Abstract 30 This memo documents procedures for listing directory service schemas 31 in a centrally operated, administered, and maintained repository. 32 This repository will be available as a resource to directory protocol 33 and service implementors to facilitate schema discovery. 35 Table of Contents 37 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 38 1.1 Terms and Definitions. . . . . . . . . . . . . . . . . . . . 3 39 2.0 Directory Schema Listing . . . . . . . . . . . . . . . . . . 5 40 2.1 Schema Listing Request Architecture Diagram. . . . . . . . . 5 41 2.2 Listing Requirements . . . . . . . . . . . . . . . . . . . . 6 42 2.2.1 Functionality Requirements . . . . . . . . . . . . . . . . 6 43 2.2.2 Naming Requirements. . . . . . . . . . . . . . . . . . . . 6 44 2.2.3 Content Formatting and Transfer Encoding Requirements. . . 6 45 2.2.4 Security Requirements. . . . . . . . . . . . . . . . . . . 7 46 2.2.5 Usage and Implementation Non-requirements. . . . . . . . . 8 47 2.2.6 Publication Requirements . . . . . . . . . . . . . . . . . 8 48 2.3 Listing Procedure. . . . . . . . . . . . . . . . . . . . . . 9 49 2.3.1 Announcement and Community Review. . . . . . . . . . . . . 9 50 2.3.2 Community Review and Assessment. . . . . . . . . . . . . . 10 51 2.3.3 Primary Repository Operator Listing. . . . . . . . . . . . 10 52 2.4 Comments on Schema Listings. . . . . . . . . . . . . . . . . 10 53 2.5 Location of List of Available Schema . . . . . . . . . . . . 10 54 2.6 Primary Repository Operator Procedures for Listing Schemas . 10 55 2.7 Change Control . . . . . . . . . . . . . . . . . . . . . . . 12 56 2.8 Listing Request Formats. . . . . . . . . . . . . . . . . . . 13 57 2.8.1 Schema Unit Listing Request Format . . . . . . . . . . . . 13 58 2.8.2 Schema Pak Listing Request Format. . . . . . . . . . . . . 14 59 2.9 Primary Repository Operator Responsibilities and Constraints 14 60 3.0 Security Considerations. . . . . . . . . . . . . . . . . . . 14 61 4.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 62 5.0 References . . . . . . . . . . . . . . . . . . . . . . . . . 15 63 6.0 Authors' Address . . . . . . . . . . . . . . . . . . . . . . 16 65 1.0 Introduction 67 There is a growing number of places where schema for Internet 68 Directory Services are being defined, with varying degrees of 69 documentation. This plethora of schemas is unavoidable in the light 70 of the needs of different service communities, but it makes it 71 difficult for directory service builders to find and make use of an 72 existing schema that will serve their needs and increase 73 interoperability with other systems. A listing service providing a 74 single point of discovery for directory service schema will promote 75 schema reuse, reduce duplication of effort, and thus promote 76 directory service interoperability. Listed schema will be assiged a 77 permanent, unique listing listing name as a part of the creating 78 schema listing requests; which starts the schema listing process. 79 This listing process was defined to ensure that directory service 80 schema writers can publish their schema in a public forum so that 81 they will be re-used. 83 The IETF schema listing service has public read access and 84 restricted, moderated write access. Currently, this listing service 85 is centrally operated, administered, and maintained by the Internet 86 Directory Consortium. The schema listing repository is mirrored to 87 ensure some level of redundancy for read access. 89 This document defines schema listing procedures which use the 90 Internet Directory Consortium as the primary listing repository 91 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 [RFC2256] 112 Metadata - characteristics that differentiate one schema unit or 113 schema pak from another; used to catalog listing service content; 114 structured using a profile of [MIMEDIR]; also contains references to 115 files stored within and outside of a listing repository 117 Schema Unit Content - a formal specification of a schema unit using a 118 profile of [MIMEDIR] 120 Schema Unit Listing - the combination of a single schema unit content 121 file intended for use within the context of a particular protocol and 122 a file containing metadata describing the schema unit specified 123 within that schema unit content file 125 Schema Pak Listing - a single metadata file containing information 126 describing and referring to a set of related or grouped schema unit 127 content files 129 Repository - a database in which listings are stored 131 Listing Request - a proposed schema unit listing or schema pak 132 listing formatted using [MIME] constructs that is submitted for 133 consideration as a listing to be published in a repository 135 Operator - an organization that administers and maintains a 136 repository 138 Primary Repository - the repository that masters the schema listings 139 database 141 Shadow Repository - a repository that mirrors the primary repository 143 Contact Person - the name of the individual who holds the authority 144 to update a listing and who should be contacted if questions or 145 concerns arise related to a listing or listing request 147 Listing Authority Contact - the name of the individual who holds 148 authority to replace a contact person; can be either the contact 149 person for a listing or an alternate contact within the organization 150 to which the contact person belongs (this allows one person 151 organizations to list schema) 153 The terms for specifying requirement level defined in [RFC2119] are 154 used in this document. 156 2.0 Directory Schema Listing 158 2.1 Schema Listing Request Architecture Diagram 160 Schema Writer 161 | <-----------------schema listing request with 162 | a permanent, unique listing 163 | name obtained from the primary 164 V repository operator 165 Schema Listing Request Review List 166 | 167 V 168 +-----------------------+ 169 |Significant objections | YES 170 |raised within 2 weeks? |----> Back to the drawing board.... 171 +-----------------------+ 172 | NO (List Moderator recommends that listing 173 Schema Listing-->| be published subject to comments on list.) 174 Request V 175 +-----------------+ 176 |Request meets | NO 177 |all requirements?| ----> Back to the drawing board.... 178 +-----------------+ 179 | YES 180 | <-----------------metadata/listing content 181 V 182 Repository Mirroring Agent 183 | | ... | 184 V V V 185 +----------+ +----------+ +----------+ 186 |Repository| |Repository| |Repository| where: 1 is the primary 187 | 1 | | 2 | | n | 2..n are replicas 188 +----------+ +----------+ +----------+ 190 Listing of a new schema starts with the construction of a listing 191 request. Schema writers obtain a unique listing name and include it 192 in the schema listing request sent to a moderated request review 193 list. Following a comment period of 2 weeks, if no significant 194 objections are raised (determined by the moderator), the moderator 195 sends the listing request to the primary listing repository operator, 196 subject to incorporation of relevant comments by the schema writer. 197 Listing requests are checked to verify compliance with the 198 requirements and conditions discussed below and the listing will be 199 published in the primary listing repository if appropriate. A 200 mirroring agent replicates the new listing across the primary and 201 mirrored copies of the listing repository database. 203 The following sections describe the requirements and procedure. 205 2.2 Listing Requirements 207 Listing requests are all expected to conform to various requirements 208 laid out in the following sections. 210 2.2.1 Functionality Requirements 212 Schema unit listings MUST include two different types of information: 214 (1) metadata 216 (2) schema unit content 218 Metadata will be used to catalog repository files by characteristics 219 that differentiate listings. 221 Schema unit content MUST be limited to the specification of a single 222 schema unit. 224 2.2.2 Naming Requirements 226 All listings MUST have a valid OID as their name. 228 The primary listing repository operator MUST provide schema writers 229 with the following components of a listing request name: 231 + a sequence number assigned to each listing 232 by the primary repository operator 234 + a version number assigned to each listing 235 version by the primary repository operator 237 2.2.3 Content Formatting and Transfer Encoding Requirements 239 All listings MUST employ a common data format. 241 Metadata and schema unit content format and transfer encoding MUST 242 utilize appropriate [MIMEDIR] profiles. 244 Currently, five [MIMEDIR] profiles have been defined for use in the 245 schema listing service: 247 [MIMELDAP] MUST be used to format and encode LDAPv3 schema unit 248 content. 250 [MIMEWHOISPP] MUST be used to format and encode WHOIS++ schema 251 unit content. 253 [MIMEWHOIS] MUST be used to format and encode WHOIS schema unit 254 content. 256 [MIMERWHOIS] MUST be used to format and encode RWHOIS schema unit 257 content. 259 [METASYN] MUST be used to format and encode metadata for all 260 schema unit listings, schema pak listings, and listing requests. 262 Other [MIMEDIR] profiles MAY be defined for use in the schema listing 263 service; this procedures document will be updated reflect such 264 changes. 266 2.2.4 Security Requirements 268 An analysis of security issues for listed schema SHOULD be performed 269 prior to submitting a listing request. However, regardless of what 270 security analysis has or has not been done, all descriptions of 271 security issues MUST be as accurate as possible. In particular, a 272 statement that there are "no security issues associated with this 273 type" MUST not be confused with "the security issues associates with 274 this type have not been assessed". 276 There is absolutely NO REQUIREMENT that listed schema be secure or 277 completely free from risks. Nevertheless, all known security risks 278 SHOULD be identified in the listing request. 280 The security considerations section of all requests is subject to 281 continuing evaluation and modification, and in particular MAY be 282 extended by use of the "comments on schema listings" mechanism 283 described in subsequent sections. 285 Some of the issues that SHOULD be looked at in a security analysis of 286 a schema listing are: 288 (1) A listing might include specifications mandating 289 exposure of certain attributes which would result in 290 compromising the privacy of an organization or 291 individual. 293 (2) A listing might be intended for use by 294 applications requiring some sort of security 295 assurances not provided by the schema specified 296 in the schema unit content or in the schema unit 297 content files referenced in a schema pak listing. 299 2.2.5 Usage and Implementation Non-requirements 301 In the directory services environment, where information on the 302 embedded schema knowledge of a directory client is frequently not 303 available to a server, maximum interoperability is attained by 304 restricting the schema used to those agreed upon by the large 305 community of directory service technology developers and users. This 306 was asserted in the past as a reason to limit the number of possible 307 schema to one via standards processes and resulted in a change 308 process with a significant hurdle and delay for those seeking to 309 modify and extend standard schema to better suite their needs. 310 Eventually, various individuals and organizations began using non- 311 standard schema, making interoperability difficult to achieve. 313 The need for "common" or "meta" schema listings does not require 314 limiting the publication of new listings. If a set of schema unit 315 listings is recommended for a particular application, that should be 316 asserted by an intended use statement specific for that application 317 and/or environment withing a schema pak listing metadata file. If a 318 set of schema pak listings is recommended for a particular 319 application, that should be asserted by a separate intended use 320 statement specific for the application and/or environment; or an 321 additional schema pak listing containing references to all of the 322 relevant schema unit listings should be created, reviewed, and 323 published. 325 As such, universal support and implementation of a schema is NOT a 326 requirement for listing it. If, however, a schema is explicitly 327 intended for limited use, this should be noted in its listing(s). 329 2.2.6 Publication Requirements 331 Requests for schema listed in the IETF schema listing service MAY be 332 published as RFCs. The primary listing repository operator will 333 retain copies of all schema listing requests that meet the 334 requirements specified below and "publish" them as part of the schema 335 listing repository. 337 The listing of a schema does not imply endorsement, approval, or 338 recommendation by the IETF or even certification that the 339 specification is adequate for the intended use of the schema. To 340 become Internet Standards, protocol, data objects, or whatever must 341 go through the IETF standards process. This is too difficult and too 342 lengthy a process for the convenient listing of schema. 344 It is expected that applicability statements for particular 345 applications will be published from time to time that recommend 346 implementation of, and support for, schema that have proven 347 particularly useful in those contexts. 349 2.3 Listing Procedure 351 The following procedure has been implemented by the primary listing 352 repository operator for review and approval of new listings. This is 353 not a formal standards process, but rather an administrative 354 procedure intended to foster re-use of directory services schema and 355 to provide a method for collecting schema in a publicly accessible 356 repository. 358 Submitting listing requests can be done via mail, treating posting of 359 a formatted request containing the specification of schema unit 360 content for a particular protocol and/or metadata to the mailing list 362 ietf-schema-review@pilot.schema.dir.reg.int 364 as a first step. 366 2.3.1 Announcement and Community Review 368 While listed schema are NOT REQUIRED to be published as RFCs, listing 369 requests documenting them MUST be posted to the mailing list 371 ietf-schema-review@pilot.schema.dir.reg.int, 373 allowing a review and comment period of at least 2 weeks. This is 374 necessary to prevent the malicious as well as unintended introduction 375 of obviously bogus or frivolous schema into the listing repository. 377 Schema writers wishing to have their schema listed by the primary 378 listing repository operator, MUST specify any such schema (may 379 require the creation/submission of more than one request) according 380 to one of the following [MIMEDIR] profiles: [MIMELDAP], 381 [MIMEWHOISPP], [MIMEWHOIS], or [MIMERWHOIS]. Other such profiles may 382 be defined elsewhere and this procedures document will be update to 383 reflect such process changes. 385 Metadata, as specified in [METASYN], MUST also be included in this 386 request. A template for listing requests is specified in paragraph 387 2.8. Schema writers MUST use this template. 389 Schema writers MUST also construct a unique listing request name for 390 each request being created. Listing names are constructed according 391 to the type valuetype syntax and type special notes for the 392 'listingName' MIME Directory Type [METASYN]. 394 Once created, the listing request should be sent to ietf-schema- 395 review@pilot.schema.dir.reg.int. 397 2.3.2 Community Review and Assessment 399 Moderated discussions on the ietf-schema- 400 review@pilot.schema.dir.reg.int mailing list will enable a means of 401 gauging concensus as to whether or not the schema being proposed is 402 bogus. If there is no significant reason to believe that a schema is 403 useful or if it appears to be a bogus or malicious request, the 404 moderator will not submit a listing request to the primary listing 405 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- 411 review@pilot.schema.dir.reg.int list moderator will send that listing 412 request to the primary repository operator, which will check this 413 listing request for validity, and make the listing available to the 414 community. 416 2.4 Comments on Schema Listings 418 Comments on listings may be submitted by members of the IETF 419 community to for consideration by the rest of the community and the 420 primary listing repository operator. These comments will be passed on 421 to the contact person for the listing if possible. Submitters of 422 comments may request that their comment be attached to the listing 423 itself. If the ietf-schema-review@pilot.schema.dir.reg.int list 424 moderator is able to gauge concensus affirming the inclusion of such 425 a comment, it will be made accessible in conjunction with the listing 426 itself. 428 2.5 Location of List of Available Schema 430 Listings will be posted in the anonymous FTP directory 431 "ftp://www.pilot.schema.dir.reg.int/schema/" and all listings will be 432 summarized in a periodically issued RFC. Schema unit content, schema 433 pak listings, and/or other supporting material may also be published 434 as an Informational RFC by sending it to "rfc-editor@isi.edu" (please 435 follow the instructions to RFC authors [RFC2223]). 437 2.6 Primary Repository Operator Procedures for Listing Schemas 439 Listings will be published by the primary repository operator 440 automatically and without any formal review as long as the following 441 minimal conditions are met: 443 (1) All listings MUST have a valid OID as their name. 445 (2) All schema unit listing requests MUST include both 446 metadata and schema unit content. 448 (3) All schema pak listing requests MUST be limited to 449 metadata. 451 (4) Metadata MUST comply with [METASYN]. 453 (5) Schema unit content MUST be compliant with at one 454 of the following [MIMEDIR] profiles: 456 + [MIMELDAP] (for LDAPv3 schema specifications) 457 + [MIMEWHOISPP] (for WHOIS++ schema specifications) 458 + [MIMEWHOIS] (for WHOIS schema specifications) 459 + [MIMERWHOIS] (for RWHOIS schema specifications) 461 Other [MIMEDIR] profiles may be defined in the future and this 462 document will be updated to reflect such additional profiles. 464 (6) Any security considerations given must not be obviously 465 bogus. It is neither possible nor necessary for the 466 primary listing repository operator to conduct a 467 comprehensive security review of listings. 468 However, the listing request review committee 469 (the members of the listing request review 470 mailing list) has the authority and expertise 471 to identify obviously incompetent material 472 and exclude it. 474 (7) Schema listing requests MAY be signed using PGP/MIME 475 as described in [RFC2015]. The primary listing repository 476 operator MUST be able to accept listing requests 477 in PGP/MIME messages, although they are NOT REQUIRED 478 to validate or retain the signatures. 480 (8) Listing request MUST be formatted according to 481 paragraph 2.8. 483 (9) If a listing request includes one or more 484 URI-based references to information that would not be 485 included in a resulting listing, but is associated with 486 the schema or schema unit specified by the request, 487 a fingerprint of this information MUST be included with 488 each such reference as specified in [METASYN]. The schema 489 writer MUST also include a special caveat metadata element 490 (as specified in [METASYN]) if at least one such 491 reference is included in the request. 493 2.7 Change Control 495 Once a listing has been published by the primary repository operator, 496 the contact person may request a change to its definition. The 497 contact person for a listed schema is defined to be the person or 498 organizational role or entity who submitted the original listing 499 request. 501 The change request follows the same procedure as the listing request 503 (1) Publish the revised listing request on the 504 ietf-schema-review@pilot.schema.dir.reg.int list. 506 (2) Leave at least two weeks for comments. 508 (3) Publish using the primary listing repository 509 operator after formal review if required. 511 Changes MAY be requested when there are serious omissions or errors 512 in the published listing or when other factors which would justify a 513 change request, such as an emerging need of the user community for a 514 listed schema which cannot be addressed by that listed schema in its 515 present form. When review is required, a change request MAY be denied 516 if it renders entities that were valid under the previous definition 517 invalid under the new definition. 519 The primary listing repository provider SHOULD attempt to verify the 520 authority of a person claiming to be the contact for a listing, prior 521 to implementing such changes. 523 The contact person for a listing MAY pass responsibility for that 524 listing to another person or agency by informing the primary listing 525 repository operator and the ietf-schema- 526 announce@pilot.schema.dir.reg.int list; this can be done without 527 discussion or review. 529 The IESG may reassign responsibility for a listing. The most common 530 case of this will be to enable changes to be made to types where the 531 contact person for the listing has died, moved out of contact, or is 532 otherwise unable to make changes that are important to the community. 534 Listings will not be deleted; listings which are no longer believed 535 appropriate for use can be declared OBSOLETE by a change to their 536 "intended use" field; such listings will be clearly marked in 537 repository content summary RFCs published by the primary listing 538 repository operator. 540 2.8 Listing Request Formats 542 2.8.1 Schema Unit Listing Request Format 544 To: ietf-schema-review@pilot.schema.dir.reg.int 545 Subject: schema unit listing request 546 MIME-Version: 1.0 547 Message-Id: 548 Content-Type: multipart/related; start=3@foo.com; boundary="boundary" 549 Content-ID: top@foo.com 551 --boundary 552 Content-Type: text/directory; 553 profile="schema-metadata-0"; 554 charset="utf-8" 555 Content-Transfer-Encoding: Quoted-Printable 556 Content-ID: 3@foo.com 558 (metadata elements and values as specified in [METASYN] and embedded 559 in a text/directory MIME component of profile "schema-meta-0") 561 --boundary 562 Content-Type: text/directory; 563 profile=""; 564 charset="utf-8" 565 Content-Transfer-Encoding: Quoted-Printable 566 Content-ID: 3@foo.com 568 (a schema specification compliant with a profile of [MIMEDIR] 569 corresponding to the value of ) 571 --boundary 573 Where: 575 = "schema-ldap-0" / "schema-whoispp-0" / 576 "schema-whois-0" / "schema-rwhois-0" 578 2.8.2 Schema Pak Listing Request Format 580 To: ietf-schema-review@pilot.schema.dir.reg.int 581 Subject: schema pak listing request 582 MIME-Version: 1.0 583 Message-Id: 584 Content-Type: text/directory; 585 profile="schema-metadata-0"; 586 charset="utf-8" 587 Content-Transfer-Encoding: Quoted-Printable 589 (metadata elements and values as specified in [METASYN] and embedded 590 in a text/directory MIME component of profile "schema-meta-0") 592 2.9 Primary Repository Operator Responsibilities and Constraints 594 The data residing in the repository is not the property of the 595 repository operator. Since the schema actually listed are the 596 intellectual property of the entities creating the listing, the 597 repository operator cannot claim them as intellectual property. All 598 metadata surrounding the system is considered to be either in the 599 public domain or is owned by the IANA (or some other suitable 600 entity). The repository operator can make no claims whatsoever of 601 ownership over any data in the repository. 603 The repository operator can also make no determinations of 604 appropriateness or suitability of a schema to be listed. This 605 responsibility rests solely with the members of the listing request 606 review committee (the members of the listing request review mailing 607 list). If the list coordinator requests that the repository operator 608 publish a schema listing, the repository operator MUST include the 609 schema listing or be relieved of the reponsibility of running the 610 repository. 612 Currently, the ability to advertise products and services on the 613 repository web site to recoup monies used in operating the service is 614 allowed. At any time, the review committee make make a policy 615 decision on the appropriateness of ads on the repository pages. 617 3.0 Security Considerations 619 As described in [LISTRQMT], the subject of trust with respect to most 620 aspects of the service involving the exchange of information 621 (submitting a listing request, updating an existing listing, or 622 retrieving a listing) is not addressed in this document. However, the 623 primary schema listing repository operator will take reasonable steps 624 to ensure that information associated with the service is as accurate 625 and authentic as possible. 627 If users of the schema listing service obtain and use listings from 628 the repository, they SHOULD verify that any fingerprints contained as 629 a part of metadata for references to related content hosted outside 630 of the repository are valid. This can be verified by computing the 631 MD5 checksum [RFC1321] of the referenced content and comparing it 632 with the fingerprint value. If this verification fails, the user of 633 this schema information can assume that this external content has 634 changed after the listing was published. In any case, no repository 635 operator has control over external content referenced by URIs in the 636 metadata. Thus the establishment of trust as it relates to the 637 validity of fingerprints and the content which they represent is 638 solely the user's responsibility and is OPTIONAL. 640 4.0 Acknowledgements 642 The format and much of the content in this document is based on 643 [RFC2048]. 645 The engineering team for listing service requirements: 647 Chris Apple - AT&T Labs 648 Michael Mealling - NSI 649 Sanjay Jain - Oracle 650 John Strassner - Cisco 651 Sam Sun - CNRI 652 Mark Wahl - Critical Angle 653 Chris Weider - Microsoft 655 Paul Hoffman for review and comments resulting from his effort to 656 develop a platform for the initial release of the schema listing 657 service. 659 5.0 References 661 [FILESYN] C. Apple, "Directory Schema Listing File Name Syntax", 662 INTERNET-DRAFT , April 1998. 664 [LISTRQMT] C. Apple, "Requirements for the Initial Release of a 665 Directory Schema Listing Service", INTERNET-DRAFT , April 1998. 668 [METASYN] C. Apple, "A MIME Directory Profile for Schema Listing Meta 669 Data", INTERNET-DRAFT , April 670 1998. 672 [MIMELDAP] M. Wahl, "A MIME Directory Profile for LDAP Schema", 673 INTERNET-DRAFT , January 1998. 675 [MIMEWHOISPP] L. Daigle, "A MIME Directory Profile for Whois++ 676 Schema", INTERNET-DRAFT , April 677 1998. 679 [MIMEWHOIS] R. Moats, "A MIME Content-Type for WHOIS", INTERNET-DRAFT 680 , April 1998. 682 [MIMERWHOIS] M. Mealling, "A MIME Directory Profile for RWhois 1.5 683 Schema", INTERNET-DRAFT , March 684 1998. 686 [RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, 687 April 1992. 689 [RFC1630] T. Berners-Lee, "Universal Resource Identifiers in WWW", 690 RFC 1630, June 1994. 692 [RFC2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)", 693 RFC 2015, October 1996. 695 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 696 Requirement Level", RFC 2119, March 1997. 698 [RFC2048] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet 699 Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, 700 November 1997. 702 [RFC2223] J. Postel, J. Reynolds, "Instructions to RFC Authors", RFC 703 2223, October 1997. 705 6.0 Authors' Address 707 Chris Apple 708 Room 2F-165 709 AT&T Labs 710 600 Mountain Ave 711 Murray Hill, NJ 07974 712 US 714 Phone: +1 908 582 2409 715 Fax: +1 908 582 3296 716 Email: capple@att.com 718 Michael Mealling 719 505 Huntmar Park Drive 720 Herndon, VA 22070 721 US 722 Phone: +1 703 742 0400 723 Fax: +1 703 742 9552 724 Email: michaelm@rwhois.net 726 This Internet-Draft expires on October 21, 1998.