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: ::= [ ":" ]* ::= "cn" | "sn" | "fn" | "c" | "st" | "l" | "email" | "title" | "fax" | "pager" | "wphone" | "hphone" | "waddress" | "haddress" | "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 -------------------------------------------------------------------- waddress work postal address a sequence of text lines separated by haddress home postal address a sequence of text lines separated by 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: Content-Type: application/directory Content-ID: 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: 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: 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: Content-Transfer-Encoding: Quoted-Printable cn: Bj=F8rn Jensen sn: Jensen email: bjorn@umich.edu image: sound: wphone: +1 313 747-4454 name: cn=3DBjorn Jensen, o=3DUniversity of Michigan,c=3DUS --woof Content-Type: image/jpeg Content-ID: <...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: --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]