Internet Engineering Task Force (IETF) S. Dalal
Request for Comments: 9745
Category: Standards Track E. Wilde
ISSN: 2070-1721 March 2025
The Deprecation HTTP response header field is used to signal to consumers of a resource (identified by a URI) that the resource will be or has been deprecated. Additionally, the deprecation link relation can be used to link to a resource that provides further information about planned or existing deprecation. It may also provide ways in which client application developers can best manage deprecation.
Deprecation HTTP Response Headerフィールドは、リソース（URIで識別される）の消費者にリソースが廃止されるか、非推奨であることを示すために使用されます。さらに、非推奨リンク関係を使用して、計画または既存の非推奨に関するさらなる情報を提供するリソースにリンクできます。また、クライアントアプリケーション開発者が非難を最適に管理できる方法を提供する場合があります。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9745.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9745で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Notational Conventions
2. The Deprecation HTTP Response Header Field
2.1. Syntax
2.2. Scope
3. The Deprecation Link Relation Type
3.1. Documentation
4. Sunset
5. Resource Behavior
6. IANA Considerations
6.1. The Deprecation HTTP Response Header Field
6.2. The Deprecation Link Relation Type
7. Security Considerations
8. Normative References
Acknowledgments
Authors' Addresses
Deprecation of an HTTP resource (Section 3.1 of [HTTP]) communicates information about the lifecycle of a resource. It encourages client applications to migrate away from the resource, discourages applications from forming new dependencies on the resource, and informs applications about the risk of continued dependence upon the resource.
HTTPリソース（[http]のセクション3.1）の非推奨は、リソースのライフサイクルに関する情報を伝えます。クライアントアプリケーションがリソースから離れて移動することを奨励し、アプリケーションがリソースに新しい依存関係を形成するのを妨げ、リソースへの継続的な依存のリスクについてアプリケーションに通知します。
The act of deprecation does not change any behavior of the resource. It informs client applications of the fact that a resource will be or has been deprecated. The Deprecation HTTP response header field can be used to convey this information at runtime and indicate when the deprecation will be in effect.
非難の行為は、リソースの行動を変えません。クライアントのアプリケーションに、リソースが廃止された、または廃止されたという事実を通知します。非推奨HTTP応答ヘッダーフィールドを使用して、実行時にこの情報を伝え、非推奨が有効になる時期を示すことができます。
In addition to the Deprecation header field, the resource provider can use other header fields such as the Link header field [LINK] to convey additional information related to deprecation. This can be information such as where to find documentation related to the deprecation, what can be used as a replacement, and when a deprecated resource becomes non-operational.
DepRecation Headerフィールドに加えて、リソースプロバイダーは、リンクヘッダーフィールド[リンク]などの他のヘッダーフィールドを使用して、非推奨に関連する追加情報を伝えることができます。これは、非推奨に関連するドキュメントを見つける場所、代替として使用できるもの、非推奨リソースが非運用になるときなどの情報です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This document uses "Structured Field Values for HTTP" [RFC9651] to specify syntax and parsing of date values.
このドキュメントでは、「HTTPの構造化されたフィールド値」[RFC9651]を使用して、日付値の構文と解析を指定します。
The term "resource" is to be interpreted as defined in Section 3.1 of [HTTP].
「リソース」という用語は、[HTTP]のセクション3.1で定義されていると解釈されます。
The Deprecation HTTP response header field allows a server to communicate to a client application that the resource in the context of the message will be or has been deprecated.
DepRECATION HTTP Response Headerフィールドにより、サーバーは、メッセージのコンテキストでのリソースが廃止された、または廃止されたというクライアントアプリケーションに通信できます。
The Deprecation HTTP response header field describes the deprecation of the resource identified with the response it occurred within (see Section 6.4.2 of [HTTP]). It conveys the deprecation date, which may be in the future (the resource in context will be deprecated at that date) or in the past (the resource in context was deprecated at that date).
非推奨HTTP応答ヘッダーフィールドは、それが発生した応答と識別されたリソースの非推奨を説明しています（[HTTP]のセクション6.4.2を参照）。将来的には非推奨日を伝えます（その日にリソースは廃止されます）または過去に（その日にコンテキストのリソースは非推奨でした）。
Deprecation is an Item Structured Header Field; its value MUST be a Date as per Section 3.3.7 of [RFC9651].
非推奨は、アイテム構造ヘッダーフィールドです。その値は、[RFC9651]のセクション3.3.7に従って日付でなければなりません。
The following example shows that the resource in context was deprecated on Friday, June 30, 2023 at 23:59:59 UTC:
次の例は、2023年6月30日金曜日23:59:59 UTCにコンテキスト内のリソースが廃止されたことを示しています。
Deprecation: @1688169599
The Deprecation header field applies to the resource identified with the response it occurred within (see Section 6.4.2 of [HTTP]), meaning that it announces the upcoming deprecation of that specific resource. However, there may be scenarios where the scope of the announced deprecation is larger than just the single resource where it appears.
非推奨ヘッダーフィールドは、それが発生した応答で識別されたリソースに適用されます（[http]のセクション6.4.2を参照）。つまり、その特定のリソースの今後の非推奨を発表します。ただし、発表された非推奨の範囲が、表示される単一のリソースよりも大きいシナリオがある場合があります。
Resources are free to define such an increased scope, and usually this scope will be documented by the resource so that consumers of the resource know about the increased scope and can behave accordingly. When doing so, it is important to take into account that such increased scoping is invisible for consumers who are unaware of the increased scoping rules. This means that these consumers will not be aware of the increased scope, and they will not interpret deprecation-related information differently from its standard meaning (i.e., it applies to the resource only).
リソースはこのような範囲の増加を自由に定義できます。通常、この範囲はリソースによって文書化され、リソースの消費者が範囲の増加を知っており、それに応じて動作することができます。そうする場合、このような増加したスコーピングは、スコーピングルールの増加に気付いていない消費者にとっては見えないことを考慮することが重要です。これは、これらの消費者が範囲の増加を認識しないことを意味し、標準的な意味とは異なる非推奨情報を異なって解釈することはありません（つまり、リソースのみに適用されます）。
Using such an increased scope still may make sense, as deprecation-related information is only a hint anyway. It is optional information that cannot be depended on, and client applications should always be implemented in ways that allow them to function without deprecation-related information. Increased scope information may help client application developers to glean additional hints from related resources and thus might allow them to implement behavior that enables them to make educated guesses about resources becoming deprecated.
除外された情報はとにかくヒントにすぎないため、このような増加スコープを使用することは依然として理にかなっているかもしれません。これはオプションの情報であり、依存することはできません。また、クライアントアプリケーションは、非推奨情報なしで機能できるようにする方法で常に実装する必要があります。スコープ情報の増加は、クライアントアプリケーション開発者が関連するリソースから追加のヒントを収集するのに役立つ可能性があり、したがって、リソースが非推奨になることについて教育を受けた推測を行うことができる動作を実装できる可能性があります。
For example, an API might not use Deprecation header fields on all of its resources but only on designated resources such as the API's home document. This means that deprecation-related information is available, but in order to get it, client application developers have to periodically inspect the home document. In this example, the extended context of the Deprecation header field would be all resources provided by the API, while the visibility of the information would only be on the home document.
たとえば、APIは、すべてのリソースでDepRecation Headerフィールドを使用しない可能性がありますが、APIのホームドキュメントなどの指定されたリソースでのみ使用できます。これは、非推奨情報が利用可能であることを意味しますが、それを取得するために、クライアントアプリケーション開発者は定期的にホームドキュメントを検査する必要があります。この例では、Deprecation Headerフィールドの拡張コンテキストはすべてAPIによって提供されるリソースですが、情報の可視性はHome文書にのみあります。
In addition to the Deprecation HTTP response header field, the server can use links with the deprecation link relation type to communicate to the client application developer where to find more information about deprecation of the context. This can happen before the actual deprecation to make a deprecation policy discoverable or after deprecation when there may be documentation about the deprecation and how to manage it.
非推奨HTTP応答ヘッダーフィールドに加えて、サーバーはDepRecationリンク関係タイプとリンクを使用して、クライアントアプリケーション開発者と通信することができます。これは、実際の非推奨の前に発生して、非難が発見できるようにしたり、非推奨とそれを管理する方法についての文書がある場合に、非難の後に発生する可能性があります。
This specification places no restrictions on the representation of the linked deprecation policy. In particular, the deprecation policy may be available as human-readable documentation or as a machine-readable description.
この仕様は、リンクされた非推奨ポリシーの表現に制限を設けません。特に、非推奨ポリシーは、人間の読み取り可能なドキュメントとして、または機械読み取り可能な説明として利用できる場合があります。
The purpose of the Deprecation header field is to provide a hint about deprecation to the resource consumer. Upon reception of the Deprecation header field, the client application developer can look up the resource's documentation in order to find deprecation-related information. The documentation MAY provide a guide and timeline for migrating away from the deprecated resource to a new resource(s) that replaces the deprecated resource, if applicable. The resource provider can provide a link to the resource's documentation using a Link header field with the relation type deprecation as shown below:
非推奨ヘッダーフィールドの目的は、リソース消費者に非推奨についてのヒントを提供することです。非推奨ヘッダーフィールドを受信すると、クライアントアプリケーション開発者は、非推奨情報を見つけるためにリソースのドキュメントを調べることができます。このドキュメントは、該当する場合、非推奨リソースを置き換える非推奨リソースから離れて移動するためのガイドとタイムラインを提供する場合があります。リソースプロバイダーは、以下に示すように、関係タイプの非推測を備えたリンクヘッダーフィールドを使用して、リソースのドキュメントへのリンクを提供できます。
Link: <https://developer.example.com/deprecation>;
rel="deprecation"; type="text/html"
In this example, the linked content provides additional information about deprecation of the resource in context. There is no Deprecation header field in the response; thus, the resource is not (yet) deprecated. However, the resource already exposes a link where information describing how deprecation is managed for the resource is available. This may be the documentation explaining the circumstances in which deprecation might take place and the deprecation policies. For example, a policy may indicate that deprecation of a resource(s) will always be signaled in the dedicated places at least N days ahead of the planned deprecation date and then the resource(s) would be deprecated on the planned date. Or a policy may indicate that the resource(s) would be deprecated first and then be signaled as deprecated at dedicated places. The documentation, in addition to the deprecation policy, may also provide a migration guide explaining to consumers of the resource how to migrate to a new or alternate resource(s) before the deprecation date. Such policy and documentation would be very useful to consumers of the resource to plan ahead and migrate successfully.
この例では、リンクされたコンテンツは、コンテキストにおけるリソースの非推奨に関する追加情報を提供します。応答に非推奨ヘッダーフィールドはありません。したがって、リソースは（まだ）非推奨ではありません。ただし、リソースはすでにリンクを公開しています。リンクは、リソースの非推奨が利用可能であることを説明する情報です。これは、非難が起こる可能性がある状況と非推奨政策を説明する文書である可能性があります。たとえば、ポリシーは、リソースの非推奨が、計画された非推奨日より少なくともN日の専用の場所で常に合図され、その後、計画日にリソースが廃止されることを示している可能性があります。または、ポリシーは、リソースが最初に廃止され、その後専用の場所で廃止されたものとして信号を受けることを示す場合があります。ドキュメントは、非推奨ポリシーに加えて、非推奨の前に新規または代替リソースに移行する方法をリソースの消費者に説明する移行ガイドを提供する場合があります。このようなポリシーとドキュメントは、リソースの消費者にとって、事前に計画し、うまく移行するために非常に役立ちます。
The following example uses the same Link header field but also announces a deprecation date using a Deprecation header field:
次の例では、同じリンクヘッダーフィールドを使用しますが、非推奨ヘッダーフィールドを使用した非推奨日も発表します。
Deprecation: @1688169599
Link: <https://developer.example.com/deprecation>;
rel="deprecation"; type="text/html"
Given that the deprecation date is in the past, the linked information resource may have been updated to include information about the deprecation, allowing consumers to discover information about the deprecation and how to best manage it.
非推奨の日付が過去のものであることを考えると、リンクされた情報リソースが更新され、非推奨に関する情報が含まれている可能性があり、消費者は非推奨とそれを最適に管理する方法に関する情報を発見することができます。
In addition to the deprecation-related information, if the resource provider wants to convey to the client application that the deprecated resource is expected to become unresponsive at a specific point in time, the Sunset HTTP header field [RFC8594] can be used in addition to the Deprecation header field.
非推奨情報に加えて、リソースプロバイダーがクライアントアプリケーションに特定の時点で非反応することが予想されることをクライアントアプリケーションに伝えたい場合、Sunset HTTPヘッダーフィールド[RFC8594]を使用して、非難ヘッダーフィールドに加えて使用できます。
The timestamp given in the Sunset HTTP header field MUST NOT be earlier than the one given in the Deprecation header field. If that happens (for example, due to misconfiguration of deployment of the resource or an error), the client application developer SHOULD consult the resource developer to get clarification.
サンセットHTTPヘッダーフィールドで与えられるタイムスタンプは、非推奨ヘッダーフィールドに与えられたものよりも早くてはなりません。それが起こった場合（たとえば、リソースの展開またはエラーの誤った構成のために）、クライアントアプリケーション開発者はリソース開発者に相談して明確化を取得する必要があります。
The following example shows that the resource in context was deprecated on Friday, June 30, 2023 at 23:59:59 UTC and its sunset date is Sunday, June 30, 2024 at 23:59:59 UTC. Please note that for historical reasons the Sunset HTTP header field uses a different data format for date.
次の例は、2023年6月30日金曜日23:59:59 UTCに、その日曜日は2024年6月30日日曜日23:59:59 UTCで、コンテキスト内のリソースが廃止されたことを示しています。歴史的な理由で、サンセットHTTPヘッダーフィールドは、日付に異なるデータ形式を使用していることに注意してください。
Deprecation: @1688169599
Sunset: Sun, 30 Jun 2024 23:59:59 UTC
The act of deprecation does not change any behavior of the resource. The presence of a Deprecation header field in a response is not meant to signal a change in the meaning or function of a resource in the context; consumers can still use the resource in the same way as they did before the resource was declared deprecated.
非難の行為は、リソースの行動を変えません。応答における非推奨ヘッダーフィールドの存在は、コンテキスト内のリソースの意味または機能の変化を示すことを意図したものではありません。消費者は、リソースが非推奨と宣言される前と同じように、リソースを使用することができます。
The Deprecation HTTP response header field has been added to the "Hypertext Transfer Protocol (HTTP) Field Name Registry" (Section 16.3.1 of [HTTP]) as follows:
次のように、Deprecation HTTP応答ヘッダーフィールドは「ハイパーテキスト転送プロトコル（HTTP）フィールド名レジストリ」（[HTTP]のセクション16.3.1）に追加されました。
Field Name:
フィールド名：
Deprecation
非難
Status:
状態：
permanent
永続
Structured Type:
構造化されたタイプ：
Item
アイテム
Reference:
参照：
RFC 9745, Section 2: The Deprecation HTTP Response Header Field
RFC 9745、セクション2：非推奨HTTP応答ヘッダーフィールド
The deprecation link relation type has been added to the "Link Relation Types" registry (Section 4.2 of [LINK]) as follows:
次のように、Deprecation Link関係タイプは「リンク関係タイプ」レジストリ（[リンク]のセクション4.2）に追加されました。
Relation Name:
関係名：
deprecation
非難
Description:
説明：
Refers to documentation (intended for human consumption) about the deprecation of the link's context.
リンクのコンテキストの非難に関するドキュメント（人間の消費を目的とした）を指します。
Reference:
参照：
RFC 9745, Section 3
RFC 9745、セクション3
The Deprecation header field should be treated as a hint, meaning that the resource is indicating (but not guaranteeing with certainty) that it will be or has been deprecated. Deprecated resources function as they would have without sending the Deprecation header field, even though non-functional details may be affected (e.g., they have less efficiency and longer response times).
非推奨ヘッダーフィールドはヒントとして扱う必要があります。つまり、リソースは、それが廃止された、または廃止されたことを示している（確実に保証するものではない）ことを意味します。非機能的な詳細が影響を受ける可能性がありますが（たとえば、効率が低く、応答時間が長くなる場合）、非難ヘッダーフィールドを送信せずに持つように機能します。
The resource's documentation should provide additional information about the deprecation, such as recommendations for replacement. Developers of client applications consuming the resource SHOULD always check the referred resource's documentation to verify authenticity and accuracy. In cases where a Link header field is used to provide documentation, one should assume (unless served over HTTPS) that the content of the Link header field may not be secure, private, or integrity-guaranteed, so due caution should be exercised when using it (see Section 5 of [LINK] for more details). In cases where the Deprecation header field value is in the past, the client application developers MUST no longer assume that the behavior of the resource will remain the same as before the deprecation date. In cases where the Deprecation header field value is a date in the future, it informs client application developers about the effective date in the future for deprecation. Therefore, client application developers consuming the resource SHOULD, if possible, consult the resource developer to discuss potential impact due to deprecation and plan for possible transition to a recommended resource(s).
リソースのドキュメントは、交換の推奨など、非難に関する追加情報を提供する必要があります。リソースを消費するクライアントアプリケーションの開発者は、紹介されたリソースのドキュメントを常に確認して、信頼性と正確性を確認する必要があります。リンクヘッダーフィールドがドキュメントを提供するために使用される場合、リンクヘッダーフィールドのコンテンツが安全、プライベート、または整合性の保証がない場合があると仮定する必要があるため、使用する場合は注意を払う必要があります（[リンク]のセクション5を参照）。非推奨ヘッダーフィールド値が過去にある場合、クライアントアプリケーション開発者は、リソースの動作が非推奨日の前と同じままであると想定する必要はありません。DepRecation Headerフィールド値が将来の日付である場合、クライアントアプリケーション開発者に、将来の発効日を非難することを通知します。したがって、リソースを消費するクライアントアプリケーション開発者は、可能であれば、リソース開発者に相談して、推奨されるリソースへの移行の可能性を非難し、計画するための潜在的な影響について議論する必要があります。
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[LINK] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8594] Wilde, E., "The Sunset HTTP Header Field", RFC 8594,
DOI 10.17487/RFC8594, May 2019,
<https://www.rfc-editor.org/info/rfc8594>.
[RFC9651] Nottingham, M. and P. Kamp, "Structured Field Values for
HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
<https://www.rfc-editor.org/info/rfc9651>.
The authors would like to thank Nikhil Kolekar, Darrel Miller, Mark Nottingham, and Roberto Polli for their contributions.
著者は、Nikhil Kolekar、Darrel Miller、Mark Nottingham、およびRoberto Polliの貢献に感謝したいと思います。
The authors take all responsibility for errors and omissions.
著者は、エラーと不作為に対してすべての責任を負います。
Sanjay Dalal
Email: sanjay.dalal@cal.berkeley.edu
URI: https://github.com/sdatspun2
Erik Wilde
Email: erik.wilde@dret.net
URI: http://dret.net/netdret