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 two characters "X-" or "x-" followed, with
no intervening white space, by any 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 two characters "X-" or "x-" followed, with
no intervening white space, by any 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: <id1@host.net>
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: <id2@host.com>
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: <id1@host.net>
Content-Type: application/directory;
profile="centroid";
source="ldap://ldap.itd.umich.edu/o=U%20of%20M";
defaulttype="cn"
Content-ID: <id2@host.com>
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]
