RFC 2048

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

okay bestie, let's get into it 🫶 this is RFC 2048, part of the MIME family, and it's all about how new MIME values get registered so the whole Internet stays organized. It's a Best Current Practice (BCP 13), not a standard, and it came out in November 1996. It was written in the Network Working Group by N. Freed (Innosoft), J. Klensin (MCI), and J. Postel (ISI). It obsoletes RFC 1521, RFC 1522, and 1590 (so those older versions are replaced by this one), and the title block doesn't list any documents it updates 🧚

---

Status of This Memo ✨

This document describes an Internet Best Current Practice for the Internet Community and asks for discussion and suggestions for improvements. Distribution of this memo is unlimited 💜

Abstract 🌸

okay so STD 11, RFC 822, defines a message format that's super detailed about US-ASCII message headers but basically leaves the message content, or body, as plain US-ASCII text 🙈 MIME is the set of documents that fixes that. It redefines the format of messages so you can have:

1. textual message bodies in character sets other than US-ASCII,
2. an extensible set of different formats for non-textual message bodies,
3. multi-part message bodies, and
4. textual header information in character sets other than US-ASCII.

these docs build on earlier work in RFC 934, STD 11, and RFC 1049, but they extend and revise it. since RFC 822 said so little about message bodies, MIME is mostly its own thing rather than a revision of RFC 822 💅

this fourth document, RFC 2048, covers the IANA registration procedures for these MIME facilities:

1. media types,
2. external body access types,
3. content-transfer-encodings.

registering character sets for MIME is handled somewhere else now, so it's not in this doc anymore 🦋

these documents revise RFCs 1521 and 1522, which were themselves revisions of RFCs 1341 and 1342. the appendix in RFC 2049 explains the differences and changes from the older versions ✨

Table of Contents 📚

