Network Working Group Tim Howes
INTERNET DRAFT Mark Smith
draft-ietf-asid-mime-direct-01.txt 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 document defines a MIME Content-Type for holding directory informa-
tion. The definition is independent of any particular directory ser-
vice. The application/directory Content-Type is defined for holding a
variety of basic textual directory information, for example, name, or
email address. The application/directory Content-Type can also be used
as the root body part in a multipart/related Content-Type for handling
more complicated situations in which non-textual information, for exam-
ple, a photograph or sound, must be represented.
The application/directory Content-Type defines a general framework and
format for holding directory information in a simple "type: value" for-
mat. This document also defines the procedure by which particular for-
mats for carrying application-specific information within an
application/directory Content-Type may be defined and registered, and
the conventions such formats must follow. It is expected that other
documents will be produced that define such formats for various applica-
tions (e.g., white pages).
Howes & Smith [Page 1]
Expires July 1996 INTERNET DRAFT
3. Need for a MIME Directory Type
For purposes of this document, a directory is a special-purpose database
that contains typed information. A directory usually supports both read
and search of the information it contains, and may support modification
of the information as well. Directory information is usually accessed
far more often than it is updated. Directories may be local or global
in scope. They may be distributed or centralized. The information they
contain may be replicated, with weak or strong consistency requirements.
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-parseable address
information when purchasing goods or services over the Internet; etc. As
MIME [RFC-1521,RFC-1522] 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 defined 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 and understandable by users. This document defines the
general form the information in the Content-Type should take, and the
procedure by which specific types and values for particular applications
may be defined. The framework is general enough to handle information
from any number of end directory services, including LDAP [RFC-1777,
RFC-1778], WHOIS++ [RFC-1835], and X.500 [x500].
Directory entries can include far more than just textual information.
Some such information (e.g., an image or sound) overlaps with predefined
MIME Content-Types. In these cases it may be desirable to include the
information in their well-known MIME formats. This situation is handled
by using a multipart/related Content-Type as defined in [RFC-1872]. The
root component of this type is an application/directory body part speci-
fying any textual 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 supplementary
Howes & Smith [Page 2]
Expires July 1996 INTERNET DRAFT
or non-textual directory information, such as an image or sound. It is
defined as follows, using the MIME media type registration template from
[MIME-REG].
To: ietf-types@uninett.no
Subject: Registration of MIME media type application/directory
MIME media type name: application
MIME subtype name: directory
Required parameters: none
Optional parameters: charset, source, profile, name, defaulttype
The "charset" parameter is as defined in [RFC-1521] for other body
parts.
The "source" parameter is used 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 as defined in [RFC-1738]
pointing to the directory entity or entities to which the informa-
tion pertains. When directory information is available from more
than one source, the sending entity should pick what it considers
to be the best source.
The "profile" parameter is used to convey the type of entity to
which the directory information pertains and the likely set of
information associated with the entity. It is intended only as a
guide to applications interpreting the information contained
within the body part. It should not be used to exclude or require
particular pieces of information. The value of the "profile"
parameter is defined as follows. Note that profile names are case
insensitive (i.e., the profile name "Person" is the same as "PER-
SON" and "person" and "peRsOn").
profile := x-token / iana-token
x-token := <The two characters "X-" or "x-" followed,
with no intervening white space, by any token>
iana-token := <a publicly-defined extension token, registered
with IANA, as specified in Section 8 of this
document>
The "name" parameter is used to convey the directory name of the
entity to which the directory information pertains. Its value is
Howes & Smith [Page 3]
Expires July 1996 INTERNET DRAFT
an ASCII string representing the name. Note that this string may
be protocol-specific and is intended for applications knowledgable
in a particular directory service protocol.
The "defaulttype" parameter is used as a space-saving optimization
for applications that need to represent large numbers of values of
the same type. The value of this parameter is the assumed type in
the "type: value" constructs found in the body part (see below) if
the "type" portion is omitted.
Encoding considerations:
As specified by the Content-Transfer-Encoding header field.
Security considerations:
Directory information may be public or it may be protected from
unauthorized access by the directory service in which it resides.
Once the information leaves its native service, there can be no
guarantee that the same care will be taken by all services han-
dling the information. Furthermore, this specification defines no
access control mechanism by which information may be protected, or
by which access control information may be conveyed.
Interoperability considerations:
In order to make sense of directory information, applications must
share a common understanding of the types of information contained
within the Content-Type. These types are not defined in this docu-
ment, but rather in companion documents that follow the require-
ments specified in this document, or in bilateral agreements.
Published specification:
The "application/directory" Content-Type contains textual direc-
tory information, typically pertaining to a single directory
entity or group of entities. The content consists of one or more
CRLF-separated lines in the following format. An
application/directory content line has the same continuation
semantics as described in RFC 822 in section 3.1.1 on "folding"
long header lines (i.e., a single line may be split across multi-
ple physical lines by replacing linear-white-space with a CRLF
immediately followed by at least one LWSP-character). Using the
notation of RFC 822, the syntax for this content is:
content := attrvalue / attrcid
attrvalue := [type] ":" SPACE [value]
Howes & Smith [Page 4]
Expires July 1996 INTERNET DRAFT
attrcid := [type] "::" SPACE msg-id ; a Message-ID as in RFC 822
type := x-token / iana-token
x-token := <the two characters "X-" or "x-" followed, with
no intervening white space, by any token>
iana-token := <a publicly-defined extension token, registered
with IANA, as specified in Section 9 of this
document>
value := *text ; characters whose syntax depends on type
Note that the meanings of the various types and the format of the
corresponding values are defined as specified in Section 9.
Specifications may impose ordering on the type constructs within a
body part, though none is required by default. The x-token type
specification is used for bilaterally-agreed upon types.
Note that the type names are case insensitive (i.e., the type name
"cn" is the same as "CN" and "Cn"). A type name may be absent only
if a "defaulttype" parameter has been given in the header for the
body part. In this case, the type name assumed is that given in
the "defaulttype" parameter.
Note that the "charset" parameter should be used to identify char-
acter sets other than US ASCII. If different information within
the same application/directory body component have different char-
acter sets, they can both be converted to UNICODE, or another
character set which is a superset of both.
Note that if a type name is followed by the two characters "::",
the value is assumed to be a Content-ID referencing the actual
value, and the application/directory body part must be used in
conjunction with the multipart/related Content-Type defined in the
next section.
Person & email address to contact for further information:
Tim Howes
University of Michigan
535 W. William St.
Ann Arbor, MI 48103
tim@umich.edu
+1 313 747-4454
Intended usage: COMMON
Howes & Smith [Page 5]
Expires July 1996 INTERNET DRAFT
Author/Change controller:
Tim Howes
University of Michigan
535 W. William St.
Ann Arbor, MI 48103
tim@umich.edu
+1 313 747-4454
Mark Smith
University of Michigan
535 W. William St.
Ann Arbor, MI 48103
mcs@umich.edu
+1 313 764-2277
6. Use of the multipart/related Content-Type
The multipart/related Content-Type can be used to hold directory infor-
mation comprised of both text and non-text information or directory
information that already has a natural MIME representation. The root
body part within the multipart/related body part is specified as defined
in [RFC-1872] by a "start" parameter, or it is the first body part in
the absence of such a parameter. The root body part must have a
Content-Type of "application/directory". This part holds text informa-
tion, optionally defines the name and source of the information, and
makes reference to subsequent body parts holding additional text or
non-text directory information via their Content-IDs as explained in
Section 5.
The body parts referred to do not have to be in any particular order,
except as noted above for the root body part.
7. Examples
The following examples are for illustrative purposes only and are not
part of the definition. The first example illustrates simple use of the
application/directory Content-Type. Note that no "profile" parameter is
given, so an application may not know what kind of directory entity the
information applies to. Note also the use of both hypothetical official
and bilaterally agreed upon types.
From: Whomever
To: Someone
Subject: whatever
MIME-Version: 1.0
Message-ID: <id1@host.net>
Content-Type: application/directory
Howes & Smith [Page 6]
Expires July 1996 INTERNET DRAFT
Content-ID: <id2@host.com>
cn: Babs Jensen
cn: Barbara J Jensen
sn: Jensen
email: babs@umich.edu
phone: +1 313 747-4454
x-id: 1234567890
The next example illustrates the use of the Quoted-Printable encoding
defined in [RFC-1522] to include non-ASCII characters in some of the
information returned, and the use of the optional "name" and "source"
parameters. Note the use of the "person" profile, as defined in [MIME-
WPP].
Content-Type: application/directory;
charset="iso-8859-1";
source="ldap://cn=Bjorn%20Jensen,o=University%20of%20Michigan,c=US";
name="cn=Bjorn Jensen, o=Universityr ofr Michigan, c=US";
profile="person"
Content-ID: <id3@host.com>
Content-Transfer-Encoding: Quoted-Printable
cn: Bj=F8rn Jensen
sn: Jensen
email: bjorn@umich.edu
phone: +1 313 747-4454
The final example illustrates the use of the multipart/related Content-
Type to include non-textual directory data.
Content-Type: multipart/related;
boundary=woof;
type="application/directory";
start="<id5@host.com>"
Content-ID: <id4@host.com>
--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>
Howes & Smith [Page 7]
Expires July 1996 INTERNET DRAFT
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";
access-type=ANON-FTP;
directory="pub/myname";
mode="image"
Content-Type: audio/basic
Content-ID: <id7@host.com>
--woof--
8. Registration of new profiles
This section defines procedures by which new profiles are registered
with the IANA and made available to the Internet community. Note that
non-IANA profiles may be used by bilateral agreement, provided the asso-
ciated profile names follow the "X-" convention defined above.
The procedures defined here are designed to allow public comment and
review of new profiles, while posing only a small impediment to the
definition of new profiles.
Registration of a new profile is accomplished by the following steps.
8.1. Define the profile
A profile is defined by completing the following template.
To: ietf-mime-direct@umich.edu
Subject: Registration of application/directory MIME profile XXX
Profile name:
Profile purpose:
Profile types:
Howes & Smith [Page 8]
Expires July 1996 INTERNET DRAFT
Profile special notes (optional):
Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
The explanation of what goes in each field in the template follows.
Profile name: The name of the profile as it will appear in the
application/directory MIME Content-Type "profile" header parameter.
Profile purpose: The purpose of the profile (e.g., to represent informa-
tion about people, printers, documents, etc.). Give a short but clear
description.
Profile types: The list of types associated with the profile. This list
of types is to be expected but not required in the profile. Other types
not mentioned in the profile definition may also be present. Note that
any new types referenced by the profile must be defined separately as
described in Section 9.
Profile special notes: Any special notes about the profile, how it is to
be used, etc. This section of the template may also be used to define an
ordering on the types that appear in the Content-Type, if such an order-
ing is required.
8.2. Post the profile definition
The profile description must be posted to the new profile discussion
list, ietf-mime-direct@umich.edu.
8.3. Allow a comment period
Discussion on the new profile must be allowed to take place on the list
for a minimum of two weeks. Consensus must be reached on the profile
before proceeding to step 4.
8.4. Submit the profile for approval
Once the two-week comment period has elapsed, and the proposer is con-
vinced consensus has been reached on the profile, the registration
application should be submitted to the Profile Reviewer for approval.
The Profile Reviewer is appointed to the Application Area Directors and
may either accept or reject the profile registration. An accepted regis-
tration should be passed on by the Profile Reviewer to the IANA for
inclusion in the official IANA profile registry. The registration may be
rejected for any of the following reasons. 1) Insufficient comment
period; 2) Consensus not reached; 3) Technical deficiencies raised on
the list or elsewhere have not been addressed. The Profile Reviewer's
decision to reject a profile may be appealed by the proposer to the
Howes & Smith [Page 9]
Expires July 1996 INTERNET DRAFT
IESG, or the objections raised can be addressed by the proposer and the
profile resubmitted.
9. Profile Change Control
Existing profiles may be changed using the same process by which they
were registered.
Define the change
Post the change
Allow a comment period
Submit the profile for approval
Note that the original author or any other interested party may propose
a change to an existing profile, but that such changes should only be
proposed when there are serious omissions or errors in the published
specification. The Profile Reviewer may object to a change if it is not
backwards compatible, but is not required to do so.
Profile definitions can never be deleted from the IANA registry, but
profiles which are nolonger believed to be useful can be declared
OBSOLETE by a change to their "intended use" field.
10. Registration of new types
This section defines procedures by which new types are registered with
the IANA. Note that non-IANA types may be used by bilateral agreement,
provided the associated types names follow the "X-" convention defined
above.
The procedures defined here are designed to allow public comment and
review of new types, while posing only a small impediment to the defini-
tion of new types.
Registration of a new type is accomplished by the following steps.
10.1. Define the type
A type is defined by completing the following template.
To: ietf-mime-direct@umich.edu
Subject: Registration of application/directory MIME type XXX
Type name:
Howes & Smith [Page 10]
Expires July 1996 INTERNET DRAFT
Type purpose:
Type encoding:
Type special notes (optional):
Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
The meaning of each field in the template is as follows.
Type name: The name of the type, as it will appear in the body of an
application/directory MIME Content-Type "type: value" line to the left
of the colon ":".
Type purpose: The purpose of the type (e.g., to represent a name, postal
address, IP address, etc.). Give a short but clear description.
Type encoding: The encoding a value of the type must have in the body of
an application/directory MIME Content-Type. This description must be
precise and must not violate the general encoding rules defined in sec-
tion 5 of this document.
Type special notes: Any special notes about the type, how it is to be
used, etc.
10.2. Post the type definition
The type description must be posted to the new type discussion list,
ietf-mime-direct@umich.edu.
10.3. Allow a comment period
Discussion on the new type must be allowed to take place on the list for
a minimum of two weeks. Consensus must be reached on the type before
proceeding to step 4.
10.4. Submit the type for approval
Once the two-week comment period has elapsed, and the proposer is con-
vinced consensus has been reached on the type, the registration applica-
tion should be submitted to the Profile Reviewer for approval. The Pro-
file Reviewer is appointed to the Application Area Directors and may
either accept or reject the type registration. An accepted registration
should be passed on by the Profile Reviewer to the IANA for inclusion in
the official IANA profile registry. The registration may be rejected for
any of the following reasons. 1) Insufficient comment period; 2) Con-
sensus not reached; 3) Technical deficiencies raised on the list or
elsewhere have not been addressed. The Profile Reviewer's decision to
Howes & Smith [Page 11]
Expires July 1996 INTERNET DRAFT
reject a type may be appealed by the proposer to the IESG, or the objec-
tions raised can be addressed by the proposer and the type resubmitted.
11. Type Change Control
Existing types may be changed using the same process by which they were
registered.
Define the change
Post the change
Allow a comment period
Submit the type for approval
Note that the original author or any other interested party may propose
a change to an existing type, but that such changes should only be pro-
posed when there are serious omissions or errors in the published
specification. The Profile Reviewer may object to a change if it is not
backwards compatible, but is not required to do so.
Type definitions can never be deleted from the IANA registry, but types
which are nolonger believed to be useful can be declared OBSOLETE by a
change to their "intended use" field.
12. Security Considerations
Internet mail is subject to many well known security attacks, including
monitoring, replay, and forgery. Care should be taken by any directory
service in allowing information to leave the scope of the service
itself, where any access controls can no longer be guaranteed. Applica-
tions should also take care to display directory data in a "safe"
environment (e.g., PostScript-valued types).
13. Acknowledgements
This material is based upon work supported by the National Science Foun-
dation under Grant No. NCR-9416667. The registration procedures defined
here were shamelessly lifted from the MIME registration draft.
14. 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
Howes & Smith [Page 12]
Expires July 1996 INTERNET DRAFT
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.
[RFC-1872]Levinson, E., "The MIME Multipart/Related Content-type," RFC
1872, December 1995.
[MIME-REG]Freed, N., Postel, J., "Multipurpose Internet Mail Extensions
(MIME) Part Four: Registration Procedures," Internet-Draft
draft-ietf-822ext-mime-reg-02.txt, December 1995.
[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.
[RFC-1738]Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource
Locators (URL)", RFC 1738, December 1994.
[MIME-WPP]Howes, T., Smith, M., "A White Pages Person Profile for the
application/directory MIME Content-Type", Internet-Draft
draft-ietf-asid-mime-person-00.txt, January, 1996.
15. Author's Address
Tim Howes
University of Michigan
535 W William St.
Ann Arbor, MI 48103-4943
USA
+1 313 747-4454
tim@umich.edu
Mark Smith
University of Michigan
535 W William St.
Howes & Smith [Page 13]
Expires July 1996 INTERNET DRAFT
Ann Arbor, MI 48103-4943
USA
+1 313 764-2277
mcs@umich.edu
Howes & Smith [Page 14]
