---
title: IANA Media Types Registry (MIME Types — Authoritative Source)
source_type: official-doc
url: https://www.iana.org/assignments/media-types/media-types.xhtml
archive_url:
status: raw
confidence: high
tags: [media-type, mime, iana, rfc6838, content-type, file-upload, serialization, registry]
related_projects: []
related_branches: [feature-file-resource-handling-contract, feature-schema-serialization-contract]
created: 2026-05-27
last_reviewed: 2026-05-27
---

# IANA Media Types Registry — Authoritative Source

> Layer: `raw/official-docs/` — IANA (Internet Assigned Numbers Authority) 의 Media Types registry 페이지 발췌. RFC 6838 / RFC 4289 / RFC 6657 의 등록 절차 + standards/vendor/personal tree 구조 + top-level type 카탈로그의 1차 출처.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-file-resource-handling-contract]] | D7 — 파일 업로드 시 허용 Content-Type whitelist 의 IANA-registered media type 사용 원칙 + 미등록/vendor tree (`application/vnd.*`) 처리 정책 |
| [[raw/branch-notes/feature-schema-serialization-contract]] | response Content-Type 의 표준 어휘 (`application/json`, `application/problem+json`, `application/xml` 등) IANA-registered 사용 원칙 |

## 컨텍스트

ca-tmpl 의 file resource handling (upload validation) 과 schema serialization (response Content-Type) 결정 시 "어떤 media type 이 공식 등록되어 있는가" 의 single source of truth. company tech blog 가 임의로 `application/json+custom` 같은 비표준 type 을 권장해도 IANA registry 에 등록되지 않으면 IANA-official 어휘가 아님. RFC 6838 의 등록 절차 + tree 구조의 normative reference 도 본 페이지에서 link.

## 출처 / Source

