WDIFF

draft-ietf-asid-mime-direct-00.txt --> draft-ietf-asid-mime-direct-01.txt

Network Working Group Tim Howes
INTERNET DRAFT Mark Smith
draft-ietf-asid-mime-direct-01.txt 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 document defines a MIME Content-Type for holding directory information. 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 tex-
tual textual directory information, for example, name, or
email address. The
multipart/mixed application/directory Content-Type is can also be used
as the root body part in a multipart/related Content-Type for handling
more complicated
situations, situations in which non-textual information, for example, 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-parsable machine-parseable address
information when purchasing goods or services over the Internet; etc. As
MIME [mime1] [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.

Howes [Page 1]

Expires January 1996 INTERNET DRAFT

4. Overview

The scheme described defined here for representing directory information in a MIME
Content-Type has two parts. First, the application/directory
Content-Type 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,
implementations and the procedure understandable by which new types are defined are given,
along with users. This document defines the formats for "value", their correspondence with values or
syntaxes
general form the information in several common directory services, the Content-Type should take, and the
procedure by which new specific types and values are for particular applications
may be defined. Many values are represented using the con-
ventions defined in RFC 1522 [mime2], allowing multiple character sets The framework is general enough to be used. 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 attribute) sound) overlaps with predefined
MIME Content-Type. Content-Types. In these cases it may be desirable to include the attributes
information in their well-known MIME formats. This situation is handled
by using a multipart/mixed Content-Type. multipart/related Content-Type as defined in [RFC-1872]. The first
root component of this type is an application/directory body part specifying speci-
fying any tex-
tual 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 non-text
information. 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 subtype definition media type registration template from RFC 1521.

(1)
[MIME-REG].

To: ietf-types@uninett.no
Subject: Registration of MIME media type name: application/directory

MIME media type name: application

(2)

MIME subtype name: directory

(3)

Required parameters: none

(4)

Optional parameters: charset, source

Note that the value of the source, profile, name, defaulttype

The "charset" parameter is as defined in [RFC-1521] for other body
parts.

The "source" parameter is intended 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 entry from entity or entities to which the information came. 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" 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 "profile" parameter is used to convey the type of entity to
which the directory information on one directory entry. Using pertains and the ABNF notation likely set of RFC
822,
information associated with the syntax for this content is:

<content> ::= [<type> ":" <value>]*

<x-type> ::= <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>

<value> ::= a character string whose syntax depends on <type>

iana-token := <a publicly-defined extension token, registered
with IANA, as specified in Section 8 of this
document>

The meanings "name" parameter is used to convey the directory name of the various "types" and
entity to which the format of directory information pertains. Its value is

Howes & Smith [Page 3]

Expires July 1996 INTERNET DRAFT

an ASCII string representing the corresponding
"values" are given below in Table 1. The corresponding types or
fields name. Note that this string may
be protocol-specific and is intended for applications knowledgable
in several existing a particular directory services are given in Appendix A.

type service protocol.

The "defaulttype" parameter is used as a space-saving optimization
for applications that need to hold format represent large numbers of values
--------------------------------------------------------------------
waddress work postal address a sequence of text lines separated
by <CRLF> <space>
haddress home postal address a sequence
the same type. The value of text lines separated 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 <CRLF> <space>
c country text
cn name text
email RFC 822 email address an 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 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 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 home
image image an least one LWSP-character). Using the
notation of RFC 822 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
sound sound an ; a Message-ID as in RFC 822 msg-id
sn surname text
st state

type := x-token / iana-token

x-token := <the two characters "X-" or province text "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 3] 8]

Expires January July 1996 INTERNET DRAFT

title title text
type type

Profile special notes (optional):

Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)

The explanation of object an object type value what goes in each field in the template follows.

Profile name: The name of the profile as defined it will appear in this document, registered 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
IANA, or bilaterally agreed upon
(see note below)
uri uniform resource
identifier an RFC 1738 URL
name directory name a text version the profile. This list
of types is to be expected but not required in the object's
directory name
--------------------------------------------------------------------
Table 1. Types, their meanings, and syntaxes. profile. Other types
not mentioned in the profile definition may also be present. Note that text values follow
any new types referenced by the RFC 822 convention for continued
lines, except that a "continued" line profile must be defined separately as
described in an address marks Section 9.

Profile special notes: Any special notes about the next line profile, how it is to
be used, etc. This section of the address, not a continuation of template may also be used to define an
ordering on the current line.

Note types that appear in the charset parameter should Content-Type, if such an order-
ing is required.

8.2. Post the profile definition

The profile description must be used posted 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 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 converted submitted to UNICODE, or another character set
which the Profile Reviewer for approval.
The Profile Reviewer is a superset of both.

