INTERNET-DRAFT C. Apple
<draft-apple-schema-proc-list-00.txt> AT&T Laboratories
Expires: May 6, 1998 M. Mealling
Network Solutions, Inc.
6 November 1997
Directory Schema Listing Procedures
<draft-apple-schema-proc-list-00.txt>
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 <draft-apple-schema-file-list-00.txt>, October 1997.
[GUIDGEN] P. Leach, R. Salz, "UUIDs and GUIDs", INTERNET-DRAFT
<draft-leach-uuids-guids-00.txt>, February 1997.
[GUIDOTHER] Open Group CAE Specification C309 "DCE: Remote Procedure
Call", August 1994.
[LISTRQMT] C. Apple, "Directory Schema Listing Requirements",
INTERNET-DRAFT <draft-apple-schema-rqmts-list-02.txt>, October 1997.
[METASYN] C. Apple, "A MIME Directory Profile for Schema Listing Meta
Data", INTERNET-DRAFT <TBD>, TBP.
[MIMELDAP] M. Wahl, "A MIME Directory Profile for LDAP Schema",
INTERNET-DRAFT <draft-wahl-mime-schema-00.txt>, 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]