Network Working Group Ned Freed, Innosoft
Internet Draft John Postel, ISI
<draft-ietf-822ext-mime-reg-00.txt>
Multipurpose Internet Mail Extensions
(MIME) Part Four:
Registration Procedures
May 5, 1995
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are
working documents 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. Internet-Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use
Internet-Drafts as reference material or to cite them other
than as a "working draft" or "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 ds.internic.net (US East
Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast),
or munnari.oz.au (Pacific Rim).
1. Abstract
STD 11, RFC 822, defines a message representation protocol
specifying considerable detail about US-ASCII message headers,
and leaves the message content, or message body, as flat US-
ASCII text. This set of documents, collectively called the
Multipurpose Internet Mail Extensions, or MIME, redefines the
format of messages to allow for
Internet Draft MIME Registration Procedures May 1995
(1) textual message bodies in character sets other than
US-ASCII,
(2) non-textual message bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other than
US-ASCII.
These documents are based on earlier work documented in RFC
934, STD 11, and RFC 1049, but extends and revises them.
Because RFC 822 said so little about message bodies, these
documents are largely orthogonal to (rather than a revision
of) RFC 822.
In particular, these documents are designed to provide
facilities to include multiple parts in a single message, to
represent body and header text in character sets other than
US-ASCII, to represent formatted multi-font text messages, to
represent non-textual material such as images and audio
fragments, and generally to facilitate later extensions
defining new types of Internet mail for use by cooperating
mail agents.
This fourth document, RFC MIME-REG, specifies various IANA
registration procedures for the following MIME entities:
(1) media types,
(2) character sets,
(3) external body access types,
(4) content-transfer-encodings.
These documents are revisions of RFCs 1521 and 1522, which
themselves were revisions of RFCs 1341 and 1342. An appendix
in RFC MIME-CONF describes differences and changes from
previous versions.
Expires November 1995 [Page 2]
Internet Draft MIME Registration Procedures May 1995
2. Table of Contents
1 Abstract .............................................. 1
2 Table of Contents ..................................... 3
3 Introduction .......................................... 4
4 Media Type Registration ............................... 4
4.1 Registration Requirements ........................... 5
4.1.1 Functionality Requirements ........................ 5
4.1.2 Naming Requirements ............................... 5
4.1.3 Parameter Requirements ............................ 6
4.1.4 Format and Canonicalization Requirements .......... 6
4.1.5 Security Requirements ............................. 6
4.1.6 Usage and Implementation Requirements ............. 7
4.1.7 Publication Requirements .......................... 7
4.2 Registration Procedure .............................. 8
4.2.1 Present the Media Type to the Community ........... 8
4.2.2 Media Type Reviewer ............................... 8
4.2.3 IANA Registration ................................. 9
4.3 Location of Registered Media Type List .............. 9
4.4 Registration Template ............................... 9
5 Character Set Registration ............................ 10
5.1 Registration Requirements ........................... 10
5.1.1 Required Characteristics .......................... 10
5.1.2 New Character Sets ................................ 10
5.1.3 Naming Requirements ............................... 11
5.1.4 Usage and Implementation Requirements ............. 11
5.1.5 Publication Requirements .......................... 11
5.2 Registration Procedure .............................. 12
5.2.1 Present the Character Set to the Community ........ 12
5.2.2 Character Set Reviewer ............................ 12
5.2.3 IANA Registration ................................. 13
5.3 Location of Registered Character Set List ........... 13
5.4 Registration Template ............................... 13
6 External Body Access Types ............................ 13
6.1 Registration Requirements ........................... 14
6.1.1 Naming Requirements ............................... 14
6.1.2 Mechanism Specification Requirements .............. 14
6.1.3 Publication Requirements .......................... 14
6.1.4 Security Requirements ............................. 14
6.2 Registration Procedure .............................. 15
6.2.1 Present the Access Type to the Community .......... 15
6.2.2 Access Type Reviewer .............................. 15
6.2.3 IANA Registration ................................. 15
6.3 Location of Registered Access Type List ............. 16
Expires November 1995 [Page 3]
Internet Draft MIME Registration Procedures May 1995
7 Transfer Encodings .................................... 16
7.1 Registration Requirements ........................... 17
7.1.1 Naming Requirements ............................... 17
7.1.2 Algorithm Specification Requirements .............. 17
7.1.3 Input Domain Requirements ......................... 17
7.1.4 Output Range Requirements ......................... 17
7.1.5 Data Integrity Requirements ....................... 18
7.1.6 New Functionality Requirements .................... 18
7.2 Registration Procedure .............................. 18
7.3 Location of Registered Transfer Encoding List ....... 19
8 Authors' Addresses .................................... 19
3. Introduction
Recent Internet protocols have been carefully designed to be
easily extensible in certain areas. In particular, MIME
[RFC-MIME-IMB] is an open-ended framework and can accomodate
additional object types, character sets, and access methods
without any changes to the basic protocol. A registration
process is needed, however, to ensure that the set of such
values is developed in an orderly, well-specified, and public
manner.
This document defines registration procedures which use the
Internet Assigned Numbers Authority (IANA) as a central
registry for such values. This procedures also addresses the
registration requirements needed for the mapping of Object
Identifiers (OIDs) for X.400 MHS use to media types.
Historical Note: The registration process for media types was
initially defined in the context of the asynchronous Internet
mail environment. In this mail environment there is a need to
limit the number of possible media types to increase the
likelihood of interoperability when the capabilities of the
remote mail system are not known. As media types are used in
new environments, where the proliferation of media types is
not a hindrance to interoperability, the original procedure
was excessively restrictive and had to be generalized.
4. Media Type Registration
Registration of a new media type or types starts with the
construction of a registration proposal. This proposal is
Expires November 1995 [Page 4]
Internet Draft MIME Registration Procedures May 1995
then circulated and reviewed. The media type is then
registered if the proposal is acceptable. The following
sections describe requirements and procedures involved.
4.1. Registration Requirements
Media type registration proposals are expected to conform to a
number of requirements as described below.
4.1.1. Functionality Requirements
Media types must function as an actual media format;
registration of entities that are better thought of as a
transfer encoding, character set, or as a collection of
separate objects of another type is not allowed. For example,
although applications exist to decode the base64 transfer
encoding [MIME-IMB], base64 cannot be registered as a subtype
of application.
4.1.2. Naming Requirements
All registered media types must be assigned a MIME type and
subtype names. The combination of these names then serves to
uniquely identify the media type.
The choice of top-level type name must take the nature of
media type involved into account. For example, media capable
of representing still images should be a subtype of the image
content type, whereas media capable of representing audio
information belongs under the audio content type. See RFC
MIME-IMT for additional information on the basic set of top-
level types and their characteristics.
New subtypes of top-level types must conform to the
restrictions of the top-level type, if any. For example, all
subtypes of the multipart content type must use the same
encapsulation syntax.
In some cases a new media type may not "fit" under any
currently defined top-level content type. Such cases are
expected to be quite rare. However, if such a case arises a
new top-level type can be defined to accomodate it. Such a
Expires November 1995 [Page 5]
Internet Draft MIME Registration Procedures May 1995
definition must be done via standards-track RFC; no other
mechanism can be used to define additional top-level content
types.
4.1.3. Parameter Requirements
Media types may elect to use one or more MIME content type
parameters, or some parameters may be automatically made
available to the media type by virtue of being a subtype of a
content type that defines a set of parameters applicable to
any subtype. In either case, the names, values, and meanings
of any parameters must be fully specified.
4.1.4. Format and Canonicalization Requirements
All registered media types must employ a single, canonical
data format. A precise and openly available specification of
the format of each media type is preferred, and if such a
specification is available the media type registration must
reference it.
However, requiring such a specification for all media types
would block the registration of proprietary formats, and as
such is unduly restrictive. As such, this format requirement
can be met by the specification of a particular version or
versions of a particular software package or packages that
understand the format. The appropriateness of using a media
type with an unavailable specification should not be an issue
in the registration process.
Some media types involve the use of patented technology. The
registration of such types is specifically allowed. However,
the restrictions set forth in RFC 1602 on the use of patented
technology in standards-track protocols must be respected when
the specification of a media type is part of a standards-track
protocol.
4.1.5. Security Requirements
Any known security issues that arise from the use of the media
type must be completely and fully described. See the
registration of the application/postscript media type in RFC
Expires November 1995 [Page 6]
Internet Draft MIME Registration Procedures May 1995
MIME-IMT for an example of what sort of security issues can
arise from the use of one particular media type.
It is not required that the media type be secure or that it be
free from risks, but that the known risks be identified.
Publication of a media type does not require an exhaustive
security review, and the security considerations section is
subject to continuing evaluation. Additional security
considerations should be periodically published in an RFC by
IANA.
4.1.6. Usage and Implementation Requirements
In the asynchronous mail environment, where information on the
capabilities of the remote mail agent is not available to the
sender, maximum interoperability is attained by restricting
the number of media types used to those "common" formats
expected to be widely implemented. This was asserted in the
past as a reason to limit the number of possible media types
and resulted in a registration process with a significant
hurdle and delay for those registering media types.
However, the need for "common" media types does not require
limiting the registration of new media types. This
restriction may, in fact, hinder interoperability by causing
separate registration authorities for specific applications
which may register values in conflict with or otherwise
incompatible with each other. If a limited set of media types
is recommended for a particular application, that should be
asserted by a separate applicability statement specific for
the application and/or environment.
As such, universal support and implementation of a media type
is NOT a requirement for registration. If, however, a media
type is explicitly intended for limited use, this should be
noted in its registration.
4.1.7. Publication Requirements
Media type registrations can be published as RFCs, however,
RFC publication is not required to register a new media type.
Expires November 1995 [Page 7]
Internet Draft MIME Registration Procedures May 1995
The registration of a data type does not imply endorsement,
approval, or recommendation by IANA or IETF or even
certification that the specification is adequate. To become
Internet Standards, protocol, data objects, or whatever must
go through the IETF standards process. This is too difficult
and to lengthy a process for the convenient and practical need
to register media types. It is expected that applicability
statements for particular applications will be published from
time to time that recommend implementation of, and support
for, data types that have proven particularly useful in those
contexts.
4.2. Registration Procedure
The following procedure has been implemented by the IANA for
review and approval of new media types. This is not a formal
standards process, but rather an administrative procedure
intended to allow community comment and sanity checking
without excessive time delay.
4.2.1. Present the Media Type to the Community
Send a proposed media type registration to the "ietf-
types@uninett.no" mailing list for a two week review period.
This mailing list has been established for the purpose of
reviewing proposed media and access types. Proposed media
types are not formally registered and must not be used; the
"x-" prefix specified in RFC MIME-IMB can be used until
registration is complete.
The intent of the public posting is to solicit comments and
feedback on the choice of type/subtype name, the unambiguity
of the references with respect to versions and external
profiling information, the choice of which OIDs to use, and a
review of any security considerations.
4.2.2. Media Type Reviewer
When the two week period has passed, the media type reviewer,
who is appointed by the IETF Applications Area Director,
either forwards the request to IANA@ISI.EDU, or rejects it
because of significant objections raised on the list.
Expires November 1995 [Page 8]
Internet Draft MIME Registration Procedures May 1995
Decisions made by the reviewer may be appealed to the IESG.
4.2.3. IANA Registration
Provided that the media type has either passed review or has
been successfully appealed to the IESG, the IANA will register
the media type, assign an OID under the IANA branch, and make
the media type registration available to the community.
4.3. Location of Registered Media Type List
Media type registrations will be posted in the anonymous FTP
directory "ftp.isi.edu:in-notes/iana/assignments/media-types"
and the media type will be listed in the periodically issued
"Assigned Numbers" RFC [RFC-1700]. The media type description
may also be published as an Informational RFC by sending it to
"rfc-editor@isi.edu" (please follow the instructions to RFC
authors [RFC-1543]).
4.4. Registration Template
To: ietf-types@uninett.no
Subject: Registration of new MIME media type
MIME media type name:
(If the the above is not an existing top-level type
please explain why an existing type cannot or should
not be used.)
MIME subtype name:
Required parameters:
Optional parameters:
Encoding considerations:
Security considerations:
Published specification:
Expires November 1995 [Page 9]
Internet Draft MIME Registration Procedures May 1995
(The published specification must be a standards-track RFC
if a new top-level type is being defined.)
Person & email address to contact for further information:
5. Character Set Registration
MIME and other modern Internet protocols are capable of using
many different character sets. This in turn means that the
ability to label different character sets is essential. This
registration procedure exists solely to associate a specific
name or names with a given character set.
5.1. Registration Requirements
Registered character sets are expected to conform to a number
of requirements as described below.
5.1.1. Required Characteristics
Registered character sets must conform to the definition of a
"character set" given in RFC MIME-IMB. In addition, character
sets intended for use in content types under the "text" top-
level type must conform to the restrictions on that type
described in RFC MIME-IMB. All registered character sets must
note whether or not they are suitable for such usage.
All registered character sets must be specified in an openly
available specification.
5.1.2. New Character Sets
This registration mechanism is not intended to be a vehicle
for the definition of entirely new character sets. This is due
to the fact that the registration process does NOT contain
adequate review mechanisims for such undertakings.
As such, only character sets defined by other processes and
standards bodies, or specific profiles of such character sets,
are eligible for registration.
Expires November 1995 [Page 10]
Internet Draft MIME Registration Procedures May 1995
5.1.3. Naming Requirements
One or more names must be assigned to all registered character
sets. Multiple names for the same character set are permitted,
but each name must uniquely identify a single character set.
All character set names must be suitable for use as the value
of a MIME content type parameter, e.g. the charset parameter
of MIME's text type.
5.1.4. Usage and Implementation Requirements
In the asynchronous mail environment, where information on the
capabilities of the remote mail agent is not available to the
sender, maximum interoperability is attained by restricting
character sets to a "common" set expected to be widely
implemented. This was asserted in the past as a reason to
limit the number of possible character sets and resulted in a
registration process with a significant hurdle and delay for
those registering character sets.
However, the need for "common" character sets does not require
limiting the registration of new character sets. This
restriction may, in fact, hinder interoperability by causing
separate registration authorities for specific applications
which may register values in conflict with or otherwise
incompatible with each other. If a limited set of character
sets is recommended for a particular application, that should
be asserted by a separate applicability statement specific for
the application and/or environment.
As such, universal support and implementation of a character
set is NOT a requirement for registration. If, however, a
character set is explicitly intended for limited use, this
should be noted in its registration.
5.1.5. Publication Requirements
Character set registrations can be published as RFCs, however,
RFC publication is not required to register a new character
set.
The registration of a data type does not imply endorsement,
approval, or recommendation by the IANA, IESG, or IETF, or
Expires November 1995 [Page 11]
Internet Draft MIME Registration Procedures May 1995
even certification that the specification is adequate. To
become Internet Standards, protocol, data objects, or whatever
must go through the IETF standards process. This is too
difficult and to lengthy a process for the convenient and
practical need to register character sets. It is expected
that applicability statements for particular applications will
be published from time to time that recommend implementation
of, and support for, character sets that have proven
particularly useful in those contexts.
5.2. Registration Procedure
The following procedure has been implemented by the IANA for
review and approval of new character sets. This is not a
formal standards process, but rather an administrative
procedure intended to allow community comment and sanity
checking without excessive time delay.
5.2.1. Present the Character Set to the Community
Send the proposed character set registration to the "ietf-
charsets@innosoft.com" mailing list. This mailing list has
been established for the sole purpose of reviewing proposed
character set registrations. Proposed character sets are not
formally registered and must not be used; the "x-" prefix
specified in RFC MIME-IMB can be used until registration is
complete.
The intent of the public posting is to solicit comments and
feedback on the definition of the character set and the name
chosen for it over a four week period.
5.2.2. Character Set Reviewer
When the four week period has passed, the character set
reviewer, who is appointed by the IETF Applications Area
Director, either forwards the request to IANA@ISI.EDU, or
rejects it because of significant objections raised on the
list.
Decisions made by the reviewer may be appealed to the IESG.
Expires November 1995 [Page 12]
Internet Draft MIME Registration Procedures May 1995
5.2.3. IANA Registration
Provided that the character set registration has either passed
review or has been successfully appealed to the IESG, the IANA
will register the character set and make its registration
available to the community.
5.3. Location of Registered Character Set List
Character set registrations will be posted in the anonymous
FTP file "ftp.isi.edu:in-notes/iana/assignments/character-
sets" and the character set will be listed in the periodically
issued "Assigned Numbers" RFC [RFC-1700]. The description of
the character set may also be published as an Informational
RFC by sending it to "rfc-editor@isi.edu" (please follow the
instructions to RFC authors [RFC-1543]).
5.4. Registration Template
To: ietf-charsets@innosoft.com
Subject: Registration of new character set
Character set name(s):
(All names must be suitable for use as the value of a
MIME content-type parameter.)
Published specification(s):
(A specification for the character set must be
openly available that accurately describes what
is being registered.)
Person & email address to contact for further information:
6. External Body Access Types
RFC MIME-IMT defines the message/external-body media type,
whereby a body part in a MIME message can act as pointer to
the actual body data in lieu of including the data in the body
part. Each message/external-body reference specifies an access
type, which determines the mechanism used to retrieve the
Expires November 1995 [Page 13]
Internet Draft MIME Registration Procedures May 1995
actual body data. RFC MIME-IMT defines an initial set of
access types, but allows for the registration of additional
access types to accomodate new retrieval mechanisms.
6.1. Registration Requirements
New access type specifications must conform to a number of
requirements as described below.
6.1.1. Naming Requirements
Each access type must have a unique name. This name appears
in the access-type parameter in the message/external-body
content-type header field, and must conform to MIME content
type parameter syntax.
6.1.2. Mechanism Specification Requirements
All of the protocols, transports, and procedures used by a
given access type must be described, either in the
specification of the access type itself or in some other
publicly available specification, in sufficient detail for the
access type to be implemented by any competent implementor.
Use of secret and/or proprietary methods in access types are
expressly prohibited. The restrictions imposed by RFC 1602 on
the standardization of patented algorithms must be respected
as well.
6.1.3. Publication Requirements
All access types must be described by an RFC. The RFC may be
informational rather than standards-track, although standard-
track review and approval are encouraged for all access types.
6.1.4. Security Requirements
Any known security issues that arise from the use of the
access type must be completely and fully described. It is not
required that the access type be secure or that it be free
from risks, but that the known risks be identified.
Expires November 1995 [Page 14]
Internet Draft MIME Registration Procedures May 1995
Publication of a new access type does not require an
exhaustive security review, and the security considerations
section is subject to continuing evaluation. Additional
security considerations should be address by publishing
revised versions of the access type specification.
6.2. Registration Procedure
Registration of a new access type starts with the construction
of a draft of an RFC.
6.2.1. Present the Access Type to the Community
Send a proposed access type specification to the "ietf-
types@uninett.no" mailing list for a two week review period.
This mailing list has been established for the purpose of
reviewing proposed access and media types. Proposed access
types are not formally registered and must not be used.
The intent of the public posting is to solicit comments and
feedback on the access type specification and a review of any
security considerations.
6.2.2. Access Type Reviewer
When the two week period has passed, the access type reviewer,
who is appointed by the IETF Applications Area Director,
either forwards the request to IANA@ISI.EDU, or rejects it
because of significant objections raised on the list.
Decisions made by the reviewer may be appealed to the IESG.
6.2.3. IANA Registration
Provided that the access type has either passed review or has
been successfully appealed to the IESG, the IANA will register
the access type and make the registration available to the
community. The specification of the access type must also be
published as an RFC. Informational RFCs are published by
sending them to "rfc-editor@isi.edu" (please follow the
instructions to RFC authors [RFC-1543]).
Expires November 1995 [Page 15]
Internet Draft MIME Registration Procedures May 1995
6.3. Location of Registered Access Type List
Media type registrations will be posted in the anonymous FTP
directory "ftp.isi.edu:in-notes/iana/assignments/access-types"
and the access type will be listed in the periodically issued
"Assigned Numbers" RFC [RFC-1700].
7. Transfer Encodings
Transfer encodings are tranformations applied to MIME media
types after conversion to the media type's canonical form.
Transfer encodings are used for several purposes:
(1) Many transports, especially message transports, can
only handle data consisting of relatively short lines
of text. There can also be severe restrictions on what
characters can be used in these liens of text -- some
transports are restricted to a small subset of US-ASCII
and others cannot handle certain character sequences.
Transfer encodings are used to transform binary data
into textual form that can survive such transports.
Examples of this sort of transfer encoding include the
base64 and quoted-printable transfer encodings defined
in MIME-IMB.
(2) Image, audio, video, and even application objects are
sometimes quite large. Compression algorithms are often
quite effective in reducing the size of large objects.
Transfer encodings can be used to apply general-purpose
non-lossy compression algorithms to MIME objects.
(3) Transport encodings can be defined as a means of
representing existing encoding formats in a MIME
context.
IMPORTANT NOTE: The registration of a large numbers of
different trnansfer encodings is seen as a significant barrier
to widespread interoperability and is expressely discouraged.
Nevertheless, the following registration procedure has been
defined to provide a means of registering additional transfer
encodings, should registration actually be justified.
Expires November 1995 [Page 16]
Internet Draft MIME Registration Procedures May 1995
7.1. Registration Requirements
Transfer encoding specifications must conform to a number of
requirements as described below.
7.1.1. Naming Requirements
Each transfer encoding must have a unique name. This name
appears in the Content-Transfer-Encoding header field and must
conform to the syntax of that field.
7.1.2. Algorithm Specification Requirements
All of the algorithms used in a transfer encoding (e.g.
conversion to printable form, compression) must be described
in their entirety in the transfer encoding specification. Use
of secret and/or proprietary algorithms in transfer encodings
are expressly prohibited. The restrictions imposed by RFC
1602 on the standardization of patented algorithms must be
respected as well.
7.1.3. Input Domain Requirements
All transfer encodings must be applicable to an arbitrary
sequence of octets of any length. Dependence on particular
input forms is not allowed.
7.1.4. Output Range Requirements
There is no requirement that a particular tranfer encoding
produce a particular form of encoded output. However, the
output format for each transfer encoding must be fully and
completely documented. In particular, each specification must
clearly state whether the output format is always lies within
the confines of 7bit text, 8bit text, or is simply pure binary
material.
Expires November 1995 [Page 17]
Internet Draft MIME Registration Procedures May 1995
7.1.5. Data Integrity Requirements
All transfer encodings must be invertible; it must be possible
to recover the original data by performing the corresponding
decoding operation. Note that this requirement effectively
excludes all forms of lossy compression from use as a transfer
encoding.
7.1.6. New Functionality Requirements
All transfer encodings must provide some sort of new
functionality. Some degree of functionality overlap with
previously registered transfer encodings is acceptable, but
any new transfer encoding must also offer something no other
transfer encoding provides.
7.2. Registration Procedure
Registration of a new transfer encoding starts with the
construction of a draft of a standards-track RFC. The RFC
must define the transfer encoding precisely and completely,
and must also provide substantial justification for defining
and standardizing a new transfer encoding. This specfication
must then be presented to the IESG for consideration. The
IESG can
(1) reject the specification outright as being
inappropriate for standardization,
(2) approve the formation of an IETF working group to work
on the specification in accordance with IETF
procedures, or,
(3) accept the specification as-is and puts it directly on
the standards track.
Transfer encoding specifications on the standards track follow
normal IETF rules for standards track documents. A transfer
encoding is considered to be registered once it is on the
standards track.
Expires November 1995 [Page 18]
Internet Draft MIME Registration Procedures May 1995
7.3. Location of Registered Transfer Encoding List
Transfer encoding registrations beyond the basic set defined
in MIME-IMB will be posted in the anonymous FTP file
"ftp.isi.edu:in-notes/iana/assignments/transfer-encodings" and
will be listed in the periodically issued "Assigned Numbers"
RFC [RFC-1700].
8. Authors' Addresses
For more information, the authors of this document are best
contacted via Internet mail:
Ned Freed
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
USA
Email: ned@innosoft.com
Phone: +1 818 919 3600
Fax: +1 818 919 3614
Jon Postel
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
USA
EMail: Postel@ISI.EDU
Phone: +1 310 822 1511
Fax: +1 310 823 6714
Expires November 1995 [Page 19]
