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 := iana-token := 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 := iana-token := 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: Content-Type: application/directory Howes & Smith [Page 6] Expires July 1996 INTERNET DRAFT Content-ID: 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: 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="" Content-ID: --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:: Howes & Smith [Page 7] Expires July 1996 INTERNET DRAFT 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"; access-type=ANON-FTP; directory="pub/myname"; mode="image" Content-Type: audio/basic Content-ID: --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]