Network Working Group Tim Howes INTERNET DRAFT Mark Smith draft-ietf-asid-mime-centroid-00.txt University of Michigan An Application/Directory MIME Content-Type Centroid Profile 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments 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). 2. Abstract This memo defines an directory profile for carrying centroid or other indexing information pertaining to one or more directory entities within an application/directory MIME Content-Type. The profile consists of type definitions, what the types are allowed to contain, and rules for their use and interpretation within the application/directory body part. The scheme is fairly general and with a few extensions could be used to handle directory modification information pertaining to a single entity, or sets of modifications pertaining to many entries, in addition to updates to centroid or other index information that apply to many enti- ties. 3. Overview The application/directory MIME Content-Type defined in [MIME-DIR] is used for representing directory information in MIME format. It defines a general framework for carrying "type: value"-style information in the body part, but does not define specific types or values. This document defines a profile containing the types and corresponding value formats Howes & Smith [Page 1] Expires July 1996 INTERNET DRAFT for representing centroid or other directory indexing information. The goal of this scheme is to represent changes to directory information to support indexing. In this scheme, a directory server might send a MIME message containing centroid or other indexing information to one or more other servers providing wide-area search service. The wide-area search server can use the index information to provide efficient searches over many servers, contacting only those servers likely to be able to answer a query. The scheme described here defines types and profiles for representing changes to centroid or other indexing information within an application/directory MIME content type. Types are defined for representing the type of update and the specific update to be performed. 4. The Centroid Profile This profile is used to represent a change to a directory centroid or other collection of index information. The profile is defined as fol- lows, using the profile registration template from Section 8 of [MIME- DIR]. 4.1. Centroid Profile Definition To: ietf-mime-direct@umich.edu Subject: Registration of application/directory MIME profile centroid Profile name: centroid Profile purpose: to hold information about a change to a centroid or other collection of index information Profile types: time, changetype, indextype, indexparm Profile special notes: The types used in the centroid profile must adhere to a specific ordering. If given, the "time" line must come first, followed by one or more "changetype" lines. The ordering is given by the fol- lowing grammar. changelist := changelist changes | changes changes := [ time CRLF ] [ indextype CRLF ] [ indexparm CRLF ] 1*( change CRLF ) time := "time" ":" date-time ; from Section 5.1 of [RFC-822] (see below) Howes & Smith [Page 2] Expires July 1996 INTERNET DRAFT indextype := "indextype" ":" ( "word" / "value" / x-token ) indexparm := "indexparm" ":" ( "weights" / x-token ) change := "changetype" ":" changeinfo changeinfo := "add" CRLF mods / "delete" CRLF [ mods ] / "replace" CRLF mods mods := content ; from Section 5 of [MIME-DIR] Changes to multiple index entities may be included in the same MIME message by specifying multiple application/directory body parts wrapped inside a multipart/parallel body part. The name and source of the centroid can optionally be taken from the application/directory MIME Content-Type "name" and "source" header parameters. The associated type definitions follow, using the type registration tem- plate from Section 9 of [MIME-DIR]. 4.2. Time Type Definition To: ietf-mime-direct@umich.edu Subject: Registration of application/directory MIME type time Type name: time Type purpose: to hold a time. Type encoding: a string containing a time as defined in section 5.1 of [RFC-822] for "date-time". 4.3. Changetype Type Definition To: ietf-mime-direct@umich.edu Subject: Registration of application/directory MIME type changetype Type name: changetype Type purpose: to hold the type of change to make to the named direc- tory entity Type encoding: one of the strings "add", "delete", or "replace". Type special notes: Howes & Smith [Page 3] Expires July 1996 INTERNET DRAFT The changetypes have the following meanings, which pertain to sub- sequent information in the application/directory body part. Also given are the subsequent information the body part must contain to accomplish the change. add Add additional index information, or create the informa- tion if none yet exists. The "changetype: add" line is followed by one or more "type: value" lines indicating the information to add. delete Delete existing index information. If the "changetype: delete" line is not followed by any additional parame- ters (i.e., the end of the body part, or the next change record comes next), the entire set of index information is to be deleted. Otherwise, additional "type: value" lines follow indicating the index values to be removed from the index information. replace Change an existing set of index information by replacing any information currently in the index, or creating a new index if none yet exists. The "changetype: replace" line is followed by one or more "type: value" lines indicating the information that should be placed in the index in place of any existing information with the same type name. Types that are not mentioned are not changed. 4.4. Indextype Type Definition To: ietf-mime-direct@umich.edu Subject: Registration of application/directory MIME type indextype Type name: indextype Type purpose: to hold the type of index information contained in the body part Type encoding: a string defined as follows. indextype := x-token / "word" / "value" x-token := The "x-token" indextype construct is to be used for bilaterally agreed upon types of index information. Type special notes: Howes & Smith [Page 4] Expires July 1996 INTERNET DRAFT The "indextype" line is used to indicate the type of index infor- mation contained in the body part. A value of "word" indicates that values are LWSP-delimited words. A value of "value" indicates that values are entire values. Future versions of this document may define other values for this parameter. 4.5. Indexparm Type Definition To: ietf-mime-direct@umich.edu Subject: Registration of application/directory MIME type indexparm Type name: indexparm Type purpose: to hold additional parameters describing the type of index information contained in the body part. Type encoding: a string defined as follows. indexparm := x-token / "weights" x-token := The "x-token" indexparm construct is to be used for bilaterally agree upon types of index information. Type special notes: The "indexparm" line is used to indicate any additional informa- tion transmitted with the index. A value of "weights" indicates that values are accompanied by weights indicating their relative frequencies in the source data. A future version of this document may define additional values of this parameter and will define the use of the "weights" parameter in more detail. 5. Centroid Examples The following example illustrates simple use of the application/directory MIME Content-Type with the "centroid" profile, for value-based index information. Note the use of the "changetype: add" line to indicate that the index information is an update to existing information. From: Whomever To: Someone Subject: whatever MIME-Version: 1.0 Message-ID: Howes & Smith [Page 5] Expires July 1996 INTERNET DRAFT Content-Type: application/directory; profile="centroid"; source="ldap://ldap.itd.umich.edu/o=U%20of%20M" Content-ID: time: Wed, 10 Jan 1996 09:45:38 EST indextype: value changetype: add cn: Babs Jensen cn: Barbara Jensen cn: Bjorn Jensen cn: Bob Jensen The next example illustrates the use of the "centroid" profile for word-based index information. Note the use of the "defaulttype" parame- ter to avoid duplicating type names, and the "changetype: replace" line to indicate the index information should be replaced, instead of updated. From: Whomever To: Someone Subject: whatever MIME-Version: 1.0 Message-ID: Content-Type: application/directory; profile="centroid"; source="ldap://ldap.itd.umich.edu/o=U%20of%20M"; defaulttype="cn" Content-ID: time: Wed, 10 Jan 1996 09:45:38 EST indextype: value changetype: replace : Jensen : Babs : Barbara : Bjorn : Bob 6. Security Considerations Internet mail is subject to many well known security attacks, including monitoring, replay, and forgery. Applications should also be aware that there may be privacy and security implications associated with releasing index information. Howes & Smith [Page 6] Expires July 1996 INTERNET DRAFT 7. Acknowledgements This material is based upon work supported by the National Science Foun- dation under Grant No. NCR-9416667. 8. Bibliography [RFC-1777]Yeong, W., Howes, T., Kille, S., "Lightweight Directory Access Protocol", Request for Comment (RFC) 1777, March 1995. [RFC-1778]Howes, T., Kille, S., Yeong, W., Robbins, C.J., "The String Representation of Standard Attribute Syntaxes", Request for Comment (RFC) 1778, March 1995. [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. [RFC-1521]Borenstein, N., Freed, N., "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, September 1993. [RFC-1522]Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522, September 1993. [x500] "Information Processing Systems - Open Systems Interconnection - The Directory: Overview of Concepts, Models and Services", ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988. [RFC-1835]Deutsch, P., Schoultz, R., Faltstrom, P., Weider, C., "Archi- tecture of the WHOIS++ service", August 1995. [MIME-DIR]Howes, T., Smith, M., "A MIME Content-Type for Directory Information," Internet-Draft draft-ietf-asid-mime-direct- 01.txt, January, 1996. [RFC-1738]Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource Locators (URL)", RFC 1738, December 1994. 9. Author's Address Tim Howes University of Michigan 535 W William St. Ann Arbor, MI 48103-4943 USA +1 313 747-4454 Howes & Smith [Page 7] Expires July 1996 INTERNET DRAFT tim@umich.edu Mark Smith University of Michigan 535 W William St. Ann Arbor, MI 48103-4943 USA +1 313 764-2277 mcs@umich.edu Howes & Smith [Page 8]