1. Introduction .........................................    3
2. Media Type Registration ..............................    4
2.1 Registration Trees and Subtype Names ................    4
2.1.1 IETF Tree .........................................    4
2.1.2 Vendor Tree .......................................    4
2.1.3 Personal or Vanity Tree ...........................    5
2.1.4 Special `x.' Tree .................................    5
2.1.5 Additional Registration Trees .....................    6
2.2 Registration Requirements ...........................    6
2.2.1 Functionality Requirement .........................    6
2.2.2 Naming Requirements ...............................    6
2.2.3 Parameter Requirements ............................    7
2.2.4 Canonicalization and Format Requirements ..........    7
2.2.5 Interchange Recommendations .......................    8
2.2.6 Security Requirements .............................    8
2.2.7 Usage and Implementation Non-requirements .........    9
2.2.8 Publication Requirements ..........................   10
2.2.9 Additional Information ............................   10
2.3 Registration Procedure ..............................   11
2.3.1 Present the Media Type to the Community for  Review   11
2.3.2 IESG Approval .....................................   12
2.3.3 IANA Registration .................................   12
2.4 Comments on Media Type Registrations ................   12
2.5 Location of Registered Media Type List ..............   12
2.6 IANA Procedures for Registering Media Types .........   12
2.7 Change Control ......................................   13
2.8 Registration Template ...............................   14
3. External Body Access Types ...........................   14
3.1 Registration Requirements ...........................   15
3.1.1 Naming Requirements ...............................   15
3.1.2 Mechanism Specification Requirements ..............   15
3.1.3 Publication Requirements ..........................   15
3.1.4 Security Requirements .............................   15
3.2 Registration Procedure ..............................   15
3.2.1 Present the Access Type to the Community ..........   16
3.2.2 Access Type Reviewer ..............................   16
3.2.3 IANA Registration .................................   16
3.3 Location of Registered Access Type List .............   16
3.4 IANA Procedures for Registering Access Types ........   16
4. Transfer Encodings ...................................   17
4.1 Transfer Encoding Requirements ......................   17
4.1.1 Naming Requirements ...............................   17
4.1.2 Algorithm Specification Requirements ..............   18
4.1.3 Input Domain Requirements .........................   18
4.1.4 Output Range Requirements .........................   18
4.1.5 Data Integrity and Generality Requirements ........   18
4.1.6 New Functionality Requirements ....................   18
4.2 Transfer Encoding Definition Procedure ..............   19
4.3 IANA Procedures for Transfer Encoding Registration...   19
4.4 Location of Registered Transfer Encodings List ......   19
5. Authors' Addresses ...................................   20
A. Grandfathered Media Types ............................   21

---

1. Introduction 💖

recent Internet protocols were designed carefully so they can be extended easily in certain areas 🧚 MIME [RFC 2045] is an open-ended framework, so it can take on new object types, character sets, and access methods without changing the basic protocol at all. that's iconic 👑 but we still need a registration process so all these new values get added in an orderly, well-specified, and public way 🫶

this document sets up the registration procedures that use the Internet Assigned Numbers Authority (IANA) as the central registry for those values 🌈

Historical Note: the registration process for media types was first defined for asynchronous Internet mail. in that setting there's a real need to limit how many media types exist, so that interoperability is more likely when you don't know what the remote mail system can handle 🙈 once media types started showing up in new environments, where having lots of them doesn't hurt interoperability, the original procedure was way too restrictive, so it had to be generalized 💅

2. Media Type Registration 🦋

okay so registering a new media type (or several) starts with writing up a registration proposal ✨ registrations can go into several different registration trees, and each tree has its own requirements, which we'll get into below. generally, the proposal gets circulated and reviewed in a way that fits the tree it's going into. if the proposal is acceptable, the media type gets registered 🎀 the following sections explain the requirements and procedures for each of the different trees.

2.1. Registration Trees and Subtype Names 🌸

to make the registration process more efficient and flexible, different structures of subtype names can be registered 💅 that way the different needs are covered: say, a subtype that the Internet Community is going to recommend for wide support and implementation, versus a subtype that's used to move files belonging to proprietary software. these subsections define registration "trees," which are told apart by faceted names (names shaped like "tree.subtree...type") 🧚 heads up that some media types defined before this document don't follow the naming conventions below. Appendix A talks about them 📚

2.1.1. IETF Tree 👑

the IETF tree is for types of general interest to the Internet Community. registering in the IETF tree requires approval by the IESG and publication of the media type registration as some form of RFC 🔥

media types in the IETF tree usually have names that aren't faceted, meaning they don't contain any period (".", full stop) characters 🦋

the "owner" of a media type registration in the IETF tree is assumed to be the IETF itself 💜 changing or altering the specification requires the same level of processing (e.g. standards track) that the original registration needed 🫶

2.1.2. Vendor Tree 🍓

the vendor tree is for media types tied to commercially available products. "vendor" and "producer" are treated as equivalent, and the term is used very broadly here ✨

anybody who needs to interchange files for a particular product can put a registration in the vendor tree 💅 but the registration formally belongs to the vendor or organization that makes the software or file format. changes to the specification get made at their request, as covered in later sections 🌈

registrations in the vendor tree are marked by the leading facet "vnd." 🎀 after that, depending on the registration, you can use either a media type name from a well-known producer (like "vnd.mudpie") or an IANA-approved designation of the producer's name, followed by a media type or product designation (like vnd.bigcompany.funnypictures) 🦋

public exposure and review aren't required for vendor tree media types, but using the ietf-types list for review is strongly encouraged, since it improves the quality of the specs 🙈 registrations in the vendor tree can be sent directly to the IANA ✨

2.1.3. Personal or Vanity Tree 🧚

registrations for media types that were made experimentally, or as part of products that aren't sold commercially, can go in the personal or vanity tree 💜 these are marked by the leading facet "prs." 🌸

the owner of "personal" registrations and their specs is the person or entity that made the registration, or someone they've handed responsibility to, as described below 💖

just like the vendor tree, public exposure and review aren't required for personal tree media types, but using the ietf-types list for review is strongly encouraged to make the specs better 🫶 registrations in the personal tree can be sent directly to the IANA 💅

2.1.4. Special `x.' Tree 🌈

for convenience and symmetry with this registration scheme, media type names that start with "x." as the first facet can be used for the same things that names starting with "x-" are usually used for ✨ these types are unregistered and experimental, and they should only be used with the active agreement of the parties exchanging them 🙈

but with the simplified registration procedures for the vendor and personal trees above, it should rarely, if ever, be necessary to use unregistered experimental types 😭 so using either the "x-" or the "x." forms is discouraged 🍓

2.1.5. Additional Registration Trees 🌈

