Internet DRAFT - draft-ietf-asid-direct
draft-ietf-asid-direct
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 00:51:22 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Thu, 27 Jul 1995 22:00:00 GMT
ETag: "2e9d0e-383a-30180c60"
Accept-Ranges: bytes
Content-Length: 14394
Connection: close
Content-Type: text/plain
Network Working Group Tim Howes
INTERNET DRAFT University of Michigan
A MIME Content-Type for Directory Information
<draft-ietf-asid-direct-00.txt>
1. Status of this Memo
This memo provides information for the Internet community. The scheme it
describes will be presented to the IETF ASID working group, and upon
approval, publication will be pursued as an Internet standard RFC.
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.
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
Howes [Page 1]
RFC DRAFT August 1995
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: 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.
(5) Encoding considerations: 7bit preferred
(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>]*
Howes [Page 2]
RFC DRAFT August 1995
<type> ::= "cn" | "sn" | "fn" | "c" | "st" | "l" | "email"
| "title" | "address" | "phone" | "fax" | "pager"
| "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
--------------------------------------------------------------------
address postal address a sequence of RFC 1522 encoded text
lines separated by <CRLF> <space>
c country RFC 1522 encoded text
cn name RFC 1522 encoded text
email RFC 822 email address an RFC 822 email address
fax fax telephone number RFC 1522 encoded text
fn first name RFC 1522 encoded text
l locality name RFC 1522 encoded text
o organization name RFC 1522 encoded text
pager pager telephone number RFC 1522 encoded text
phone voice telephone number RFC 1522 encoded text
image image an RFC 822 msg-id
sound sound an RFC 822 msg-id
sn surname RFC 1522 encoded text
st state or province RFC 1522 encoded text
title title RFC 1522 encoded 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 an RFC 1522 encoded text version of
the object's directory name
--------------------------------------------------------------------
Table 1. Types, their meanings, and syntaxes.
Note that address values follow the same convention as continued
RFC 1522 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 RFC 1522 defines a scheme for representing text in character
Howes [Page 3]
RFC DRAFT August 1995
sets other than ASCII.
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
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
Howes [Page 4]
RFC DRAFT August 1995
cn: Barbara J Jensen
sn: Jensen
email: babs@umich.edu
phone: +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;
name="cn=Bjorn Jensen, o=University of Michigan, c=US";
source="ldap";
Content-ID: <id3@host.com>
cn: =?ISO-8859-1?Q?Bj=F8rn_Jensen?=
sn: Jensen
email: bjorn@umich.edu
phone: +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>
--woof
Content-Type: application/directory;
name="cn=Bjorn Jensen, o=University of Michigan, c=US";
source="x500";
Content-ID: <id5@host.com>
cn: =?ISO-8859-1?Q?Bj=F8rn_Jensen?=
sn: Jensen
email: bjorn@umich.edu
image: <id6@host.com>
sound: <id7@host.com>
phone: +1 313 747-4454
--woof
Content-Type: image/jpeg
Content-ID: <id6@host.com>
<...image data...>
--woof
Content-Type: message/external-body;
name="myvoice.au";
site="myhost.com";
Howes [Page 5]
RFC DRAFT August 1995
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
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
Howes [Page 6]
RFC DRAFT August 1995
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++
--------------------------------------------------------------------
address postalAddress, Work-address Address
homePostalAddress
c friendlyCountryName,co C C
c,countryName
cn commonName,cn Name,CommonName CN
email rfc822Mailbox,mail Email-address, Email
rfc822Mailbox
fax facsimileTelephoneNumber Fax-telephone Fax
fn givenName First name First
l localityName,l LocalityName L
o organizationName,o Organization O
pager pagerTelephoneNumber,
pager
phone telephoneNumber,
homeTelephoneNumber Work-telephone Phone
photo jpegPhoto,photo
sn surname,sn Surname S
st stateOrProvinceName,st StateOrProvinceName ST
title title,personalTitle Title Title
type objectClass Template Template
uri labeledURI
Howes [Page 7]