- 원본 URL: https://www.iana.org/assignments/media-types/media-types.xhtml
- 아카이브 URL: (미수집)
- 발행 조직: IANA (Internet Assigned Numbers Authority) — 운영: ICANN
- 발행일: 지속적 갱신 (registry — 매번 새 media type 등록 시 업데이트)
- 관련 RFC: RFC 6838 (Media Type Specifications and Registration Procedures), RFC 4289 (Multipurpose Internet Mail Extensions Part Four: Registration Procedures), RFC 6657 (Update to MIME regarding "charset" Parameter)
- 마지막 확인일: 2026-05-27 (WebFetch via https://www.iana.org/assignments/media-types/media-types.xhtml)

## 왜 저장했는지 / Why archived

file upload 의 Content-Type whitelist 와 response Content-Type 표준 어휘 결정의 1차 authoritative 출처. IANA-registered vs vendor tree (`application/vnd.*`) vs unregistered 의 정확한 구분이 보안 (예: `application/x-msdownload` 차단) 과 호환성 (예: `application/problem+json` 정식 등록 여부) 양쪽에서 critical.

## 핵심 인용 / Key quotes (verbatim, 2026-05-27 WebFetch)

> [Authority statement] "Media Types (formerly known as MIME types) and Media Subtypes will be assigned and listed by the IANA."

> [Registration procedures] "Procedures for registering Media Types can be found in RFC6838, RFC4289, and RFC6657."

> [Standards Tree oversight] "Standards Tree requests made through IETF documents will be reviewed and approved by the IESG."

> [Registration trees — Vendor/Personal] "Expert Review for Vendor and Personal Trees. For Standards Tree, see RFC6838, Section 3.1."

> [Top-level types] "application, audio, example, font, haptics, image, message, model, multipart, text, video."

> [Provisional registrations note] "Some early registrations have no registration template. The absence of a template does not imply a different or reduced registration status."

> [Parameter restriction] "The media type registry disallows parameters named 'q'."

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| IANA-MEDIA-C1 | Media Types (구 MIME types) 와 Media Subtypes 의 assignment 와 listing 은 IANA 가 담당 | [Authority statement] "Media Types (formerly known as MIME types) and Media Subtypes will be assigned and listed by the IANA." | `official-standard` | media type 의 공식 출처 식별 — IANA 가 single registry 운영 | 등록되지 않은 vendor-specific type (예: `application/x-custom-foo`) 의 사용을 금지한다는 뜻은 아님 — RFC 6838 의 `x-` prefix 정책 별도 |
| IANA-MEDIA-C2 | Media Type 등록 절차는 RFC 6838, RFC 4289, RFC 6657 에 정의됨 | [Registration procedures] "Procedures for registering Media Types can be found in RFC6838, RFC4289, and RFC6657." | `official-standard` | media type 신규 등록 시 따라야 할 normative procedure | 각 RFC 의 구체적 등록 요구사항 (template, registration form 등) 은 본 인용 범위 밖 — 해당 RFC 별도 참조 |
| IANA-MEDIA-C3 | Standards Tree 의 등록 요청 (IETF document 통한) 은 IESG (Internet Engineering Steering Group) 가 review 및 approve | [Standards Tree oversight] "Standards Tree requests made through IETF documents will be reviewed and approved by the IESG." | `official-standard` | standards tree media type 등록의 거버넌스 모델 | non-IETF 출처 의 standards tree 등록 절차는 RFC 6838 §3.1 별도 |
| IANA-MEDIA-C4 | Vendor Tree 와 Personal Tree 는 Expert Review 로 등록. Standards Tree 는 RFC 6838 §3.1 에 따름 | [Registration trees] "Expert Review for Vendor and Personal Trees. For Standards Tree, see RFC6838, Section 3.1." | `official-standard` | media type 의 3-tier tree 구조 (standards / vendor / personal) 별 등록 절차 차이 | `vnd.` (vendor) prefix vs `prs.` (personal) prefix 의 정확한 naming 규칙은 본 인용 범위 밖 — RFC 6838 §3.2-§3.3 별도 |
| IANA-MEDIA-C5 | IANA 가 등록 관리하는 top-level types: `application`, `audio`, `example`, `font`, `haptics`, `image`, `message`, `model`, `multipart`, `text`, `video` | [Top-level types] "application, audio, example, font, haptics, image, message, model, multipart, text, video." | `official-standard` | media type 의 top-level 어휘 — 이 11개 외의 top-level type 은 IANA 미등록 | 각 top-level 아래의 subtype 카탈로그는 별도 — 본 인용은 top-level 만. `haptics` 는 최근 추가된 top-level (촉각 데이터) |
| IANA-MEDIA-C6 | 일부 early registration 은 registration template 없음. template 부재가 등록 status 차이를 의미하지 않음 | [Provisional registrations note] "Some early registrations have no registration template. The absence of a template does not imply a different or reduced registration status." | `official-standard` | legacy media type (예: `text/plain`, `application/octet-stream`) 의 status 해석 | provisional vs full registration 의 다른 구분 기준은 별도 |
| IANA-MEDIA-C7 | media type registry 는 `q` 라는 이름의 parameter 등록을 disallow (Accept header 의 q-value 와 충돌 회피) | [Parameter restriction] "The media type registry disallows parameters named 'q'." | `official-standard` | 신규 media type 의 parameter naming 제약 | 기존 등록 type 의 모든 parameter naming 규칙은 RFC 6838 별도 |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - `IANA-MEDIA-C1`~`C2`: IANA 가 media type 의 authoritative registry + 등록 절차의 normative RFC
  - `IANA-MEDIA-C3`~`C4`: 3-tier tree 구조 + 각 tree 의 등록 거버넌스
  - `IANA-MEDIA-C5`: 11 개 top-level type 어휘
  - `IANA-MEDIA-C6`~`C7`: legacy 처리 + parameter naming 제약
- **이 자료가 증명하지 않는 것**:
  - 특정 subtype 의 등록 여부 — 본 페이지는 catalog 의 entry point 만, 각 type 별 detail page 가 정확한 source. 예: `application/problem+json` 등록 여부는 https://www.iana.org/assignments/media-types/application/problem+json 별도 확인 필요
  - 어떤 media type 을 application 이 사용해야 하는지의 권고 — 본 페이지는 registry 운영 정보, 사용 권고는 application/protocol spec 별도
  - 파일 확장자와 media type 의 매핑 (`.json` ↔ `application/json` 등) — 본 페이지에 직접 정의 없음, 각 type 의 detail page 가 `File extension(s)` 필드에 명시
  - browser/server 가 media type sniffing 으로 IANA 미등록 type 을 reject 하는지 — 구현체 별도 정책 (RFC 9110 §8.3 magic byte sniffing)
  - `application/x-*` (unregistered prefix) 의 사용 정책 — RFC 6838 §3.4 별도
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - 파일 업로드 whitelist 에 사용하는 type (예: `image/jpeg`, `image/png`, `application/pdf`) 의 IANA 등록 detail page 확인 + `File extension(s)` / `Encoding considerations` 필드
  - Spring `MediaType` enum 이 IANA-registered type 과 정확히 일치하는지 (`MediaType.APPLICATION_PROBLEM_JSON` 등)
  - Content-Type sniffing 정책 — 브라우저 (Chrome / Firefox) 의 MIME sniffing vs 서버 명시 type 의 우선순위
  - `application/json` vs `application/vnd.api+json` (JSON:API) vs `application/problem+json` 의 trade-off 결정 시 각 type detail page 의 reference RFC 확인

## 메모 / Notes

- WebFetch 가 본 페이지의 핵심 7 quote 를 verbatim 반환. registry 의 individual type entry (예: `application/json`) 는 각 detail page 가 source — 별도 raw 작성 후보.
- `IANA-MEDIA-C5` 의 `haptics` 는 비교적 최근 추가된 top-level (RFC 9695, 2024). RFC 6838 (2013) 원본 enumeration 에는 없음 — IANA registry 가 RFC 6838 이후 확장되었음을 시사.
- RFC 6838 §3.4 의 `x-` / `X-` prefix 정책 ("SHOULD NOT use" for new registrations) 은 본 IANA page 에 직접 인용 없음 — 별도 RFC 6838 raw 작성 권고.
- ca-tmpl 의 file upload validation 시 "whitelist by IANA-registered type" 만으로는 보안 충분하지 않음 (sniffing/magic byte 검증 필요) — 본 IANA 자료 범위 밖, 별도 source 필요.

## Related / 관련

- 같은 주제 다른 official-doc:
  - RFC 6838 (Media Type Specifications and Registration Procedures) — 별도 raw 작성 후보
  - RFC 7807 / `application/problem+json` 등록 detail page — [[raw/official-docs/problem-detail-rfc-7807]] 참조
  - RFC 9110 §8.3 (Content-Type and sniffing) — [[raw/official-docs/rfc9110-http-semantics]] (간접 관련)
- 인용하는 branch:
  - [[raw/branch-notes/feature-file-resource-handling-contract]] (D7)
  - [[raw/branch-notes/feature-schema-serialization-contract]]
- 인용하는 project:
  - [[raw/project-notes/ca-skeleton-operational-contract]]
- 인용한 wiki 요약: (미작성)