Every so often, when the community really needs it, the IANA can create brand new top-level registration trees, but only with the IESG's advice and consent 🙏. It's totally expected that these trees could be handed off for outside registration and management to well-known permanent bodies, like scientific societies for the media types in their own fields 🔬. Generally, the review quality for specs in one of these extra trees is expected to match what the IETF would do for its own tree 🔍. Setting up a new tree gets announced through an RFC publication that the IESG has approved 📣.

2.2. Registration Requirements 📋

Every media type registration proposal is expected to conform to a bunch of requirements, which the following sections walk through 💅. Heads up: the specifics sometimes shift depending on the registration tree, and the following sections spell that out too 🌸.

2.2.1. Functionality Requirement 🎬

Media types must function as an actual media format 🎞️. Registering something that's really a transfer encoding, a character set, or a collection of separate entities of another type is not allowed 🙅. For example, applications exist that can decode the base64 transfer encoding [RFC 2045], but base64 cannot be registered as a media type 💀.

This one applies no matter which registration tree you're in 🌳.

2.2.2. Naming Requirements 🏷️

All registered media types must be assigned MIME type and subtype names ✍️. Those two names together uniquely identify the media type, and the format of the subtype name tells you which registration tree it lives in ✨.

The top-level type name has to take the nature of the media type into account. For example, media normally used for still images should be a subtype of the image content type, whereas media that can carry audio belongs under the audio content type 🖼️🎧. See RFC 2046 for more on the basic set of top-level types and what they're all about 📚.

New subtypes of top-level types must conform to the restrictions of that top-level type, if there are any. For example, all subtypes of the multipart content type must use the same encapsulation syntax 🧩.

Sometimes a new media type doesn't "fit" under any currently defined top-level content type. That's expected to be quite rare 🦄. But if it does happen, a new top-level type can be defined to accommodate it. That definition has to be done through a standards-track RFC, because no other mechanism can be used to define additional top-level content types 🚫.

These requirements apply regardless of the registration tree involved.

2.2.3. Parameter Requirements 🎛️

Media types can choose to use one or more MIME content type parameters. Or some parameters get made available automatically, by virtue of the media type being a subtype of a content type that defines a set of parameters applicable to any of its subtypes 🪄. Either way, the names, values, and meanings of any parameters must be fully specified when a media type is registered in the IETF tree, and should be specified as completely as possible when media types are registered in the vendor or personal trees 📝.

New parameters must not be used to introduce new functionality in types registered in the IETF tree 🙅‍♀️. New parameters are still allowed to convey additional information that doesn't otherwise change existing functionality ✨. An example would be a "revision" parameter that indicates a revision level of an external specification, such as JPEG 🖨️. Similar behavior is encouraged for media types registered in the vendor or personal trees, but it isn't required 💜.

2.2.4. Canonicalization and Format Requirements 🎯

All registered media types must employ a single, canonical data format, regardless of registration tree 💎.

A precise and openly available specification of the format of each media type is required for all types registered in the IETF tree. At a minimum, it must be referenced by the media type registration proposal, if it isn't actually included in the proposal itself 📄.

For vendor tree media types, the specifications of format and processing particulars may or may not be publicly available 🤷‍♀️. Those registration proposals are explicitly permitted to include only a specification of which software and version produce or process the media type 🖥️. References to or inclusion of format specifications in registration proposals is encouraged, but not required 🫶.

Format specifications are still required for the personal tree 🧸. They can be published as RFCs or otherwise deposited with IANA 📬. The deposited specifications will meet the same criteria as those required to register a well-known TCP port and, in particular, they don't need to be made public 🤫.

Some media types involve the use of patented technology 🏆. Registering media types that involve patented technology is specifically permitted. However, the restrictions set forth in RFC 1602 on the use of patented technology in standards-track protocols must be respected when a media type's specification is part of a standards-track protocol ⚖️.

2.2.5. Interchange Recommendations 🤝

Media types should, whenever possible, interoperate across as many systems and applications as possible 🌍. Some media types will inevitably have problems interoperating across different platforms 😬. Problems with different versions, byte ordering, and specifics of gateway handling can and will come up 🙃.

Universal interoperability of media types isn't required, but known interoperability issues should be identified whenever possible 🔎. Publishing a media type doesn't require an exhaustive interoperability review, and the interoperability considerations section is subject to continuing evaluation 🔄.

These recommendations apply regardless of the registration tree involved.

2.2.6. Security Requirements 🔐

