[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 rfc2425                               
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]