What this RFC defined
RFC 2048 defined the procedures for registering MIME media types with IANA. It specified the registration process for new types, the requirements for registration documents, and the different registration trees (IETF tree, vendor tree, personal tree). All MIME type registrations from 1996 onwards followed this RFC until its replacement.
Where you would have seen it in practice
Before RFC 2048, new MIME types were registered informally. RFC 2048 established a formal process ensuring that types like application/json, image/webp, or video/mp4 went through a consistent review and registration process. Email clients, spam filters, and content delivery systems rely on the IANA media type registry to correctly handle message content, and RFC 2048 built the process behind that registry.
How it connects to other RFCs
RFC 2048 was part of the original MIME suite alongside RFC 2045-2047 and RFC 2049. It was obsoleted by RFC 4288 in 2005, which was itself obsoleted by RFC 6838 in 2013. The IANA media type registry it established continues to be maintained under the procedures in RFC 6838.
Current status
RFC 2048 was obsoleted by RFC 4288 in 2005, which was subsequently replaced by RFC 6838 in 2013. Historical references to RFC 2048 registration requirements should be updated to reference RFC 6838. The IANA media type registry it established continues to grow under current procedures.
IANA registration procedures
RFC 2048 defined the procedures for registering new MIME media types with IANA. Before this document, there was no formal process for adding subtypes like application/pdf or image/webp; developers invented names and hoped for interoperability. RFC 2048 created three registration paths: standards-tree (through the IETF process), vendor-tree (for vendor-specific types like application/vnd.ms-excel), and personal-tree (for experimental or private types like application/x-custom).
Why it was replaced
RFC 2048 was obsoleted by RFC 4288 in 2005 and further updated by RFC 6838 in 2013. The registration procedures were simplified and clarified over time, and new subtree categories were added. The core vendor and personal namespaces (application/vnd.* and application/x-*) still work as designed, but the registration process is now easier for new standards-tree types. Nothing that references RFC 2048 in modern code is wrong, but new work should cite RFC 6838 as the current authority.
Practical impact today
The IANA media types registry now contains over 1,900 registered types. Every Content-Type value your email client sends (text/plain, text/html, application/pdf, image/jpeg, application/octet-stream) traces its legitimacy back to the registration process RFC 2048 established. If you invent a new content type for internal use, use the application/vnd.company.type or application/x-custom form; do not squat on standards-tree names, which will collide with future IANA assignments.
RFC 2048 (November 1996) defined the MIME media type registration procedures: how new Content-Type values enter the IANA registry, what documentation is required, and how the standards, vendor, and personal trees work. Obsoleted by RFC 4288 (2005) which was itself replaced by RFC 6838 (2013). The three trees (standards, vendor vnd., personal prs., and unregistered x.) established here remain the framework. Modern reference for new media types is RFC 6838.
RFC 2048 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Registration procedures for Content-Type values in IANA media type registry |
| Three trees | Standards, vendor (vnd.), personal (prs.), plus experimental (x.) |
| Standards tree | Requires IETF review; well-established general-use types |
| Vendor tree | vnd.company.type; lightweight registration for vendor-specific formats |
| Personal tree | prs.name.type; lightweight registration for individual formats |
| Unregistered | x.type or x-type; discouraged, deprecated by RFC 6648 |
| Published | November 1996 |
| Superseded by | RFC 4288 (2005), then RFC 6838 (2013) |
The four media type trees
| Tree | Prefix | Registration bar | Examples |
|---|---|---|---|
| Standards | None | IETF review required; general purpose formats | text/plain, application/pdf, image/jpeg |
| Vendor | vnd. | Company can request; lightweight review | application/vnd.ms-excel, application/vnd.google-apps.document |
| Personal | prs. | Individual can request; lightweight | application/prs.plucker |
| Unregistered (experimental) | x. or x- | No registration | text/x-vcard (legacy; deprecated) |
Common media type mistakes
application/mycompany-format without registration risks colliding with future IANA assignments. Use the vendor tree: application/vnd.mycompany.format. The vnd. prefix signals “this is a company-specific format, not a standards-tree name” and reserves the space via IANA’s lightweight vendor registration.text/plain without charset lets the client guess; text/plain; charset=utf-8 is unambiguous. Always include parameters that affect interpretation.Related standards and further reading
- RFC 2045: MIME base headers
- RFC 2046: Initial media types
- RFC 2047: Encoded-word for non-ASCII headers
- RFC 2049: Conformance criteria
- RFC 4288: Media type specifications and registration (obsoleted by RFC 6838)
- RFC 6838: Current media type registration procedures
- RFC 6648: Deprecating x- prefixes in protocol parameters
- RFC 4021: Registration of mail and MIME header fields
- Content-Type and MIME Structure: practical type usage
Frequently asked questions
Is RFC 2048 still the current registration procedure?
No. RFC 2048 was obsoleted by RFC 4288 (2005), which was itself obsoleted by RFC 6838 (2013). RFC 6838 is the current procedure. However, the framework RFC 2048 established (four trees, standards/vendor/personal/experimental) continues. Read RFC 6838 for current registration process; RFC 2048 is historical context and remains referenced for existing registered types.
How do I register a new media type?
Per RFC 6838 (current procedure). For standards tree: draft an RFC through IETF process. For vendor tree: file a request at IANA with your specification (or specification URL) and contact information; approval is lightweight. For personal tree: same process, personal identity instead of company. Free; typically completes within weeks for vendor/personal, months to years for standards tree.
What is the difference between vnd. and prs. types?
vnd. (vendor) is for organizations: companies, open-source projects, government entities. prs. (personal) is for individuals. Both have identical registration lightness; the prefix indicates who owns the format. In practice, most new registrations are vnd. because most format authorship is organizational.
Should I keep using x- prefixes I already deployed?
Continue supporting existing x- types for backward compatibility, but for new formats use registered names. RFC 6648 deprecates x- for new use but does not force retirement of existing deployments. Example: text/x-vcard was widely used before text/vcard was registered; both are accepted by parsers, but new implementations should emit the registered form.
Where can I find the current list of registered media types?
The authoritative IANA registry at iana.org/assignments/media-types. Includes all standards-tree types, vendor tree registrations (thousands as of 2026), and personal tree entries. The registry is authoritative; local file extension databases in operating systems occasionally lag or diverge. When implementing MIME-aware software, reference IANA rather than local system data.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