An analysis of security issues is required for all types registered in the IETF Tree 🛡️. (This is in accordance with the basic requirements for all IETF protocols.) A similar analysis for media types registered in the vendor or personal trees is encouraged, but not required 🫧. However, no matter what security analysis has or hasn't been done, all descriptions of security issues must be as accurate as possible, regardless of registration tree 🎯. In particular, a statement that there are "no security issues associated with this type" must not be confused with "the security issues associated with this type have not been assessed" 🚨.

There is absolutely no requirement that media types registered in any tree be secure or completely free from risks 😅. Nevertheless, all known security risks must be identified in the registration of a media type, again regardless of registration tree 🔥.

The security considerations section of all registrations is subject to continuing evaluation and modification. In particular, it may be extended by use of the "comments on media types" mechanism described in subsequent sections 🧾.

Security is not a vibe, bestie. Read these carefully 🫶

Some of the issues that should be looked at in a security analysis of a media type are:

1. Complex media types may include provisions for directives that institute actions on a recipient's files or other resources. In many cases, provision is made for originators to specify arbitrary actions in an unrestricted fashion, which may then have devastating effects 💀. See the registration of the application/postscript media type in RFC 2046 for an example of such directives and how to handle them 📖.
2. Complex media types may include provisions for directives that institute actions which, while not directly harmful to the recipient, may result in disclosure of information that either facilitates a subsequent attack or else violates a recipient's privacy in some way 👀. Again, the registration of the application/postscript media type illustrates how such directives can be handled 🙈.
3. A media type might be targeted for applications that require some sort of security assurance but do not provide the necessary security mechanisms themselves 🔓. For example, a media type could be defined for storage of confidential medical information, which in turn requires an external confidentiality service 🏥.

2.2.7. Usage and Implementation Non-requirements 📭

In the asynchronous mail environment, the sender often has no idea what the remote mail agent is capable of 📬. Maximum interoperability is attained by restricting the number of media types used to the "common" formats that are expected to be widely implemented 🧃. This was once asserted as a reason to limit the number of possible media types, and it resulted in a registration process with a significant hurdle and delay for anyone registering media types 🐢.

However, the need for "common" media types does not require limiting the registration of new media types 🙌. If a limited set of media types is recommended for a particular application, that should be asserted by a separate applicability statement specific to that 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 🏷️.

2.2.8. Publication Requirements 📰

Proposals for media types registered in the IETF tree must be published as RFCs 🎓. RFC publication of vendor and personal media type proposals is encouraged, but not required. In all cases, IANA will retain copies of all media type proposals and "publish" them as part of the media types registration tree itself 📚.

Other than in the IETF tree, registering 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, protocols, data objects, or whatever else must go through the IETF standards process. That process is too difficult and too lengthy for the convenient registration of media types 🐌.

The IETF tree exists for media types that do require a substantive review and approval process, and the vendor and personal trees exist for those that do not 🌳. It's expected that applicability statements for particular applications will be published from time to time, recommending implementation of and support for media types that have proven especially useful in those contexts 💜.

As discussed above, registration of a top-level type requires standards-track processing and, hence, RFC publication 🎀.

2.2.9. Additional Information 🎁

Various sorts of optional information may be included in the specification of a media type, if it is available 🧁:

1. Magic number(s) (length, octet values). Magic numbers are byte sequences that are always present and thus can be used to identify entities as being of a given media type 🔮.
2. File extension(s) commonly used on one or more platforms to indicate that some file containing a given type of media 📁.
3. Macintosh File Type code(s) (4 octets) used to label files containing a given type of media 🍎.

Such information is often quite useful to implementors, and if available, should be provided 💖.

2.3. Registration Procedure 💌

Okay so IANA has this procedure for reviewing and approving new media types 🎀. It's not a formal standards process, more of an admin thing that lets the community comment and sanity-check without waiting forever ⏳. For the IETF tree, the normal IETF processes should be followed, and posting an internet-draft plus an announcement on the ietf-types list (see the next subsection) counts as step one 📝. For vendor or personal tree registrations, that initial review step may be omitted, and you can just send the template and an explanation straight to IANA at iana@iana.org 💅. Still, authors of vendor or personal media type specs are encouraged to seek community review and comment whenever it's feasible 🫶.

2.3.1. Present the Media Type to the Community for Review 📣

