RFC 7807 Quiz

**Explanation:** **Terms:** media type, Problem Details **Correct (B):** payloadの意味を示すため, 専用media typeを定義している **Options:** - A (incorrect): 動くことはあるが, Problem Detailsの意味は伝わらない - B (correct): 標準 - C (incorrect): 定義されていない **Related:** XML向けにはapplication/problem+xmlがある

**Explanation:** **Terms:** members, extensibility **Correct (A,B,C,D,E):** これらが標準member **Options:** - F (incorrect): 標準ではない, 露出も危険になりやすい **Related:** extension memberは追加できるが, 安定仕様として文書化する

**Explanation:** **Terms:** URI reference, problem type **Correct (C):** typeは分類子で, document URLやabout:blankを使うことが多い **Options:** - A (incorrect): statusがHTTP status - B (incorrect): typeの意味ではない - C (correct): errorの安定分類に使える **Related:** about:blankは, typeがHTTP statusにより暗黙と解釈される

**Explanation:** **Terms:** status member **Correct (A):** client向けの便宜であり, 別系統のstatus channelではない **Options:** - A (correct): status lineと揃える - B (incorrect): 標準memberのstatusは数値 - C (incorrect): error表現に使う **Related:** proxy等でstatusが変わるなら, 一貫性に注意

**Explanation:** **問題を出した背景:** `title` と `detail` はどちらも人間向け文字列なので, 役割を入れ替えやすい member です. summary と instance-specific detail を分けて理解する問題です. **用語:** **`title`** は problem の短い human-readable summary, **`detail`** はその発生事象に固有の説明です. **Correct:** **title**. **Why this matters:** client UI や log では, 安定した短い summary と個別事情の detail を分けて扱えると実装しやすくなります.

**Explanation:** **Terms:** interoperability, client UX **Correct (B):** 一貫schemaは実装と運用の負担を減らす **Options:** - A (incorrect): 無関係 - B (correct): これが主要コスト - C (incorrect): errorは防げない **Related:** detailやextensionで内部情報を漏らさない