datatracker.ietf.org
Sign in
Version 5.6.2.p5, 2014-08-04
Report a bug

Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures
RFC 4289

Document type: RFC - Best Current Practice (December 2005; No errata)
Obsoletes RFC 2048
Also Known As BCP 13
Was draft-freed-mime-p4 (individual in gen area)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4289 (Best Current Practice)
Responsible AD: Ted Hardie
Send notices to: <ned.freed@mrochek.com>, <klensin@jck.com>,<nsb@guppylake.com>

Network Working Group                                           N. Freed
Request for Comments: 4289                              Sun Microsystems
BCP: 13                                                       J. Klensin
Obsoletes: 2048                                            December 2005
Category: Best Current Practice

        Multipurpose Internet Mail Extensions (MIME) Part Four:
                        Registration Procedures

Status of This Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document specifies IANA registration procedures for MIME
   external body access types and content-transfer-encodings.

Freed & Klensin          Best Current Practice                  [Page 1]
RFC 4289                   MIME Registration               December 2005

Table of Contents

   1. Introduction ....................................................2
   2. External Body Access Types ......................................3
      2.1. Registration Requirements ..................................3
         2.1.1. Naming Requirements ...................................3
         2.1.2. Mechanism Specification Requirements ..................3
         2.1.3. Publication Requirements ..............................4
         2.1.4. Security Requirements .................................4
      2.2. Registration Procedure .....................................4
         2.2.1. Present the Access Type to the Community ..............4
         2.2.2. Access Type Reviewer ..................................4
         2.2.3. IANA Registration .....................................5
      2.3. Location of Registered Access Type List ....................5
      2.4. IANA Procedures for Registering Access Types ...............5
   3. Transfer Encodings ..............................................5
      3.1. Transfer Encoding Requirements .............................6
         3.1.1. Naming Requirements ...................................6
         3.1.2. Algorithm Specification Requirements ..................6
         3.1.3. Input Domain Requirements .............................6
         3.1.4. Output Range Requirements .............................6
         3.1.5. Data Integrity and Generality Requirements ............7
         3.1.6. New Functionality Requirements ........................7
         3.1.7. Security Requirements .................................7
      3.2. Transfer Encoding Definition Procedure .....................7
      3.3. IANA Procedures for Transfer Encoding Registration .........8
      3.4. Location of Registered Transfer Encodings List .............8
   4. Security Considerations .........................................8
   5. IANA Considerations .............................................8
   6. Acknowledgements ................................................8
   7. References ......................................................9
   A.  Changes Since RFC 2048 .........................................9

1.  Introduction

   Recent Internet protocols have been carefully designed to be easily
   extensible in certain areas.  In particular, MIME [RFC2045] is an
   open-ended framework and can accommodate additional object types,
   charsets, 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 that use the Internet
   Assigned Numbers Authority (IANA) as a central registry for these
   values.

Freed & Klensin          Best Current Practice                  [Page 2]
RFC 4289                   MIME Registration               December 2005

   Note:

      Registration of media types and charsets for use in MIME are
      specified in separate documents [RFC4288] [RFC2978] and are not
      addressed here.

1.1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  External Body Access Types

   [RFC2046] defines the message/external-body media type, whereby a
   MIME entity can act as pointer to the actual body data in lieu of
   including the data directly in the entity body.  Each

[include full document text]