INTERNET-DRAFT C. Apple AT&T Laboratories Expires: April 11, 1998 11 October 1997 Directory Schema Listing Requirements 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 requirements for listing directory services schema 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 The fastest route to interoperable directory services is through standard object classes and attribute types. There is a growing number of places where schema for Internet Directory Services and Internet Operations are being defined, with varying degrees of documentation. This plethora of schema 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, Apple [Page 1] INTERNET-DRAFT Directory Schema Listing Requirements 11 October 1997 and thus promote directory service interoperability. The intent is to offer a schema listing service with public read access and restricted, moderated write access. Many hard-coded choices and constraints have been reflected in this requirements document for the purpose of expediting deployment. Future releases of the service may require an update of this document. Initially, such a listing service will be centrally operated, administered, and maintained. The schema listing repository database may also be mirrored to ensure some level of redundancy for read access in the event of service interruption. Eventually, the operations, administration, and maintenance of such a listing service may evolve to use a more distributed deployment scenario. The schema listing service is also intended to be largely automated, with minimal human involvement. Human involvement is likely to be limited to the following types of activities: + handling repository access problems + trouble resolution for computing and communications facilities + dealing with reasonable requests that fall outside of the scope of normal schema listing repository operations + reviewing schema listing requests on a mailing list prior to publishing in the listing repository Future releases of the service may automate some of these tasks. 1.1 Scope Requirements for the initial release of a directory schema listing service are inside the scope of this document. Specifications for syntaxes and grammars to be used in the initial release of the directory schema listing service are outside the scope of this document. Documentation of schema listing procedures is outside the scope of this document. 1.2 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 Apple [Page 2] INTERNET-DRAFT Directory Schema Listing Requirements 11 October 1997 Listing Content - a formal specification, using a single type of syntax, of a schema Schema Listing - the combination of listing meta data and all available syntax types of 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 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. 1.3 Usage Scenarios 1.3.1 Location and Retrieval of the vCard Schema for LDAPv3 A user of the schema listing service wants to locate a copy of the vCard schema for LDAPv3 so that they can use it in a prototyping project. First, they point their web browser at a schema listing repository web site and download the list of available schema. Next, they use the search command on their browser to locate occurences of the string "vCard". The browser automatically scrolls down to the appropriate place in the list of available schema and the user clicks on a link to view the listing meta data to verify that this is indeed the vCard schema for use with version 3 of the LDAP protocol. Included in the web-based representation of the listing meta data are ftp URLs pointing to available syntaxes for this schema. The user clicks on the link for the syntax that they can use. Apple [Page 3] INTERNET-DRAFT Directory Schema Listing Requirements 11 October 1997 1.3.2 Submission of a New Schema Listing via SMTP A schema writer wishes to list a schema they have created and prepares the listing meta data and listing content according to appropriate syntax specifications. However, the schema writer does not currently have an OID at which to root this schema. The schema writer may apply for and obtain an OID through channels other than the schema listing service. However, if the schema writer is unable or does not wish to independently obtain an OID, the primary listing repository operator will supply one. Once this OID is available for use, the schema writer or the listing repository operator incorporates it into the listing meta data and submits an SMTP message includeing the listing meta data and all available syntaxes of the listing content in multipart-mixed MIME format to a listing request review mailing list. After a short review period, the listing repository operator validates the request, and if properly formed, assigns a unique serial number to the listing and publishes it according to the listing procedures. An announcement of the newly published schema listing is sent to a mailing list reserved for this purpose. 2.0 Listing Service Requirements 2.1 Functional Requirements Listed schema MAY be published as an RFC. A list of available schema listings MUST be maintained. Schema MUST be named according to the namespace defined in section 3. Schema listings MUST be identifiable by a unique serial number. The listing service SHALL also maintain information about the schema, beyond its definition. This information is referred to as meta data and will consist of information used for cataloging schema in the listing repositories. The particular set of meta data elements used during the initial deployment of the listing service are outside of the scope of this document. Listing meta data and listing content MUST be parsable. 2.2 Operational Requirements The process of listing schema MUST be centralized for the initial deployment. Apple [Page 4] INTERNET-DRAFT Directory Schema Listing Requirements 11 October 1997 Updated schema listings SHALL be deprecated. A new serial number SHALL be generated for each schema listing that results in the deprecation of an existing schema listing. Schema listing serial numbers MUST NOT be recycled or re-used. The listing repository MUST be centrally administered. The listing repository MAY be mirrored. Schema listing requests MAY be signed using PGP/MIME as described in [RFC2015]. The primary listing repository operator MUST be able to accept schema listing requests in PGP/MIME messages, although they are NOT REQUIRED to validate the signatures. The method for validating and determining trust of signatures is outside the scope of this document and is determined by the parties in the exchange. The method for determining and validating trust in an unsigned request is outside the scope of this document, as is the method for determining trust in schema listing repository or its content. A mailing list MUST be created for the purpose of submitting schema listing requests for publishing in the schema listing repository. The schema listing repository MUST be moderated via this mailing list. Schema listing requests MUST be subjected to community review on this mailing list for a period of at least 2 weeks. If no comments are received, properly formed schema SHALL be listed as requested; otherwise, the request MAY either denied or the schema MAY listed subject to incorporation of comments. A mailing list MUST be created for announcing new and updated schema listings. A mailbox MUST be created for the purpose of receiving service trouble requests from users. Listing repository operators (of primary and shadow sites) MUST provide a free means of accessing the listing service consistent with the functions documented in paragraph 2.3. 2.3 Repository Access Functionality The following schema listing repository access protocols MUST be supported: FTP [RFC959], HTTP 1.1[RFC2044], and SMTP [RFC821]. The following access functions are REQUIRED: a) obtain schema listing content Apple [Page 5] INTERNET-DRAFT Directory Schema Listing Requirements 11 October 1997 b) obtain schema listing meta data c) browse schema listing meta data d) browse schema listing content e) obtain a list of available schema listings f) browse a list of available schema listings g) search a list of available schema listings h) add a schema listing i) update a schema listing The following access functions MAY be supported: a) search schema listing content b) search schema listing meta data 3.0 Listing Service Namespace The listing service namespace MUST be protocol-independent. Names constructed using the listing service namespace MUST be permanent, globally unique, and publicly available. The listing name MUST be the OID at which the schema is rooted. Consider the following example of a schema name for the vCard schema [VCARD]: 1.3.6.1.4.1.2309.1.1.1.1 4.0 Listing Requirements Listing content SHALL be limited to the information actually required to specify the schema. Listing meta data SHALL be composed of information used to catalog schema listings. Meta data element syntax SHALL be defined based on the concept of tagged attribute type-value pairs. Language tags as specified in [RFC1766] MUST be used in listing content and meta data. Meta data element values MUST be encoded using the UCS Transformation Format - 8 bit form [RFC2044]. For the purposes of submitting a listing request, listing content and meta data SHOULD be structured according to appropriate MIME type definitions [MIME]. Apple [Page 6] INTERNET-DRAFT Directory Schema Listing Requirements 11 October 1997 5.0 Listing Storage Requirements Listing file names MUST be permanent, globally unique, and publicly available. Listing content and listing meta data MUST be stored in separate files. 6.0 Security Considerations 6.1 Compromisable Assets One or more of the following assets could be compromised if the service is attacked: + Listing meta data + Listing content + Repository Hardware & Software + Networking Facilities Connecting Repository to the Internet + Repository Mirror Sites 6.2 Attack Scenarios Allowable methods for submitting schema listing requests are: a) sending an e-mail message to a mail box b) submitting requests using web-based forms Based on these request submission methods, there are a number of known repository attack scenarios that must be considered during the implementation of schema listing procedures and the software and operational processes required to support them. 6.2.1 Denial-of-Service Attack Scenarios Scenario A: someone could send in a large number of improperly formed requests Scenario B: someone could send in a large number of properly formed, but frivolous, useless, or trivial requests 6.2.2 Confuse-the-User Attack Scenarios Scenario A: someone could send in a large number of valid, but frivolous, useless, or trivial requests and some or all of these requests actually become listings in the repository Scenario B: someone could maliciously submit one or more slightly Apple [Page 7] INTERNET-DRAFT Directory Schema Listing Requirements 11 October 1997 modified versions of existing schema listings which are popular or widely used 6.3 Security Requirements on Schema Listing Procedures The following contextual definitions apply to the requirements listed in the remainder of this paragraph: Verification - a process of determining authenticity of facts implied or explicitly specified by a contact person during the process of submitting a schema listing request; the methods used to implement such a process MAY or MAY NOT be based on an IETF-sanctioned security protocol; specification of the methods used to implement such a process as well as the trust relationships relevant to the process are outside the scope of this document. High-Quality Directory Schema - a directory schema that serves some useful purpose (e.g., a related set of attribute and object class definitions for holding information about people in a LDAP directory); a schema that is _not_ merely trivial or frivolous (e.g., a trivial schema might consist of a related set of attribute and object class definitions for holding information about the two possible binary bit values in a directory). The schema listing procedures SHOULD be designed to enable: a) verification that all properly formed schema listing requests are submitted by the contact person claiming to originate them c) methods of ensuring that only properly-formed, high-quality directory schema are published in the schema listing repository d) verifcation that requests to change the identity of the contact person for a schema listing originate from the listing authority contact e) coping with the situation in which the contact person and/or listing authority contact for a schema is no longer available or is unable to submit updates to the schema listing for which they hold update authority 7.0 Acknowledgements Leslie Daigle of Bunyip Information Systems and Chris Weider of Microsoft provided valuable comments on multiple versions of this document. The engineering team for listing service requirements: Apple [Page 8] INTERNET-DRAFT Directory Schema Listing Requirements 11 October 1997 Sanjay Jain - Oracle Michael Mealling - NSI John Strassner - Cisco Sam Sun - CNRI Mark Wahl - Critical Angle Chris Weider - Microsoft The members of the ietf-schema-reg@imc.org mailing list. 8.0 References [CHARSET] Internet Assigned Numbers Authority, "CHARACTER SETS", . [LDAPV3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (Version 3)", INTERNET-DRAFT , July 1997. [MIME] [RFC2045], [RFC2046], and [RFC2047]. [RFC821] J. Postel, "Simple Mail Transfer Protocol", RFC 821, Aug-01- 1982. [RFC959] J. Postel, J.K. Reynolds, "File Transfer Protocol", RFC 959, Oct-01-1985. [RFC1766] H. Alvestrand, "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level", March 1997. [RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [RFC2044] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996. [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2046] N. Freed & N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. Apple [Page 9] INTERNET-DRAFT Directory Schema Listing Requirements 11 October 1997 [RFC2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [VCARD] F. Dawson, M. O'Brien, "The vCard Schema For Use In LDAPv3", INTERNET-DRAFT , July 1997. 9.0 Author's Address Chris Apple AT&T Laboratories 600 - 700 Mountain Ave., Room 2F-165 Murray Hill, NJ 07974-0636 USA E-Mail: capple@att.com Phone: +1 908 582 2409 FAX: +1 908 582 3296 This INTERNET-DRAFT expires on April 11, 1998. Apple [Page 10]