Internet DRAFT - draft-apple-schema-proc
draft-apple-schema-proc
Internet Draft C. Apple
Document: draft-apple-schema-proc-00.txt DSI Consulting, Inc.
Expires: December 2003 M. Mealling
Verisign
June 2003
Directory Schema Listing Procedures
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026].
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Apple, Mealling Expires - December 2003 [Page 1]
INTERNET DRAFT Directory Schema Listing Procedures June 2003
Table of Contents
1. Introduction...................................................3
2. Terms and Definitions..........................................3
3. Directory Schema Listing.......................................5
3.1 Schema Listing Request Architecture Diagram................5
3.2 Listing Requirements.......................................6
3.2.1 Functionality Requirements...............................6
3.2.2 Naming Requirements......................................6
3.2.3 Content Formatting and Transfer Encoding Requirements....6
3.2.4 Security Requirements....................................7
3.2.5 Usage and Implementation Non-requirements................8
3.2.6 Publication Requirements.................................8
4. Listing Procedure..............................................9
4.1 Announcement and Community Review..........................9
4.2 Community Review and Assessment...........................10
4.3 Primary Repository Operator Listing.......................10
4.4 Comments on Schema Listings...............................10
4.5 Location of List of Available Schema......................11
4.6 Primary Repository Operator Procedures for Listing Schemas11
4.7 Change Control............................................12
4.8 Listing Request Formats...................................13
4.8.1 Schema Unit Listing Request Format......................13
4.8.2 Schema Pak Listing Request Format.......................14
4.9 Primary Repository Operator Responsibilities & Constraints14
5. Security Considerations.......................................15
6. References....................................................16
6.1 Normative References......................................16
6.2 Informative References....................................16
7. Acknowledgments...............................................17
8. Author's Addresses............................................17
Apple, Mealling Expires - December 2003 [Page 2]
INTERNET DRAFT Directory Schema Listing Procedures June 2003
1. 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
directory service interoperability. Listed schema will be assiged a
permanent, unique listing listing name as a part of the creating
schema listing requests; which starts the schema listing process.
This listing process was defined to ensure that directory service
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 <organization
to be discussed>. The schema listing repository is mirrored to
ensure some level of redundancy for read access.
This document defines schema listing procedures which use the
<organization to be discussed> as the primary listing repository
operator.
2. Terms and Definitions
Information Object - a descriptive abstraction of some real-world
object
Object Attribute - a descriptive property of an information object;
typically, object attributes are defined in terms of semantic and
syntactic definitions
Schema - a collection of definitions for related information objects
Schema Unit - a related or grouped set of object attributes that form
a discrete unit within the context of a schema for a particular
protocol; an example is an LDAP object class
Schema Pak - a related or grouped set of schema units that
collectively specify a schema associated with a particular protocol;
Apple, Mealling Expires - December 2003 [Page 3]
INTERNET DRAFT Directory Schema Listing Procedures June 2003
an example of a schema pak is the set of LDAP object classes
specified in [RFC2256]
Metadata - characteristics that differentiate one schema unit or
schema pak from another; used to catalog listing service content;
structured using a profile of [RFC2927]; also contains references to
files stored within and outside of a listing repository
Schema Unit Content - a formal specification of a schema unit using a
profile of [RFC2927]
Schema Unit Listing - the combination of a single schema unit content
file intended for use within the context of a particular protocol and
a file containing metadata describing the schema unit specified
within that schema unit content file
Schema Pak Listing - a single metadata file containing information
describing and referring to a set of related or grouped schema unit
content files
Repository - a database in which listings are stored
Listing Request - a proposed schema unit listing or schema pak
listing formatted using [MIME] constructs that is submitted for
consideration as a 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 listing and who should be contacted if questions or
concerns arise related to a listing or 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 listing or an alternate contact within the organization
to which the contact person belongs (this allows one person
organizations to list schema)
Apple, Mealling Expires - December 2003 [Page 4]
INTERNET DRAFT Directory Schema Listing Procedures June 2003
3. Directory Schema Listing
3.1 Schema Listing Request Architecture Diagram
Schema Writer
| <--------------schema listing request with
| a permanent, unique listing
| name obtained from the primary
| repository operator
V
Schema Listing Request Review List
|
V
+-----------------------+
|Significant objections | YES
|raised within 2 weeks? |----> Back to the drawing board....
+-----------------------+
| NO (List Moderator recommends that listing
Schema Listing-->| be published subject to comments on list.)
Request V
+-----------------+
|Request meets | NO
|all requirements?| ----> Back to the drawing board....
+-----------------+
| YES
| <-----------------metadata/listing content
V
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 obtain a unique listing name and include it
in the schema listing request sent to a 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 the listing will be
published in the primary listing repository if appropriate. A
Apple, Mealling Expires - December 2003 [Page 5]
INTERNET DRAFT Directory Schema Listing Procedures June 2003
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.
3.2 Listing Requirements
Listing requests are all expected to conform to various requirements
laid out in the following sections.
3.2.1 Functionality Requirements
Schema unit listings MUST include two different types of information:
(1) metadata
(2) schema unit content
Metadata will be used to catalog repository files by characteristics
that differentiate listings.
Schema unit content MUST be limited to the specification of a single
schema unit.
3.2.2 Naming Requirements
All listings MUST have a valid OID as their name.
The primary listing repository operator MUST provide schema writers
with the following components of a listing request name:
+ a sequence number assigned to each listing
by the primary repository operator
+ a version number assigned to each listing
version by the primary repository operator
3.2.3 Content Formatting and Transfer Encoding Requirements
All listings MUST employ a common data format.
Apple, Mealling Expires - December 2003 [Page 6]
INTERNET DRAFT Directory Schema Listing Procedures June 2003
Metadata and schema unit content format and transfer encoding MUST
utilize appropriate [RFC2927] profiles.
Currently, two [RFC2927] profiles have been defined for use in the
schema listing service:
[RFC2927] MUST be used to format and encode LDAPv3 schema unit
content.
[METASYN] MUST be used to format and encode metadata for all
schema unit listings, schema pak listings, and listing requests.
Other [RFC2927] profiles MAY be defined for use in the schema
Listing service; this procedures document will be updated reflect
such changes.
3.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
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 o
a schema listing are:
(1) A listing might include specifications mandating
exposure of certain attributes which would result in
compromising the privacy of an organization or
individual.
(2) A listing might be intended for use by
applications requiring some sort of security
assurances not provided by the schema specified
in the schema unit content or in the schema unit
Apple, Mealling Expires - December 2003 [Page 7]
INTERNET DRAFT Directory Schema Listing Procedures June 2003
content files referenced in a schema pak listing.
3.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 publication of new listings. If a set of schema unit
listings is recommended for a particular application, that should be
asserted by an intended use statement specific for that application
and/or environment withing a schema pak listing metadata file. If a
set of schema pak listings is recommended for a particular
application, that should be asserted by a separate intended use
statement specific for the application and/or environment; or an
additional schema pak listing containing references to all of the
relevant schema unit listings should be created, reviewed, and
published.
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(s).
3.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 mugo
Apple, Mealling Expires - December 2003 [Page 8]
INTERNET DRAFT Directory Schema Listing Procedures June 2003
through the IETF standards process. This is too difficult and to
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.
4. Listing Procedure
The following procedure has been implemented by the primary listing
repository operator for review and approval of new 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 schema unit
content for a particular protocol and/or metadata to the mailing list
ietf-schema-review@pilot.schema.dir.reg.int
as a first step.
4.1 Announcement and Community Review
While listed schema are NOT REQUIRED to be published as RFCs, listing
requests documenting them MUST be posted to the mailing list
ietf-schema-review@pilot.schema.dir.reg.int,
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 (may
require the creation/submission of more than one request) according
to the [RFC2927] profile specified in [RFC2927]. Other such profiles
may be defined elsewhere and this procedures document will be update
to reflect such process changes.
Metadata, as specified in [METASYN], MUST also be included in this
request. A template for listing requests is specified in paragraph
Apple, Mealling Expires - December 2003 [Page 9]
INTERNET DRAFT Directory Schema Listing Procedures June 2003
2.8. Schema writers MUST use this template.
Schema writers MUST also construct a unique listing request name for
each request being created. Listing names are constructed according
to the type valuetype syntax and type special notes for the
'listingName' MIME Directory Type [METASYN].
Once created, the listing request should be sent to
ietf-schema-review@pilot.schema.dir.reg.int.
4.2 Community Review and Assessment
Moderated discussions on the
ietf-schema-review@pilot.schema.dir.reg.int
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.
4.3 Primary Repository Operator Listing
Provided that the schema listing request meets the requirement
defined in paragraph 2.1, the
ietf-schema-review@pilot.schema.dir.reg.int
list moderator will send that listing request to the primary
repository operator, which will check this listing request for
validity, and make the listing available to the community.
4.4 Comments on Schema Listings
Comments on listings 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 contact person for the listing if possible. Submitters of
comments may request that their comment be attached to the listing
itself. If the ietf-schema-review@pilot.schema.dir.reg.int list
Apple, Mealling Expires - December 2003 [Page 10]
INTERNET DRAFT Directory Schema Listing Procedures June 2003
moderator is able to gauge concensus affirming the inclusion of such
a comment, it will be made accessible in conjunction with the listing
itself.
4.5 Location of List of Available Schema
Listings will be posted in the anonymous FTP directory
"ftp://www.pilot.schema.dir.reg.int/schema/" and all listings will be
summarized in a periodically issued RFC. Schema unit content, schema
pak listings, and/or 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 [RFC2223]).
4.6 Primary Repository Operator Procedures for Listing Schemas
Listings will be published by the primary repository operator
automatically and without any formal review as long as the following
minimal conditions are met:
(1) All listings MUST have a valid OID as their name.
(2) All schema unit listing requests MUST include both
metadata and schema unit content.
(3) All schema pak listing requests MUST be limited to
metadata.
(4) Metadata MUST comply with [METASYN].
(5) Schema unit content MUST be compliant with TBD
Other [RFC2927] profiles may be defined in the future and
this document will be updated to reflect such additional
profiles.
(6) 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 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.
(7) Schema listing requests MAY be signed using PGP/MIME
as described in [RFC2015]. The primary listing repository
Apple, Mealling Expires - December 2003 [Page 11]
INTERNET DRAFT Directory Schema Listing Procedures June 2003
operator MUST be able to accept listing requests
in PGP/MIME messages, although they are NOT REQUIRED
to validate or retain the signatures.
(8) Listing request MUST be formatted according to
paragraph 2.8.
(9) If a listing request includes one or more URI-based
references to information that would not be included in a
resulting listing, but is associated with the schema or
schema unit specified by 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 metadata element (as specified in
[METASYN]) if at least one such reference is included in
the request.
4.7 Change Control
Once a 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 listing request on the
ietf-schema-review@pilot.schema.dir.reg.int list.
(2) Leave at least two weeks for comments.
(3) Publish using the primary listing repository
operator after formal review if required.
Changes MAY be requested when there are serious omissions or errors
in the published listing or when other factors which would justify a
change request, such as an emerging need of the user community for a
listed schema which cannot be addressed by that listed schema in its
present form. 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.
The primary listing repository provider SHOULD attempt to verify the
authority of a person claiming to be the contact for a listing, prior
to implementing such changes.
Apple, Mealling Expires - December 2003 [Page 12]
INTERNET DRAFT Directory Schema Listing Procedures June 2003
The contact person for a listing MAY pass responsibility for that
listing to another person or agency by informing the primary listing
repository operator and the
ietf-schema-announce@pilot.schema.dir.reg.int
list; this can be done without discussion or review.
The IESG may reassign responsibility for a listing. The most common
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.
Listings will not be deleted; listings which are no longer believed
appropriate for use can be declared OBSOLETE by a change to their
"intended use" field; such listings will be clearly marked in
repository content summary RFCs published by the primary listing
repository operator.
4.8 Listing Request Formats
4.8.1 Schema Unit Listing Request Format
To: ietf-schema-review@pilot.schema.dir.reg.int
Subject: schema unit listing request
MIME-Version: 1.0
Message-Id: <ids1@wherever.com>
Content-Type: multipart/related; start=3@foo.com; boundary="boundary"
Content-ID: top@foo.com
--boundary
Content-Type: text/directory;
profile="schema-metadata-0";
charset="utf-8"
Content-Transfer-Encoding: Quoted-Printable
Content-ID: 3@foo.com
(metadata 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="<mimedir-profile-type>";
charset="utf-8"
Content-Transfer-Encoding: Quoted-Printable
Content-ID: 3@foo.com
Apple, Mealling Expires - December 2003 [Page 13]
INTERNET DRAFT Directory Schema Listing Procedures June 2003
(a schema specification compliant with a profile of [RFC2927]
corresponding to the value of <mimedir-profile-type>)
--boundary
Where:
<mimedir-profile-type> = "schema-ldap-0" / "schema-whoispp-0" /
"schema-whois-0" / "schema-rwhois-0"
4.8.2 Schema Pak Listing Request Format
To: ietf-schema-review@pilot.schema.dir.reg.int
Subject: schema pak listing request
MIME-Version: 1.0
Message-Id: <ids1@wherever.com>
Content-Type: text/directory;
profile="schema-metadata-0";
charset="utf-8"
Content-Transfer-Encoding: Quoted-Printable
(metadata elements and values as specified in [METASYN] and embedded
in a text/directory MIME component of profile "schema-meta-0")
4.9 Primary Repository Operator Responsibilities & 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
metadata 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 listing request 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.
Apple, Mealling Expires - December 2003 [Page 14]
INTERNET DRAFT Directory Schema Listing Procedures June 2003
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 review committee MAY make a policy decision
on the appropriateness of ads on the repository pages.
5. 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 listing, or
retrieving a 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 listings from
the repository, they SHOULD verify that any fingerprints contained as
a part of metadata for references to related content hosted outside
of the repository are valid. This can be verified by computing the
MD5 checksum [RFC1321] 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
metadata. Thus the establishment of trust as it relates to the
validity of fingerprints and the content which they represent is
solely the user's responsibility and is OPTIONAL.
Apple, Mealling Expires - December 2003 [Page 15]
INTERNET DRAFT Directory Schema Listing Procedures June 2003
6. References
6.1 Normative References
[FILESYN] C. Apple, "Directory Schema Listing File Name Syntax",
INTERNET-DRAFT <draft-apple-schema-reg-file-00.txt>, June 2003.
[LISTRQMT] C. Apple, "Requirements for the Initial Release of a
Directory Schema Listing Service", INTERNET-DRAFT <draft-apple-
schema-reg-rqmts-00.txt>, June 2003.
[METASYN] C. Apple, "A MIME Directory Profile for Schema Listing Meta
Data", INTERNET-DRAFT <draft-apple-schema-reg-metadata-00.txt>, June-
2003.
[RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1630] T. Berners-Lee, "Universal Resource Identifiers in WWW",
RFC 1630, June 1994.
[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", RFC 2119, March 1997.
[RFC2927] M. Wahl, "A MIME Directory Profile for LDAP Schema", RFC
2927, September 2000.
6.2 Informative References
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[RFC2048] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048,
November 1997.
[RFC2223] J. Postel, J. Reynolds, "Instructions to RFC Authors", RFC
2223, October 1997.
Apple, Mealling Expires - December 2003 [Page 16]
INTERNET DRAFT Directory Schema Listing Procedures June 2003
7. Acknowledgments
The format and much of the content in this document is based on
[RFC2048].
The engineering team for listing service requirements:
Chris Apple - DSI Consulting, Inc.
Michael Mealling - Verisign
Sanjay Jain - Oracle
John Strassner - Intelliden
Sam Sun - CNRI
Mark Wahl - Sun Microsystems
Chris Weider - Microsoft
Paul Hoffman for review and comments resulting from his effort to
develop a platform for the initial release of the schema listing
service.
The members of the ietf-schema-reg@imc.org mailing list.
8. Author's Addresses
Chris Apple
DSI Consulting, Inc.
3601 W. Hundred Road
Chester, VA 23831
US
Phone: +1 856 869 0768
Email: capple@dsi-consulting.net
Michael Mealling
Verisign
505 Huntmar Park Drive
Herndon, VA 22070
US
Phone: +1 703 742 0400
Fax: +1 703 742 9552
Email: michaelm@neonym.net
This Internet-Draft expires December 2003.
Apple, Mealling Expires - December 2003 [Page 17]
