donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
511b6bb022af3aec410d3fc71dd4a14a82bc608f
llm-wiki/raw/official-docs/iana-media-types-registry.md
T

10 KiB
Raw Blame History

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

왜 저장했는지 / 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 / 관련

Reference in New Issue View Git Blame Copy Permalink