llm-wiki/raw/official-docs/rfc9457-problem-details-http-apis.md

---
title: "RFC 9457 — Problem Details for HTTP APIs (IETF Standards Track, July 2023)"
source_type: official-doc
url: https://www.rfc-editor.org/rfc/rfc9457.html
archive_url:
vendor: IETF / M. Nottingham, E. Wilde, S. Dalal
related_branches: [feature-contract-registry-governance]
related_projects: [ca-skeleton]
tags: [official-doc, ca-skeleton, api-design, ietf, api-contract]
created: 2026-06-15
---

# RFC 9457 — Problem Details for HTTP APIs (IETF Standards Track, July 2023)

> Layer: `raw/` — 외부 자료(공식 문서 / 표준 사양)의 **원문 발췌·출처 기록**.
> 검증된 요약은 `/ingest` 후 `wiki/concepts/`에 별도 작성. 원본은 raw에 영구 보관.

## Parent / 활용 branch (필수, 최소 1개+)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-contract-registry-governance]] | D5: 외부 platform 표준(RFC 7807→9457)을 사용하는 경우에도 skeleton registry 에 mapping/version row 를 남겨야 함 — RFC 9457 이 RFC 7807 을 obsolete 하고 error envelope shape 을 변경한다는 IETF 공식 증거 |

## 출처 / Source

- 원본 URL: https://www.rfc-editor.org/rfc/rfc9457.html
- 아카이브 URL: (미제공)
- 저자 / 조직: M. Nottingham, E. Wilde, S. Dalal — IETF Standards Track
- 발행일: July 2023
- 마지막 확인일: 2026-06-15

## 왜 저장했는지 / Why archived

RFC 9457 은 RFC 7807 을 obsolete 하고 error envelope 의 외부 표준이 버전 관리된다는 사실을 공식으로 증명한다. `feature-contract-registry-governance` 브랜치의 D5 결정 — "외부 platform 표준을 쓰는 경우에도 skeleton registry 에 mapping row 를 남김" — 이 UNSUPPORTED_DECISION 으로 표시된 것을 RFC 9457 원문 인용으로 뒷받침하기 위해 보관.

## 핵심 인용 / Key quotes (verbatim, 3~5문장)

> [Abstract] "This document obsoletes RFC 7807."

> [§3.1.1 — line 250] "Consumers MUST use the \"type\" URI (after resolution, if necessary) as the problem type's primary identifier."

> [§3 — line 378] "Clients consuming problem details MUST ignore any such extensions that they don't recognize; this allows problem types to evolve and include additional information in the future."

> [§4.2 — line 469] "This specification defines the \"HTTP Problem Types\" registry for common, widely used problem type URIs, to promote reuse."

> [Appendix D — line 808] "Section 4.2 introduces a registry of common problem type URIs"

## Claims Extracted / 추출된 주장

> 이 자료가 **직접 말하는 것만** claim 으로 분리한다. 내 프로젝트에 적용한 결론은 여기 쓰지 않는다.

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| RFC9457-C1 | RFC 9457 은 RFC 7807 을 공식 폐지(obsolete)하며 HTTP API error response 의 외부 표준이 버전 관리된다 | [Abstract] "This document obsoletes RFC 7807." | `official-standard` | IETF Standards Track 을 따르는 모든 HTTP API error response 설계 | RFC 7807 → 9457 외 에도 추가 개정이 없을 것이라는 보장 없음; ca-tmpl 의 기존 RFC 7807 기반 error 코드가 자동으로 9457 호환이 됨을 증명하지 않음 |
| RFC9457-C2 | 소비자(consumer)는 반드시 `type` URI 를 problem type 의 **기본 식별자(primary identifier)**로 사용해야 한다 | [§3.1.1] "Consumers MUST use the \"type\" URI (after resolution, if necessary) as the problem type's primary identifier." | `official-standard` | RFC 9457 을 준수하는 모든 HTTP API 클라이언트 및 서버 구현 | server 측의 type URI 선택 방식(resolvable vs non-resolvable)을 규정하지 않음; 특정 프레임워크(Spring, etc.)의 기본 error 응답이 이 rule 을 준수하는지 증명하지 않음 |
| RFC9457-C3 | 소비자는 인식하지 못하는 extension member 를 반드시 무시해야 한다(forward-compatibility 규칙) | [§3] "Clients consuming problem details MUST ignore any such extensions that they don't recognize; this allows problem types to evolve and include additional information in the future." | `official-standard` | RFC 9457 을 준수하는 클라이언트 구현체; extension member 를 추가하는 server 설계 | server 측이 어떤 extension 을 추가해도 된다는 것을 무한정 허용하지 않음; IANA registry 에 없는 extension 의 의미론적 안전성은 보장하지 않음 |
| RFC9457-C4 | IETF 는 RFC 9457 과 함께 "HTTP Problem Types" IANA registry 를 신설했다 | [§4.2] "This specification defines the \"HTTP Problem Types\" registry for common, widely used problem type URIs, to promote reuse." | `official-standard` | HTTP API 의 error type URI 재사용을 원하는 모든 구현자 | registry 등록이 의무(MUST)임을 규정하지 않음; vendor-specific / application-specific / deployment-specific 값은 등록 불가(§4.2 본문) |
| RFC9457-C5 | RFC 9457 이 RFC 7807 대비 도입한 3가지 변경은 (1) common problem type URI 의 registry 신설, (2) 다수 문제(multiple problems) 처리 방식 명확화, (3) 역참조 불가 type URI 에 대한 안내 추가다 | [Appendix D] "Section 4.2 introduces a registry of common problem type URIs" [...] "Section 3 clarifies how multiple problems should be treated" [...] "Section 3.1.1 provides guidance for using type URIs that cannot be dereferenced" | `official-standard` | RFC 7807 → 9457 마이그레이션을 고려하는 API 설계자 | error envelope 의 필드 추가·삭제가 없었음을 의미하지 않음(type/status/title/detail/instance 5 멤버는 유지되지만 semantic 변경 가능); 특정 언어/프레임워크 구현체의 migration 가이드를 제공하지 않음 |

