INTERNET-DRAFT C. Apple AT&T Laboratories Expires: May 6, 1998 M. Mealling Network Solutions, Inc. 6 November 1997 Directory Schema Listing Procedures Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo documents procedures for listing directory service schemas in a centrally operated, administered, and maintained repository. This repository will be available as a resource to directory protocol and service implementors to facilitate schema discovery. 1.0 Introduction There is a growing number of places where schema for Internet Directory Services are being defined, with varying degrees of documentation. This plethora of schemas is unavoidable in the light of the needs of different service communities, but it makes it difficult for directory service builders to find and make use of an existing schema that will serve their needs and increase interoperability with other systems. A listing service providing a single point of discovery for directory service schema will promote schema reuse, reduce duplication of effort, and thus promote Apple, Mealling [Page 1] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 directory service interoperability. Listed schema will be assiged a permanent serial number (similar to those assigned to RFCs) as a part of the listing process. This listing process was defined to ensure that schema writers can publish their schema in a public forum so that they will be re-used. The IETF schema listing service has public read access and restricted, moderated write access. Currently, this listing service is centrally operated, administered, and maintained by TBD. The schema listing repository is mirrored to ensure some level of redundancy for read access. This document defines schema listing procedures which use TBD as the primary listing repository operator. 1.1 Terms and Definitions Information Object - a descriptive abstraction of some real-world object Schema - a collection of definitions for related information objects Listing Meta Data - characteristics that differentiate one schema from another; used to catalog schema Listing Content - a formal specification of a schema using a profile of [MIMEDIR] created to provide a template for syntax and content transfer encoding of directory service protocol schema Schema Listing - the combination of listing meta data and all available listing content for a particular schema Repository - a database in which schema listings are stored Schema Listing Request - a schema listing formatted using [MIME] constructs that is submitted for consideration as a schema listing to be published in a repository Operator - an organization that administers and maintains a repository Primary Repository - the repository that masters the schema listings database Shadow Repository - a repository that mirrors the primary repository Contact Person - the name of the individual who holds the authority to update a schema listing and who should be contacted if questions Apple, Mealling [Page 2] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 or concerns arise related to a schema listing or schema listing request Listing Authority Contact - the name of the individual who holds authority to replace a contact person; can be either the contact person for a schema listing or an alternate contact within the organization to which the contact person belongs (this allows one person organizations to list schema) The terms for specifying requirement level described in [RFC2119] are used in this document. 2.0 Directory Schema Listing 2.1 Schema Listing Request Architecture Diagram Schema Writer | <-----------------schema listing request V Schema Listing Request Review List | V +-----------------------+ |Significant objections | YES |raised within 2 weeks? |----> Back to the drawing board.... +-----------------------+ | NO (List Moderator recommends that schema listing Schema Listing-->| be published subject to comments on list.) Request V +-----------------+ |Request meets | NO |all requirements?| ----> Back to the drawing board.... +-----------------+ | YES | <-----------------schema listing meta data V and listing content Repository Mirroring Agent | | ... | V V V +----------+ +----------+ +----------+ |Repository| |Repository| |Repository| where: 1 is the primary | 1 | | 2 | | n | 2..n are replicas +----------+ +----------+ +----------+ Listing of a new schema starts with the construction of a listing request. Schema writers send in schema listing requests to a Apple, Mealling [Page 3] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 moderated request review list. Following a comment period of 2 weeks, if no significant objections are raised (determined by the moderator), the moderator sends the listing request to the primary listing repository operator, subject to incorporation of relevant comments by the schema writer. Listing requests are checked to verify compliance with the requirements and conditions discussed below and assigned a permanent serial number. A mirroring agent replicates the new listing across the primary and mirrored copies of the listing repository database. The following sections describe the requirements and procedure. 2.2 Listing Requirements Listing requests are all expected to conform to various requirements laid out in the following sections. 2.2.1 Functionality Requirements Listings MUST include two different types of information: (1) listing meta data (2) listing content Listing meta data will be used to catalog the listed schema by characteristics that differentiate schema. Listing content MUST be limited to the specification of the schema itself. Different profiles containing listing content MAY be included in the same listing request. Listing content MUST actually function as a directory schema. Listing of schema that include listing content that does not function as a directory schema is PROHIBITED. 2.2.2 Naming Requirements All listings MUST have a valid OID as their name. The primary listing repository operator MUST construct an OID for each listing based on the combination of + a root OID obtained from IANA specifically for use in the schema listing service + a sequence number assigned to each schema Apple, Mealling [Page 4] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 listing by the primary repository operator + a version number assigned to each schema listing by the primary repository operator The schema writer MUST allocate a temporary name for all schema listing requests. This listing request name must based on one of the following: + an OID allocated from within an OID subtree which the schema writer or their organization administers + a GUID generated according to [GUIDGEN] or [GUIDOTHER] 2.2.3 Content Formatting and Transfer Encoding Requirements All schema listings MUST employ a common data format. Listing meta data and listing content format and transfer encoding MUST utilize appropriate [MIMEDIR] profiles. Currently, four [MIMEDIR] profiles have been defined for use in the schema listing service: [MIMELDAP] MUST be used to format and encode LDAPv3 listing content. [MIMEWHOIS] MUST be used to format and encode WHOIS++ listing content. [MIMERWHOIS] MUST be used to format and encode RWHOIS listing content. [METASYN] MUST be used to format and encode meta data for all schema listings and listing requests. Other [MIMEDIR] profiles MAY be defined for use in the schema listing service; this procedures document will be updated reflect such changes. 2.2.4 Security Requirements 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 Apple, Mealling [Page 5] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 this type have not been assessed". There is absolutely NO REQUIREMENT that listed schema be secure or completely free from risks. Nevertheless, all known security risks SHOULD be identified in the listing request. The security considerations section of all requests is subject to continuing evaluation and modification, and in particular MAY be extended by use of the "comments on schema listings" mechanism described in subsequent sections. Some of the issues that SHOULD be looked at in a security analysis of a schema listing are: (1) A schema listing might include specifications mandating exposure of certain attributes which would result in compromising the privacy of an organization or individual. (2) A schema listing might be intended for use by applications requiring some sort of security assurances not provided by the schema specified in the listing content. 2.2.5 Usage and Implementation Non-requirements In the directory services environment, where information on the embedded schema knowledge of a directory client is frequently not available to a server, maximum interoperability is attained by restricting the schema used to those agreed upon by the large community of directory service technology developers and users. This was asserted in the past as a reason to limit the number of possible schema to one via standards processes and resulted in a change process with a significant hurdle and delay for those seeking to modify and extend standard schema to better suite their needs. Eventually, various individuals and organizations began using non- standard schema, making interoperability difficult to achieve. The need for "common" or "meta" schema listings does not require limiting the listing of new schema listings. If a limited set of schema is recommended for a particular application, that should be asserted by a separate intended use statement specific for the application and/or environment. As such, universal support and implementation of a schema is NOT a requirement for listing it. If, however, a schema is explicitly intended for limited use, this should be noted in its listing. Apple, Mealling [Page 6] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 2.2.6 Publication Requirements Requests for schema listed in the IETF schema listing service MAY be published as RFCs. The primary listing repository operator will retain copies of all schema listing requests that meet the requirements specified below and "publish" them as part of the schema listing repository. The listing of a schema does not imply endorsement, approval, or recommendation by the IETF or even certification that the specification is adequate for the intended use of the schema. To become Internet Standards, protocol, data objects, or whatever must go through the IETF standards process. This is too difficult and too lengthy a process for the convenient listing of schema. It is expected that applicability statements for particular applications will be published from time to time that recommend implementation of, and support for, schema that have proven particularly useful in those contexts. 2.3 Listing Procedure The following procedure has been implemented by the primary listing repository operator for review and approval of new schema listings. This is not a formal standards process, but rather an administrative procedure intended to foster re-use of directory services schema and to provide a method for collecting schema in a publicly accessible repository. Submitting listing requests can be done via mail, treating posting of a formatted request containing the specification of listing content (in all available types) and supporting material (meta data) to the ietf-schema-review@TBD list, as a first step. 2.3.1 Announcement and Community Review While listed schema are NOT REQUIRED to be published as RFCs, they MUST be posted to the ietf-schema-review@TBD list, allowing a review and comment period of at least 2 weeks. This is necessary to prevent the malicious as well as unintended introduction of obviously bogus or frivolous schema into the listing repository. Schema writers wishing to have their schema listed by the primary listing repository operator, MUST specify any such schema (one per request) according to one or more of the following [MIMEDIR] profiles: [MIMELDAP], [MIMEWHOIS], or [MIMERWHOIS]. Other such profiles may be defined elsewhere and this procedures document will Apple, Mealling [Page 7] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 be update to reflect such process changes. Listing meta data, as specified in [METASYN], MUST also be included in this request. A template for listing requests is specified in paragraph 2.8. Schema writers MUST use this template. Once written, the request should be sent to ietf-schema-review@TBD. 2.3.2 Community Review and Assessment At this stage of the schema listing process, a place holder, such as the ever popular TBD (to be determined) MAY be used in place of an actual OID value for the name of the schema specified in the listing request. Moderated discussions on the ietf-schema-review@TBD mailing list will enable a means of gauging concensus as to whether or not the schema being proposed is bogus. If there is no significant reason to believe that a schema is useful or if it appears to be a bogus or malicious request, the moderator will not submit a listing request to the primary listing repository operator; otherwise, they may do so. If the listing request is to be published, the temporary name (an OID or GUID) for the schema listing MUST be replaced with a constructed OID by the primary listing repository operator. 2.3.3 Primary Repository Operator Listing Provided that the schema listing request meets the requirements defined in paragraph 2.1, the ietf-schema-review@TBD list moderator will send a listing request to the primary repository operator, which will check the schema listing for validity, and make the schema listing available to the community. 2.4 Comments on Schema Listings Comments on listed schema may be submitted by members of the IETF community to for consideration by the rest of the community and the primary listing repository operator. These comments will be passed on to the owner of the schema if possible. Submitters of comments may request that their comment be attached to the schema listing itself. If the ietf-schema-review@TBD list moderator is able to establish concensus affirming the inclusion of such a comment, it will be made accessible in conjunction with the schema listing itself. 2.5 Location of List of Available Schema Schema listings will be posted in the anonymous FTP directory Apple, Mealling [Page 8] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 "ftp://TBD.host.name/schema/" and all listed schema will be listed in a periodically issued RFC. The schema listing content and other supporting material may also be published as an Informational RFC by sending it to "rfc-editor@isi.edu" (please follow the instructions to RFC authors [RFC1543]). 2.6 Primary Repository Operator Procedures for Listing Schemas Schema will be listed by the primary repository operator automatically and without any formal review as long as the following minimal conditions are met: (1) Schema MUST function as an actual directory service schema. In particular, generic database schema MUST NOT be listed. (2) All schema listings MUST have a valid OID as their name. (3) All schema listing requests MUST include both meta data and listing content. (4) Schema listing meta data MUST comply with [METASYN]. (5) Schema listing content MUST be compliant with at least one of the following [MIMEDIR] profiles: + [MIMELDAP] (for LDAPv3 schema specifications) + [MIMEWHOIS] (for WHOIS++ schema specifications) + [MIMERWHOIS] (for RWHOIS schema specifications) Other [MIMEDIR] profiles may be defined in the future and this document will be updated to reflect such additional profiles. (6) Equivalent schema listing content specified using different [MIMEDIR] profiles MAY be included in the same listing request. (7) Any security considerations given must not be obviously bogus. It is neither possible nor necessary for the primary listing repository operator to conduct a comprehensive security review of schema listings. However, the listing request review committee (the members of the listing request review mailing list) has the authority and expertise to identify obviously incompetent material and exclude it. (8) Schema listing requests MAY be signed using PGP/MIME as described in [RFC2015]. The primary listing repository Apple, Mealling [Page 9] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 operator MUST be able to accept schema listing requests in PGP/MIME messages, although they are NOT REQUIRED to validate or retain the signatures. (9) The listing request MUST be formatted according to paragraph 2.8. (10) If the listing request includes one or more external, URI-based references to information associated with the schema specified in the request, a fingerprint of this information MUST be included with each such reference as specified in [METASYN]. The schema writer must also include a special caveat meta data element (as specified in [METASYN]) if at least one such reference is included in the request. 2.7 Change Control Once a schema listing has been published by the primary repository operator, the contact person may request a change to its definition. The contact person for a listed schema is defined to be the person or organizational role or entity who submitted the original listing request. The change request follows the same procedure as the listing request (1) Publish the revised schema listing proposal on the ietf-schema-review@TBD list. (2) Leave at least two weeks for comments. (3) Publish using the primary listing repository operator after formal review if required. Changes SHOULD be requested only when there are serious omission or errors in the published specification. When review is required, a change request MAY be denied if it renders entities that were valid under the previous definition invalid under the new definition. However, the primary listing repository provider SHOULD attempt to verify the authority of a person claiming to be the contact for a schema listing to change it, prior to implementing such changes. The contact person for a schema MAY pass responsibility for the schema to another person or agency by informing the primary listing repository operator and the ietf-schema-announce list; this can be done without discussion or review. The IESG may reassign responsibility for a schema. The most common Apple, Mealling [Page 10] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 case of this will be to enable changes to be made to types where the contact person for the listing has died, moved out of contact, or is otherwise unable to make changes that are important to the community. Schema listings will not be deleted; schema which are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended use" field; such schema will be clearly marked in the lists published by the primary listing repository operator. 2.8 Listing Proposal Format To: ietf-schema-review@TBD Subject: schema listing request Content-Type: multipart/related; start=2@foo.com; boundary="boundary" Content-ID: top@foo.com --boundary Content-Type: text/directory; profile="schema-meta-0" Content-ID: 3@foo.com (meta data elements and values as specified in [METASYN] and embedded in a text/directory MIME component of profile "schema-meta-0") --boundary Content-Type: text/directory; profile="schema-ldap-0" Content-ID: 3@foo.com (a schema specification compliant with [MIMELDAP]) --boundary Content-Type: text/directory; profile="schema-whoispp-0" Content-ID: 4@foo.com (a schema specification compliant with [MIMEWHOIS]) --boundary Content-Type: text/directory; profile="schema-rwhois-0" Content-ID: 5@foo.com (a schema specification compliant with [MIMERWHOIS]) --boundary-- 2.9 Primary Repository Operator Responsibilities and Constraints The data residing in the repository is not the property of the repository operator. Since the schema actually listed are the intellectual property of the entities creating the listing, the repository operator cannot claim them as intellectual property. All Apple, Mealling [Page 11] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 meta data surrounding the system is considered to be either in the public domain or is owned by the IANA (or some other suitable entity). The repository operator can make no claims whatsoever of ownership over any data in the repository. The repository operator can also make no determinations of appropriateness or suitability of a schema to be listed. This responsibility rests solely with the members of the listing request review committee (the members of the review mailing list). If the list coordinator requests that the repository operator publish a schema listing, the repository operator MUST include the schema listing or be relieved of the reponsibility of running the repository. Currently, the ability to advertise products and services on the repository web site to recoup monies used in operating the service is allowed. At any time, the submittal committee make make a policy decision on the appropriateness of ads on the repository pages. 3.0 Security Considerations As described in [LISTRQMT], the subject of trust with respect to most aspects of the service involving the exchange of information (submitting a listing request, updating an existing schema listing, or retrieving a schema listing) is not addressed in this document. However, the primary schema listing repository operator will take reasonable steps to ensure that information associated with the service is as accurate and authentic as possible. If users of the schema listing service obtain and use schema from the repository, they SHOULD verify that any fingerprints contained as a part of the listing meta data for external references to related content outside of the repository are valid. This can be verified by computing the MD5 checksum of the referenced content and comparing it with the fingerprint value. If this verification fails, the user of this schema information can assume that this external content has changed after the listing was published. In any case, no repository operator has control over external content referenced by URIs in the meta data. Thus the establishment of trust as it relates to the validity of fingerprints and the content which they represent is the solely user's responsibility and is optional. 4.0 Acknowledgements The format and much of the content in this document is based on [RFC2048]. The engineering team for listing service requirements: Apple, Mealling [Page 12] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 Chris Apple - AT&T Labs Michael Mealling - NSI Sanjay Jain - Oracle John Strassner - Cisco Sam Sun - CNRI Mark Wahl - Critical Angle Chris Weider - Microsoft 4.0 References [FILESYN] C. Apple, "Directory Schema Listing File Name Syntax", INTERNET-DRAFT , October 1997. [GUIDGEN] P. Leach, R. Salz, "UUIDs and GUIDs", INTERNET-DRAFT , February 1997. [GUIDOTHER] Open Group CAE Specification C309 "DCE: Remote Procedure Call", August 1994. [LISTRQMT] C. Apple, "Directory Schema Listing Requirements", INTERNET-DRAFT , October 1997. [METASYN] C. Apple, "A MIME Directory Profile for Schema Listing Meta Data", INTERNET-DRAFT , TBP. [MIMELDAP] M. Wahl, "A MIME Directory Profile for LDAP Schema", INTERNET-DRAFT , October 1997. [MIMEWHOIS] TBP. [MIMERWHOIS] TBP. [RFC2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996. [RFC2048] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1997. 5.0 Authors' Address Chris Apple Room 2F-165 AT&T Laboratories 600 Mountain Ave Murray Hill, NJ 07974 US Apple, Mealling [Page 13] INTERNET-DRAFT Directory Schema Listing Procedures 6 November 1997 Phone: +1 908 582 2409 Fax: +1 908 582 3296 Email: capple@att.com Michael Mealling 505 Huntmar Park Drive Herndon, VA 22070 US Phone: +1 703 742 0400 Fax: +1 703 742 9552 Email: michaelm@rwhois.net This Internet-Draft expires on May 6, 1998. Apple, Mealling [Page 14]