Send a proposed media type registration to "ietf-types@iana.org" for a two week review period 🦋. That mailing list exists specifically to review proposed media and access types. Proposed media types are not formally registered and must not be used ❌. The x- prefix specified in RFC 2045 can be used until registration is complete 🌸.

The point of the public posting is to get feedback on the choice of type/subtype name, whether the references are unambiguous with respect to versions and external profiling information, and a check of any interoperability or security considerations 🔍. The submitter can submit a revised registration, or withdraw it completely, at any time 💖.

2.3.2. IESG Approval 🏅

Media types registered in the IETF tree must be submitted to the IESG for approval 👑.

2.3.3. IANA Registration 🎉

As long as the media type meets the requirements for media types and has obtained any approval that's necessary, the author can submit the registration request to IANA ✨. IANA will then register the type and make the registration available to the community 🌈.

2.4. Comments on Media Type Registrations 💬

Community members can submit comments on registered media types to IANA 🗣️. IANA passes these on to the "owner" of the media type if possible. Commenters can ask for their comment to be attached to the registration itself, and if IANA approves, it'll be viewable alongside the type registration 🧚.

2.5. Location of Registered Media Type List 📍

Media type registrations get posted in the anonymous FTP directory "ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/" 📂. All registered media types also show up in the periodically issued "Assigned Numbers" RFC [currently STD 2, RFC 1700] 📜. The media type description and other supporting material can also be published as an Informational RFC by sending it to "rfc-editor@isi.edu" (please follow the instructions to RFC authors [RFC-1543]) 💜.

2.6. IANA Procedures for Registering Media Types 🤖

IANA only registers media types in the IETF tree when it gets a message from the IESG saying a given registration was approved 👑. Vendor and personal types get registered automatically and without any formal review, as long as these minimal conditions are met 🫧:

1. Media types must function as an actual media format. In particular, character sets and transfer encodings may not be registered as media types 🚫.
2. All media types must have properly formed type and subtype names. All type names must be defined by a standards-track RFC. All subtype names must be unique, must conform to the MIME grammar for such names, and must contain the proper tree prefix 🏷️.
3. Types registered in the personal tree must either provide a format specification or a pointer to one 📄.
4. Any security considerations given must not be obviously bogus. (It is neither possible nor necessary for the IANA to conduct a comprehensive security review of media type registrations. Nevertheless, IANA has the authority to identify obviously incompetent material and exclude it.) 🛡️💀

2.7. Change Control 🔧

Once IANA has published a media type, the author can request a change to its definition 📝. The descriptions of the different registration trees above name the "owners" of each type of registration 👑. The change request follows the same procedure as the registration request:

1. Publish the revised template on the ietf-types list 📣.
2. Leave at least two weeks for comments ⏰.
3. Publish using IANA after formal review if required 🎀.

Changes should only be requested when there are serious omissions or errors in the published specification 🙈. When review is required, a change request may be denied if it makes entities that were valid under the previous definition invalid under the new one 😬.

The owner of a content type can hand responsibility over to another person or agency by informing IANA and the ietf-types list. This can happen without discussion or review 🦋.

The IESG may reassign responsibility for a media type 🧑‍⚖️. The most common case is when the registration's author has died, has moved out of contact, or is otherwise unable to make changes the community cares about 🕊️.

Media type registrations may not be deleted! Types that are no longer believed appropriate for use can be declared OBSOLETE by changing their "intended use" field. Those types will be clearly marked in the lists IANA publishes 🪦.

2.8. Registration Template 📋

Here's the template you fill in to register a type, copied exactly as the original 💅:

     To: ietf-types@iana.org
     Subject: Registration of MIME media type XXX/YYY

     MIME media type name:

     MIME subtype name:

     Required parameters:

     Optional parameters:

     Encoding considerations:

     Security considerations:

     Interoperability considerations:

     Published specification:

     Applications which use this media type:

     Additional information:

       Magic number(s):
       File extension(s):
       Macintosh File Type Code(s):

     Person & email address to contact for further information:

     Intended usage:

     (One of COMMON, LIMITED USE or OBSOLETE)

     Author/Change controller:

     (Any other information that the author deems interesting may be
     added below this line.)

3. External Body Access Types 🦋

Okay so RFC 2046 defines the message/external-body media type, which lets a MIME entity act as a pointer to the actual body data instead of including that data in the entity body 🧚. Each message/external-body reference specifies an access type, and that decides the mechanism used to retrieve the actual body data 🔑. RFC 2046 defines an initial set of access types, but it also allows new access types to be registered for new retrieval mechanisms 🌈.

