[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
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]