## Usage Boundaries / 적용 경계

- 이 자료가 직접 증명하는 것:
  - `RFC9457-C1`: HTTP API error response 의 외부 표준이 개정될 수 있으며 RFC 7807 은 이미 obsolete — skeleton registry 에 version/mapping row 가 필요한 이유
  - `RFC9457-C2`: error envelope 의 `type` URI 가 primary identifier 이며 소비자는 이것으로 problem type 을 식별해야 함
  - `RFC9457-C3`: extension member 를 추가해도 forward-compatible 하게 설계할 수 있음 — registry 에 새 column 추가 시 소비자 영향 최소화 가능
  - `RFC9457-C4`: 표준 error type URI 재사용을 위한 IANA registry 가 존재함
  - `RFC9457-C5`: RFC 7807 → 9457 의 3가지 구체적 변경 사항
- 이 자료가 증명하지 않는 것:
  - RFC 9457 이 RFC 7807 과 **필드 레벨에서** 하위 호환임을 보장하지 않음 — migration 검증은 별도 필요
  - Spring Boot / Keycloak 등 특정 구현체가 RFC 9457 을 자동으로 준수하는지 증명하지 않음
  - ca-tmpl 의 현재 error response 가 RFC 9457 compliant 한지 증명하지 않음
  - registry 에 외부 표준 mapping row 를 **어떤 schema 로** 추가해야 하는지 안내하지 않음 (D4 UNSUPPORTED_DECISION 영역)
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  - ca-tmpl 의 error response envelope 이 RFC 9457 의 `type`/`status`/`title`/`detail`/`instance` 구조를 따르는지 코드 검증
  - Spring Boot `ProblemDetail` (Spring 6+) 의 RFC 9457 준수 여부 공식 문서 확인 (별도 raw 자료 필요)
  - registry 의 `compatibility_impact` column 이 RFC 9457 obsolete 처리를 어떻게 반영할지 결정 (D4 UNSUPPORTED_DECISION 범위)

## 메모 / Notes

- RFC 9457 의 IANA "HTTP Problem Types" registry URL: https://iana.org/assignments/http-problem-types
- Appendix D 의 3가지 변경 중 "(2) multiple problems" 는 §3 에서 단일 response 에 여러 problem 을 담는 방법을 안내 — ca-tmpl 의 validation error 처리(복수 field 오류 시 어떻게 encapsulate 할지)에 직접 관련
- `RFC9457-C3`(forward-compatibility MUST ignore) 는 ca-tmpl registry 의 extension column 추가 시 소비자 영향을 제한하는 근거로 활용 가능 — 단 UNSUPPORTED_IMPL_DECISION 없이 직접 결론 내리지 말 것

## Related / 관련

- 같은 주제 다른 official-doc: [[raw/official-docs/opentelemetry-versioning-stability-spec]] — 외부 표준 versioning 일반 패턴
- 이 자료를 인용한 branch-note: [[raw/branch-notes/feature-contract-registry-governance]] (D5)
- wiki 요약 (생성 시): `[[wiki/concepts/rfc9457-problem-details]]` (미생성)