3.1. Registration Requirements 📏

New access type specifications have to meet a number of requirements, described below 💼.

3.1.1. Naming Requirements 🏷️

Each access type must have a unique name 💖. That name appears in the access-type parameter in the message/external-body content-type header field, and it must conform to MIME content type parameter syntax 🎀.

3.1.2. Mechanism Specification Requirements 🔍

All of the protocols, transports, and procedures used by a given access type must be described, either in the access type's own specification or in some other publicly available specification 📚. The description has to be detailed enough for the access type to be implemented by any competent implementor 🧑‍💻. Use of secret and/or proprietary methods in access types is expressly prohibited 🚫. The restrictions RFC 1602 puts on standardizing patented algorithms must be respected as well ⚖️.

3.1.3. Publication Requirements 📰

All access types must be described by an RFC 📜. The RFC may be informational rather than standards-track, although standards-track review and approval are encouraged for all access types ⭐.

3.1.4. Security Requirements 🛡️💀

Any known security issues that arise from using the access type must be completely and fully described 🚨. The access type doesn't have to be secure or free from risks. What matters is that the known risks get identified 🙏. Publishing a new access type doesn't require an exhaustive security review, and the security considerations section is subject to continuing evaluation 🔁. Additional security considerations should be addressed by publishing revised versions of the access type specification 🩹.

3.2. Registration Procedure 🗂️

Registering a new access type starts with writing a draft of an RFC ✍️.

3.2.1. Present the Access Type to the Community 📣

Send a proposed access type specification to the "ietf-types@iana.org" mailing list for a two week review period 🦋. That list was set up to review proposed access and media types. Proposed access types are not formally registered and must not be used ❌.

The point of the public posting is to get feedback on the access type specification and a review of any security considerations 🔍.

3.2.2. Access Type Reviewer 🧐

When the two week period is over, the access type reviewer does one of two things. The reviewer is appointed by the IETF Applications Area Director, and they either forward the request to "iana@isi.edu", or reject it because of significant objections raised on the list ⚖️.

Decisions made by the reviewer must be posted to the ietf-types mailing list within 14 days ⏰. Decisions made by the reviewer may be appealed to the IESG 🙋‍♀️.

3.2.3. IANA Registration 🎉

Once the access type has either passed review or been successfully appealed to the IESG, IANA registers it and makes the registration available to the community 🌟. The access type's specification must also be published as an RFC 📜. Informational RFCs get published by sending them to "rfc-editor@isi.edu" (please follow the instructions to RFC authors [RFC-1543]) 💜.

3.3. Location of Registered Access Type List 📍

Access type registrations get posted in the anonymous FTP directory "ftp://ftp.isi.edu/in-notes/iana/assignments/access-types/" 📂. All registered access types are listed in the periodically issued "Assigned Numbers" RFC [currently RFC-1700] 📜.

3.4. IANA Procedures for Registering Access Types 🤖

The IESG tells IANA who the access type reviewer is 👑. IANA only acts on access type definitions that the reviewer has approved and forwarded to IANA for registration. The other option is a communication from the IESG saying an appeal has overturned the reviewer's ruling 🔄.

4. Transfer Encodings ✨

okay so transfer encodings are basically glow-up transformations 💅 you apply to MIME media types AFTER they've been converted to their canonical form. 🦋 They show up for a few main reasons:

1. Lots of transports, especially message transports, can only handle data made of fairly short lines of text 📝 and there can be super strict rules about which characters are allowed in those lines. Some transports only accept a tiny slice of US-ASCII, and others choke on certain character sequences 😭 Transfer encodings turn binary data into text so it can survive that journey. The base64 and quoted-printable transfer encodings defined in RFC 2045 are the classic examples of this.
2. Images, audio, video, and even application entities can be huge 🐘 Compression algorithms are often really good at shrinking large entities, so transfer encodings can be used to apply general-purpose non-lossy compression to MIME entities. 🗜️
3. Transport encodings can be defined as a way of representing existing encoding formats in a MIME context. 🧚

IMPORTANT: Standardizing a huge pile of different transfer encodings is seen as a big barrier to widespread interoperability, so it's expressly discouraged 🙅‍♀️ Still, the following procedure exists so people can define additional transfer encodings, if standardization actually turns out to be justified.

