Network Working Group Tim Howes INTERNET DRAFT University of Michigan A MIME Content-Type for Directory Information 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: ::= [ ":" ]* Howes [Page 2] RFC DRAFT August 1995 ::= "cn" | "sn" | "fn" | "c" | "st" | "l" | "email" | "title" | "address" | "phone" | "fax" | "pager" | "uri" | "o" | "photo" | "type" | "name" | ::= ::= a character string whose syntax depends on 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 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: Content-Type: application/directory Content-ID: 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: 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: --woof Content-Type: application/directory; name="cn=Bjorn Jensen, o=University of Michigan, c=US"; source="x500"; Content-ID: cn: =?ISO-8859-1?Q?Bj=F8rn_Jensen?= sn: Jensen email: bjorn@umich.edu image: sound: phone: +1 313 747-4454 --woof Content-Type: image/jpeg Content-ID: <...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: --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]