Note that appointed to the "image" and "sound" types contain a Content-ID Application Area Directors and are
only used in conjunction with
may either accept or reject the multipart/mixed Content-Type defined
in profile registration. An accepted regis-
tration should be passed on by the next section.

The allowable values Profile Reviewer to the IANA for
inclusion in the "type" type are listed below.

"person"

Further values official IANA profile registry. The registration may be registered with IANA or bilaterally agreed
upon. A bilaterally agreed upon value consists
rejected for any of the two characters
"X-" following reasons. 1) Insufficient comment
period; 2) Consensus not reached; 3) Technical deficiencies raised on
the list or "x-" followed, with no intervening white space, elsewhere have not been addressed. The Profile Reviewer's
decision to reject a profile may be appealed by any
other token.

Note that the "name" field may 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 not be meaningful, depending
on changed using the source directory service.

[[ 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 IANA registration schemes referred original author or any other interested party may propose
a change to here will an existing profile, but that such changes should only be
defined
proposed when there are serious omissions or errors in a later version of this document. ]]

6. Use of the multipart/mixed Content-Type published
specification. The multipart/mixed Content-Type 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 used deleted from the IANA registry, but
profiles which are nolonger believed to hold directory entries
containing both text and non-text information. The first body part must
have be useful can be declared
OBSOLETE by a Content-Type change to their "intended use" field.

10. Registration of "application/directory". new types

This part section defines procedures by which new types are registered with
the
name 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 source
review of new types, while posing only a small impediment to the information, holds any text information from defini-
tion of new types.

Registration of a new type is accomplished by the following steps.

10.1. Define the
entry, and makes reference to subsequent body parts holding non-text 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 4] 10]

Expires January July 1996 INTERNET DRAFT

directory information via their Content-IDs.

Type purpose:

Type encoding:

Type special notes (optional):

Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)

The body parts referred to do not have to be meaning of each field in any particular order, the template is as
long follows.

Type name: The name of the type, as they come after it will appear in the "application/directory" part referring body of an
application/directory MIME Content-Type "type: value" line to
them.

7. Examples the left
of the colon ":".

Type purpose: The following example illustrates simple use purpose of the
"application/directory" Content-Type.

From: Whomever
To: Someone
Subject: whatever
MIME-Version: 1.0
Message-ID: <id1@host.net>
Content-Type: application/directory
Content-ID: <id2@host.com>

cn: Babs Jensen
cn: Barbara J Jensen
sn: Jensen
email: babs@umich.edu
wphone: +1 313 747-4454 type (e.g., to represent a name, postal
address, IP address, etc.). Give a short but clear description.

Type encoding: The next example illustrates encoding a value of the use type must have in the body of RFC 1522
an application/directory MIME Content-Type. This description must be
precise and must not violate the general encoding to include
non-ascii characters rules defined in some sec-
tion 5 of this document.

Type special notes: Any special notes about the information returned, and type, how it is to be
used, etc.

10.2. Post the use 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 optional "name" type before
proceeding to step 4.

10.4. Submit the type for approval

Once the two-week comment period has elapsed, and "source" parameters.

Content-Type: application/directory;
charset="iso-8859-1";
source="ldap://cn=Bjorn%20Jensen,o=University%20of%20Michigan,c=US"
Content-ID: <id3@host.com>
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 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 final example illustrates 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 use Profile Reviewer to the IANA for inclusion in
the official IANA profile registry. The registration may be rejected for
any of the multipart/mixed Content-
Type 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 include non-textual directory data.

Content-Type: multipart/mixed; boundary=woof
Content-ID: <id4@host.com>

Howes & Smith [Page 5] 11]

Expires January July 1996 INTERNET DRAFT

cn: Bj=F8rn Jensen
sn: Jensen
email: bjorn@umich.edu
image: <id6@host.com>
sound: <id7@host.com>
wphone: +1 313 747-4454
name: cn=3DBjorn Jensen, o=3DUniversity of Michigan,c=3DUS

--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--

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. Applications 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
attributes).

9. 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

[ldap1] Yeong,

[RFC-1777]Yeong, W., Howes, T., Kille, S., "Lightweight Directory Access
Protocol", Request for Comment (RFC) 1777, March 1995.

[ldap2] Howes,

[RFC-1778]Howes, T., Kille, S., Yeong, W., Robbins, C.J., "The String
Representation of Standard Attribute Syntaxes", Request for

Howes & Smith [Page 6] 12]

Expires January July 1996 INTERNET DRAFT

Comment (RFC) 1778, March 1995.

[rfc822]

[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.

[mime1] Borenstein,

[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.

[mime2] Moore,

[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.

10.

[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
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

Mark Smith
University of Michigan
535 W William St.

Howes & Smith [Page 7] 13]

Expires January July 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

Ann Arbor, MI 48103-4943
USA
+1 313 764-2277
mcs@umich.edu

Howes & Smith [Page 8] 14]

----