4.1. Transfer Encoding Requirements

Transfer encoding specifications have to meet a bunch of requirements, which we'll go through below. 📋 Think of it as the vibe check before anything gets approved. 💜

4.1.1. Naming Requirements

Every transfer encoding MUST have a unique name. 🏷️ That name shows up in the Content-Transfer-Encoding header field, so it MUST conform to the syntax of that field. No copycats allowed, bestie! 🙅‍♀️

4.1.2. Algorithm Specification Requirements

All of the algorithms used in a transfer encoding (for example, conversion to printable form, or compression) MUST be described in their entirety in the transfer encoding specification. 📖 Using secret and/or proprietary algorithms in standardized transfer encodings is expressly prohibited, full stop. 🚫 The restrictions that RFC 1602 puts on standardizing patented algorithms MUST be respected as well. ⚖️

4.1.3. Input Domain Requirements

All transfer encodings MUST be applicable to an arbitrary sequence of octets of any length. 🌊 Depending on particular input forms is not allowed, no exceptions. 🙅‍♀️

It should be noted that the 7bit and 8bit encodings do not conform to this requirement. 🙈 Beyond the fact that having a pile of specialized encodings is just undesirable, the whole point here is to block new encodings that look like 7bit and 8bit. 🚧

4.1.4. Output Range Requirements

There is no requirement that a particular transfer encoding produce a particular form of encoded output. 🤷‍♀️ However, the output format for each transfer encoding MUST be fully and completely documented. 📚 Specifically, each specification MUST clearly state whether the output format always lies within the confines of 7bit data, 8bit data, or is simply pure binary data. 🔍

4.1.5. Data Integrity and Generality Requirements

All transfer encodings MUST be fully invertible on any platform. 🔁 It MUST be possible for anyone to recover the original data by performing the corresponding decoding operation. 🗝️ Note that this requirement effectively excludes all forms of lossy compression, as well as all forms of encryption, from being used as a transfer encoding. 🙅‍♀️ (Lossy compression and encryption are not it, bestie.)

4.1.6. New Functionality Requirements

All transfer encodings MUST provide some sort of new functionality. ✨ Some overlap in functionality with previously defined transfer encodings is acceptable, but any new transfer encoding MUST also offer something no other transfer encoding provides. 👑 It has to bring something new to the table, obviously. 💅

4.2. Transfer Encoding Definition Procedure

Defining a new transfer encoding starts with writing a draft of a standards-track RFC. 📝 The RFC MUST define the transfer encoding precisely and completely, and it MUST also provide substantial justification for defining and standardizing a new transfer encoding. 🧾 That specification then MUST 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 put it directly on the standards track. 🚀

Transfer encoding specifications on the standards track follow the normal IETF rules for standards track documents. 📜 A transfer encoding is considered to be defined and available for use once it is on the standards track. 🎀

4.3. IANA Procedures for Transfer Encoding Registration

There is no need for a special procedure for registering Transfer Encodings with the IANA. 🙌 All legitimate transfer encoding registrations MUST appear as a standards-track RFC, so it is the IESG's responsibility to notify the IANA when a new transfer encoding has been approved. 📬

4.4. Location of Registered Transfer Encodings List

Transfer encoding registrations will be posted in the anonymous FTP directory ftp://ftp.isi.edu/in-notes/iana/assignments/transfer-encodings/, and all registered transfer encodings will be listed in the periodically issued "Assigned Numbers" RFC [currently RFC-1700]. 🗂️

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

Phone: +1 818 919 3600
Fax:   +1 818 919 3614
EMail: ned@innosoft.com

John Klensin
MCI
2100 Reston Parkway
Reston, VA 22091

Phone: +1 703 715-7361
Fax:   +1 703 715-7436
EMail: klensin@mci.net

Jon Postel
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA  90292
USA

Phone: +1 310 822 1511
Fax:   +1 310 823 6714
EMail: Postel@ISI.EDU

---

Appendix A -- Grandfathered Media Types 🌸

A number of media types registered prior to 1996 would, if registered under the guidelines in this document, be placed into either the vendor or personal trees. 🌳 Reregistering those types to reflect the appropriate trees is encouraged, but not required. 💖 Ownership and change control principles outlined in this document apply to those types as if they had been registered in the trees described above. 🫶