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

Versions: 00 01 02 03 04 05 06 07 rfc2425                               
Network Working Group                                        Tim Howes
INTERNET DRAFT                                  University of Michigan

             A MIME Content-Type for Directory Information

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 a MIME Content-Type for holding directory information.
The application/directory Content-Type is defined for holding basic tex-
tual directory information, for example, name,  or  email  address.  The
multipart/mixed  Content-Type  is  used  for  handling  more complicated
situations, in which non-textual information, for example, a  photograph
or sound, must be represented.

3.  Need for a MIME Directory Type

There are several situations in which users of Internet mail may wish to
exchange  directory  information: the email analogy of a "business card"
exchange; the conveyance of directory information to a user having  only
email  access to the Internet; the provision of machine-parsable address
information when purchasing goods or services over the Internet; etc. As
MIME [mime1] is used increasingly by other protocols, most notably HTTP,
it may be useful for these protocols  to  be  able  to  carry  directory
information in MIME format. Such a format, for example, could be used to
represent  URC  (uniform  resource  characteristics)  information  about
resources on the World Wide Web.

Howes                                                           [Page 1]

Expires January 1996                                      INTERNET DRAFT

4.  Overview

The scheme described here for representing directory  information  in  a
MIME  Content-Type  has  two  parts.  First,  the  application/directory
Content-Type is defined for use  in  holding  simple  textual  directory
information,  for example name, title, or email address. The format uses
a simple "type: value" approach, which  should  be  easily  parsable  by
existing  MIME  implementations.  The allowable values for "type", their
correspondence with attributes or fields  in  several  common  directory
services,  and  the  procedure by which new types are defined are given,
along with the formats for "value", their correspondence with values  or
syntaxes  in  several  common  directory  services, and the procedure by
which new values are defined. Many values are represented using the con-
ventions  defined  in RFC 1522 [mime2], allowing multiple character sets
to be used.

Directory entries can include far more than  just  textual  information.
Some  such information (e.g., an image or sound attribute) overlaps with
predefined MIME Content-Type. In these cases  it  may  be  desirable  to
include  the attributes in their well-known MIME formats. This situation
is handled by using a multipart/mixed Content-Type. The first  component
of  this  type is an application/directory body part specifying any tex-
tual  information  in-line,  and  for  information  contained  in  other
Content-Types, the Content-IDs of those types.

5.  The application/directory Content-Type

The application/directory Content-Type is used to hold textual directory
information  and  to  point  to  other  MIME body parts holding non-text
information. It is defined as follows, using the MIME subtype definition
from RFC 1521.

      (1) MIME type name: application

      (2) MIME subtype name: directory

      (3) Required parameters: none

      (4) Optional parameters: charset, source

      Note that the value of the "source" parameter is intended to provide
      the means by which applications knowledgable in the given directory
      service protocol may obtain additional or more up-to-date
      information from the directory service. It contains a URL pointing
      to the directory entry from which the information came. When
      directory information is available from more than one source, the
      sending entity should pick what it considers to be the "best" source.

Howes                                                           [Page 2]

Expires January 1996                                      INTERNET DRAFT

      (5) Encoding considerations: as specified by Content-Transfer-Encoding

      (6) Security considerations: none

      (7) Specification:

      The "application/directory" Content-Type contains directory
      information on one directory entry.  Using the ABNF notation of RFC
      822, the syntax for this content is:

      <content>  ::=  [<type>   ":" <value>]*

      <type>     ::=  "cn" | "sn" | "fn" | "c" | "st" | "l" | "email"
                      | "title" | "fax" | "pager" | "wphone" | "hphone"
                      | "waddress" | "haddress" | "uri" | "o" | "photo"
                      | "type" | "name" | <x-type>

      <x-type>   ::=  <the two characters "X-" or "x-" followed, with no
                       intervening white space, by any token>

      <value>    ::=  a character string whose syntax depends on <type>

      The meanings of the various "types" and the format of the corresponding
      "values" are given below in Table 1. The corresponding types or
      fields in several existing directory services are given in Appendix A.

      type     used to hold            format of values
      waddress work postal address     a sequence of text lines separated
                                         by <CRLF> <space>
      haddress home postal address     a sequence of text lines separated
                                         by <CRLF> <space>
      c        country                 text
      cn       name                    text
      email    RFC 822 email address   an RFC 822 email address
      fax      fax telephone number    text
      fn       first name              text
      l        locality name           text
      o        organization name       text
      pager    pager telephone number  text
      wphone   voice telephone number  text
                 at work
      hphone   voice telephone number  text
                 at home
      image    image                   an RFC 822 msg-id
      sound    sound                   an RFC 822 msg-id
      sn       surname                 text
      st       state or province       text

Howes                                                           [Page 3]

