Network Working Group Tim Howes
INTERNET DRAFT University of Michigan
draft-ietf-asid-mime-direct-00.txt
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.
"person"
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
them.
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;
charset="iso-8859-1";
source="ldap://cn=Bjorn%20Jensen,o=University%20of%20Michigan,c=US"
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
--woof
Content-Type: application/directory;
charset="iso-8859-1";
source="ldap://cn=Bjorn%20Jensen,o=University%20of%20Michigan,c=US"
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
--woof
Content-Type: image/jpeg
Content-ID: <id6@host.com>
<...image data...>
--woof
Content-Type: message/external-body;
name="myvoice.au";
site="myhost.com";
access-type=ANON-FTP;
directory="pub/myname";
mode="image"
Content-Type: audio/basic
Content-ID: <id7@host.com>
--woof--
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
attributes).
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
1993.
[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
USA
+1 313 747-4454
tim@umich.edu
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
c,countryName
cn commonName,cn Name,CommonName Name
email rfc822Mailbox,mail Email-address, Email
rfc822Mailbox
fax facsimileTelephoneNumber Fax-telephone Work-Fax,
Home-Fax
fn givenName First name
l localityName,l LocalityName
o organizationName,o Organization Organization-Name
pager pagerTelephoneNumber,
pager
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]