Expires January 1996                                      INTERNET DRAFT

      title    title                   text
      type     type of object          an object type value as defined
                                         in this document, registered with
                                         IANA, or bilaterally agreed upon
                                         (see note below)
      uri      uniform resource
                 identifier            an RFC 1738 URL
      name     directory name          a text version of the object's
                                         directory name
      Table 1. Types, their meanings, and syntaxes.

      Note that text values follow the RFC 822 convention for continued
      lines, except that a "continued" line in an address marks
      the next line of the address, not a continuation of the current line.

      Note that the charset parameter should be used to identify character
      sets other than US ASCII. If different attributes within the same
      "application/directory" body component have different character sets,
      they can both be converted to UNICODE, or another character set
      which is a superset of both.

      Note that the "image" and "sound" types contain a Content-ID and are
      only used in conjunction with the multipart/mixed Content-Type defined
      in the next section.

      The allowable values for the "type" type are listed below.


      Further values may be registered with IANA or bilaterally agreed
      upon. A bilaterally agreed upon value consists of the two characters
      "X-" or "x-" followed, with no intervening white space, by any
      other token.

      Note that the "name" field may or may not be meaningful, depending
      on the source directory service.

      [[ Note that the IANA registration schemes referred to here will be
         defined in a later version of this document. ]]

6.  Use of the multipart/mixed Content-Type

The multipart/mixed Content-Type can be used to hold  directory  entries
containing  both text and non-text information. The first body part must
have a Content-Type of "application/directory". This  part  defines  the
name  and source of the information, holds any text information from the
entry, and makes reference to subsequent  body  parts  holding  non-text

Howes                                                           [Page 4]

Expires January 1996                                      INTERNET DRAFT

directory information via their Content-IDs.

The body parts referred to do not have to be in any particular order, as
long  as  they  come after the "application/directory" part referring to

7.  Examples

The    following    example    illustrates    simple    use    of    the
"application/directory" Content-Type.

      From: Whomever
      To: Someone
      Subject: whatever
      MIME-Version: 1.0
      Message-ID: <id1@host.net>
      Content-Type: application/directory
      Content-ID: <id2@host.com>

      cn: Babs Jensen
      cn: Barbara J Jensen
      sn: Jensen
      email: babs@umich.edu
      wphone: +1 313 747-4454

The next example illustrates the use of RFC  1522  encoding  to  include
non-ascii characters in some of the information returned, and the use of
the optional "name" and "source" parameters.

      Content-Type: application/directory;
      Content-ID: <id3@host.com>
      Content-Transfer-Encoding: Quoted-Printable

      cn: Bj=F8rn Jensen
      waddress: 535 W. William St.
                Ann Arbor, MI 48103
      sn: Jensen
      email: bjorn@umich.edu
      wphone: +1 313 747-4454

The final example illustrates the use of  the  multipart/mixed  Content-
Type to include non-textual directory data.

      Content-Type: multipart/mixed; boundary=woof
      Content-ID: <id4@host.com>

Howes                                                           [Page 5]

Expires January 1996                                      INTERNET DRAFT

      Content-Type: application/directory;
      Content-ID: <id5@host.com>
      Content-Transfer-Encoding: Quoted-Printable

      cn: Bj=F8rn Jensen
      sn: Jensen
      email: bjorn@umich.edu
      image: <id6@host.com>
      sound: <id7@host.com>
      wphone: +1 313 747-4454
      name: cn=3DBjorn Jensen, o=3DUniversity of Michigan,c=3DUS

      Content-Type: image/jpeg
      Content-ID: <id6@host.com>

      <...image data...>

      Content-Type: message/external-body;

      Content-Type: audio/basic
      Content-ID: <id7@host.com>


8.  Security Considerations

Internet mail is subject to many well known security attacks,  including
monitoring,  replay,  and forgery. Applications should also take care to
display directory data in a "safe" environment (e.g.,  PostScript-valued

9.  Bibliography

[ldap1]   Yeong, W., Howes, T., Kille, S., "Lightweight Directory Access
          Protocol", Request for Comment (RFC) 1777, March 1995.

[ldap2]   Howes, T., Kille, S., Yeong, W., Robbins,  C.J.,  "The  String
          Representation  of  Standard  Attribute Syntaxes", Request for

Howes                                                           [Page 6]

Expires January 1996                                      INTERNET DRAFT

          Comment (RFC) 1778, March 1995.

[rfc822]  Crocker, D., "Standard for the Format of  ARPA  Internet  Text
          Messages", STD 11, RFC 822, August 1982.

[mime1]   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

[mime2]   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.

10.  Author's Address

   Tim Howes
   University of Michigan
   ITD Research Systems
   535 W William St.
   Ann Arbor, MI 48103-4943
   +1 313 747-4454

11.  Appendix A - Correspondence With Various Directory Services

                name in                   name in              name in
      type      LDAP/X.500                SOLO                 WHOIS++
      waddress  postalAddress             Work-address         Work-Postal
      haddress  homePostalAddress                              Home-Postal
      c         friendlyCountryName,co    C                    Country
      cn        commonName,cn             Name,CommonName      Name
      email     rfc822Mailbox,mail        Email-address,       Email
      fax       facsimileTelephoneNumber  Fax-telephone        Work-Fax,
      fn        givenName                 First name
      l         localityName,l            LocalityName
      o         organizationName,o        Organization         Organization-Name
      pager     pagerTelephoneNumber,

Howes                                                           [Page 7]

Expires January 1996                                      INTERNET DRAFT

      wphone    telephoneNumber           Work-telephone       Work-Phone
      hphone    homeTelephoneNumber                            Home-Phone,
      photo     jpegPhoto,photo
      sn        surname,sn                Surname
      st        stateOrProvinceName,st    StateOrProvinceName  State
      title     title,personalTitle       Title                Title
      type      objectClass               Template             Template-Type
      uri       labeledURI                                     Description-URI

Howes                                                           [Page 8]