[要約] RFC 8594は、HTTPヘッダーフィールドの1つであるSunsetヘッダーフィールドに関する仕様を提供しています。この仕様の目的は、リソースの廃止予定日をクライアントに通知し、適切な対応を促すことです。
Internet Engineering Task Force (IETF) E. Wilde
Request for Comments: 8594 May 2019
Category: Informational
ISSN: 2070-1721
The Sunset HTTP Header Field
Sunset HTTPヘッダーフィールド
Abstract
概要
This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future. It also defines a sunset link relation type that allows linking to resources providing information about an upcoming resource or service sunset.
この仕様は、Sunset HTTP応答ヘッダーフィールドを定義します。これは、URIが将来、指定されたポイントで応答しなくなる可能性があることを示します。また、今後のリソースまたはサービスの日没に関する情報を提供するリソースへのリンクを可能にする日没リンク関係タイプも定義します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc8594.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8594で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Temporary Resources . . . . . . . . . . . . . . . . . . . 3
1.2. Migration . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Retention . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Deprecation . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Sunset HTTP Response Header Field . . . . . . . . . . . . 4
4. Sunset and Caching . . . . . . . . . . . . . . . . . . . . . 5
5. Sunset Scope . . . . . . . . . . . . . . . . . . . . . . . . 6
6. The Sunset Link Relation Type . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.1. The Sunset Response Header Field . . . . . . . . . . . . 7
7.2. The Sunset Link Relation Type . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
As a general rule, URIs should be stable and persistent so that applications can use them as stable and persistent identifiers for resources. However, there are many scenarios where, for a variety of reasons, URIs have a limited lifetime. In some of these scenarios, this limited lifetime is known in advance. In this case, it can be useful for clients if resources make this information about their limited lifetime known. This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future.
一般的なルールとして、URIは、アプリケーションがリソースの安定した永続的な識別子として使用できるように、安定して永続的である必要があります。ただし、さまざまな理由により、URIの有効期間が限られているシナリオは数多くあります。これらのシナリオのいくつかでは、この限られた寿命は前もってわかっています。この場合、リソースがこの限られた寿命に関するこの情報を知っていると、クライアントにとって役立ちます。この仕様は、Sunset HTTP応答ヘッダーフィールドを定義します。これは、URIが将来、指定されたポイントで応答しなくなる可能性があることを示します。
This specification also defines a sunset link relation type that allows information to be provided about 1) the sunset policy of a resource or a service, and/or 2) upcoming sunsets, and/or 3) possible mitigation scenarios for resource/service users. This specification does not place any constraints on the nature of the linked resource, which can be targeted to humans, machines, or both.
この仕様は、1）リソースまたはサービスの日没ポリシー、および/または2）今後の日没、および/または3）リソース/サービスユーザーの可能な軽減シナリオに関する情報を提供できる日没リンク関係タイプも定義します。この仕様は、人間、マシン、またはその両方を対象とすることができるリンクされたリソースの性質に制約を課しません。
Possible scenarios for known lifetimes of resources include, but are not limited to, the following scenarios.
リソースの既知のライフタイムの考えられるシナリオには、次のシナリオが含まれますが、これらに限定されません。
Some resources may have a limited lifetime by definition. For example, a pending shopping order represented by a resource may already list all order details, but it may only exist for a limited time unless it is confirmed and only then becomes an acknowledged shopping order. In such a case, the service managing the pending shopping order can make this limited lifetime explicit, allowing clients to understand that the pending order, unless confirmed, will disappear at some point in time.
一部のリソースは、定義上、有効期間が限られている場合があります。たとえば、リソースで表される保留中のショッピング注文には、すでにすべての注文の詳細がリストされている場合がありますが、確認されずに確認済みのショッピング注文になるまで、限られた時間しか存在しない場合があります。このような場合、保留中の注文を管理するサービスは、この限られた有効期間を明示的にすることができ、クライアントは、確認されない限り、保留中の注文がいつか消えることを理解できます。
If resources are changing identity because a service migrates them, then this may be known in advance. While it may not yet be appropriate to use HTTP redirect status codes (3xx), it may be interesting for clients to learn about the service's plan to take down the original resource.
サービスがリソースを移行したためにリソースがIDを変更している場合、これは事前にわかっている可能性があります。 HTTPリダイレクトステータスコード（3xx）を使用することはまだ適切ではないかもしれませんが、クライアントが元のリソースを削除するサービスの計画について知るのは興味深いかもしれません。
There are many cases where regulation or legislation require that resources are kept available for a certain amount of time. However, in many cases there is also a requirement for those resources to be permanently deleted after some period of time. Since the deletion of the resource in this scenario is governed by well-defined rules, it could be made explicit for clients interacting with the resource.
規制または法律により、リソースを一定期間利用できるようにしておく必要がある場合が多くあります。ただし、多くの場合、これらのリソースを一定期間後に完全に削除する必要があります。このシナリオでのリソースの削除は明確に定義されたルールによって管理されるため、リソースと対話するクライアントに対して明示的にすることができます。
For Web APIs one standard scenario is that an API or specific subsets of an API may get deprecated. Deprecation often happens in two stages: the first stage being that the API is not the preferred or recommended version anymore and the second stage being that the API or a specific version of the API gets decommissioned.
Web APIの1つの標準的なシナリオは、APIまたはAPIの特定のサブセットが廃止される可能性があることです。非推奨は多くの場合2つの段階で発生します。第1段階はAPIが推奨または推奨バージョンではなくなったことであり、第2段階はAPIまたはAPIの特定のバージョンが廃止されることです。
For the first stage (the API is not the preferred or recommended version anymore), the Sunset header field is not appropriate: at this stage, the API remains operational and can still be used. Other mechanisms can be used for signaling that first stage that might help with more visible deprecation management, but the Sunset header field does not aim to represent that information.
最初の段階（APIが推奨または推奨バージョンではなくなった）の場合、Sunsetヘッダーフィールドは適切ではありません。この段階では、APIは引き続き機能し、引き続き使用できます。他のメカニズムを使用して、より明確な非推奨管理に役立つ可能性があるその最初のステージをシグナリングできますが、Sunsetヘッダーフィールドはその情報を表すことを目的としていません。
For the second stage (the API or a specific version of the API gets decommissioned), the Sunset header field is appropriate: that is when the API or a version does become unresponsive. From the Sunset header field's point of view, it does not matter that the API may not have been the preferred or recommended version anymore. The only thing that matters is that it will become unresponsive and that this time can be advertised using the Sunset header field.
2番目のステージ（APIまたはAPIの特定のバージョンが廃止される）では、Sunsetヘッダーフィールドが適切です。つまり、APIまたはバージョンが応答しなくなったときです。 Sunsetヘッダーフィールドの観点からは、APIが推奨バージョンまたは推奨バージョンでなくなった可能性があることは問題ではありません。重要なのは、応答しなくなることと、今回はSunsetヘッダーフィールドを使用してアドバタイズできることです。
In this scenario, the announced sunset date typically affects all of the deprecated API or parts of it (i.e., just deprecated sets of resources), and not just a single resource. In this case, it makes sense for the API to define rules about how an announced sunset on a specific resource (such as the API's home/start resource) implies the sunsetting of the whole API or parts of it (i.e., sets of resources), and not just the resource returning the sunset header field. Section 5 discusses how the scope of the Sunset header field may change because of how a resource is using it.
このシナリオでは、発表された廃止日は通常、単一のリソースだけでなく、廃止予定のすべてのAPIまたはその一部（つまり、廃止予定のリソースのセットのみ）に影響します。この場合、APIが特定のリソース（APIのホーム/開始リソースなど）で発表された廃止が、API全体またはその一部（つまり、リソースのセット）の廃止をどのように意味するかに関するルールを定義することは理にかなっています、そして日没のヘッダーフィールドを返すリソースだけではありません。セクション5では、リソースが使用しているためにSunsetヘッダーフィールドのスコープがどのように変化するかについて説明します。
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]で説明されているように解釈されます。
The Sunset HTTP response header field allows a server to communicate the fact that a resource is expected to become unresponsive at a specific point in time. It provides information for clients that they can use to control their usage of the resource.
Sunset HTTP応答ヘッダーフィールドを使用すると、サーバーは、特定の時点でリソースが応答しなくなることが予想されるという事実を伝えることができます。リソースの使用を制御するためにクライアントが使用できる情報を提供します。
The Sunset header field contains a single timestamp that advertises the point in time when the resource is expected to become unresponsive. The Sunset value is an HTTP-date timestamp, as defined in Section 7.1.1.1 of [RFC7231], and SHOULD be a timestamp in the future.
Sunsetヘッダーフィールドには、リソースが応答しなくなることが予想される時点を通知する単一のタイムスタンプが含まれます。 [RFC7231]のセクション7.1.1.1で定義されているように、サンセット値はHTTP日付のタイムスタンプであり、将来のタイムスタンプにする必要があります（SHOULD）。
It is safest to consider timestamps in the past mean the present time, meaning that the resource is expected to become unavailable at any time.
過去のタイムスタンプは現在の時間を意味すると考えるのが最も安全です。つまり、リソースはいつでも利用できなくなることが予想されます。
Sunset = HTTP-date
For example:
例えば：
Sunset: Sat, 31 Dec 2018 23:59:59 GMT Clients SHOULD treat Sunset timestamps as hints: it is not guaranteed that the resource will, in fact, be available until that time and will not be available after that time. However, since this information is provided by the resource itself, it does have some credibility.
サンセット：2018年12月31日、土曜日23:59:59 GMTクライアントはサンセットタイムスタンプをヒントとして扱う必要があります。実際には、リソースがその時間まで利用可能であり、その後は利用できないことは保証されません。ただし、この情報はリソース自体によって提供されるため、ある程度の信頼性があります。
After the Sunset time has arrived, it is likely that interactions with the resource will result in client-side errors (HTTP 4xx status codes), redirect responses (HTTP 3xx status codes), or the client might not be able to interact with the resource at all. The Sunset header field does not expose any information about which of those behaviors can be expected.
日没時間に達した後、リソースとのやり取りがクライアント側エラー（HTTP 4xxステータスコード）、リダイレクト応答（HTTP 3xxステータスコード）になるか、クライアントがリソースとやり取りできない可能性がありますまったく。 Sunsetヘッダーフィールドは、これらの動作のどれが期待できるかについての情報を公開しません。
Clients not interpreting an existing Sunset header field can operate as usual and simply may experience the resource becoming unavailable without recognizing any notification about it beforehand.
既存のSunsetヘッダーフィールドを解釈しないクライアントは通常どおり動作し、リソースに関する通知を事前に認識せずにリソースが使用できなくなるだけです。
It should be noted that the Sunset HTTP response header field serves a different purpose than HTTP caching [RFC7234]. HTTP caching is concerned with making resource representations (i.e., represented resource state) reusable so that they can be used more efficiently. This is achieved by using header fields that allow clients and intermediaries to better understand when a resource representation can be reused or when resource state (and, thus, the representation) may have changed.
なお、Sunset HTTPレスポンスヘッダーフィールドは、HTTPキャッシング[RFC7234]とは異なる目的を果たします。 HTTPキャッシングは、リソース表現（つまり、表現されたリソースの状態）を再利用可能にすることで、リソースをより効率的に使用できるようにします。これは、クライアントと仲介者がリソース表現を再利用できる時期や、リソースの状態（つまり表現）が変更された時期をよりよく理解できるようにするヘッダーフィールドを使用することで実現されます。
The Sunset header field is not concerned with resource state at all. It only signals that a resource is expected to become unavailable at a specific point in time. There are no assumptions about if, when, or how often a resource may change state in the meantime.
Sunsetヘッダーフィールドは、リソースの状態とはまったく関係ありません。リソースが特定の時点で使用できなくなることが予想されることを通知するだけです。その間にリソースが状態を変更するかどうか、いつ、どのくらいの頻度であるかについての仮定はありません。
For these reasons, the Sunset header field and HTTP caching should be seen as complementary and not as overlapping in scope and functionality.
これらの理由により、SunsetヘッダーフィールドとHTTPキャッシングは、スコープと機能が重複しているのではなく、補完的であると見なされます。
This also means that applications acting as intermediaries, such as search engines or archives that make resources discoverable, should treat Sunset information differently from caching information. These applications may use Sunset information for signaling to users that a resource may become unavailable. But they still have to account for the fact that resource state can change in the meantime and that Sunset information is a hint and, thus, future resource availability may differ from the advertised timestamp.
これは、リソースを検出可能にする検索エンジンやアーカイブなどの仲介者として機能するアプリケーションは、日没情報をキャッシュ情報とは異なる方法で処理する必要があることも意味します。これらのアプリケーションは、リソースが使用できなくなる可能性があることをユーザーに通知するために日没情報を使用する場合があります。ただし、リソースの状態はその間に変化する可能性があり、サンセット情報はヒントであるため、将来のリソースの可用性が通知されたタイムスタンプと異なる可能性があるという事実を考慮する必要があります。
The Sunset header field applies to the resource that returns it, meaning that it announces the upcoming sunset of that specific resource. However, as discussed in Section 1.4, there may be scenarios where the scope of the announced Sunset information is larger than just the single resource where it appears.
Sunsetヘッダーフィールドは、それを返すリソースに適用されます。つまり、その特定のリソースの今後の廃止を通知します。ただし、セクション1.4で説明したように、発表された日没情報の範囲が、それが表示される単一のリソースだけよりも大きいシナリオがある場合があります。
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. However, 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 Sunset information different from its standard meaning (i.e., it applies to the resource only).
リソースは、このように拡大されたスコープを自由に定義できます。通常、このスコープはリソースによって文書化されるため、リソースのコンシューマーは、拡大されたスコープを認識し、それに応じて動作できます。ただし、このようなスコープの増加は、スコープの規則の増加を認識していない消費者には見えないことを考慮することが重要です。つまり、これらのコンシューマはスコープの拡大を認識せず、標準の意味とは異なる日没情報を解釈しません（つまり、リソースにのみ適用されます）。
Using such an increased scope still may make sense, as Sunset information is only a hint anyway; thus, it is optional information that cannot be depended on, and clients should always be implemented in ways that allow them to function without Sunset information. Increased scope information may help clients to glean additional hints from resources (e.g., concluding that an API is being deprecated because its home/start resource announces a Sunset) and, thus, might allow them to implement behavior that allows them to make educated guesses about resources becoming unavailable.
とにかく日没の情報はヒントに過ぎないので、そのように拡大されたスコープを使用することは依然として意味があるかもしれません。したがって、これは依存できないオプション情報であり、クライアントは常に、日没情報なしで機能できるように実装する必要があります。スコープ情報の増加は、クライアントがリソースから追加のヒントを収集するのに役立ち（たとえば、ホーム/開始リソースが日没を発表するため、APIが非推奨になっていると結論付ける）、したがって、クライアントが知識を推測できる動作を実装できるようになる可能性があります。リソースが利用できなくなります。
The Sunset HTTP header field indicates the upcoming retirement of a resource or a service. In addition, a resource may want to make information available that provides additional information about how retirement will be handled for resources or services. This information can be broadly described by the following three topics:
Sunset HTTPヘッダーフィールドは、リソースまたはサービスの今後の廃止を示します。さらに、リソースは、リソースまたはサービスのリタイアがどのように処理されるかについての追加情報を提供する情報を利用可能にしたい場合があります。この情報は、次の3つのトピックで大まかに説明できます。
Sunset policy: The policy for which resources and in which way sunsets may occur may be published as part of service's description. Sunsets may only/mostly affect a subset of a service's resources, and they may be exposed according to a certain policy (e.g., one week in advance).
日没ポリシー：サービスの説明の一部として、どのリソースのどのような方法で日没が発生するかについてのポリシーが公開される場合があります。日没は、サービスのリソースのサブセットにのみ/主に影響を与える可能性があり、特定のポリシー（たとえば、1週間前）に従って公開される可能性があります。
Upcoming sunset: There may be additional information about an upcoming sunset, which can be published as a resource that can be consumed by those looking for this additional information.
今後の日没：今後の日没に関する追加情報がある可能性があります。これは、この追加情報を探している人が利用できるリソースとして公開できます。
Sunset mitigation: There may be information about possible mitigation/migration strategies, such as possible ways how resource users can switch to alternative resources/services.
日没の緩和：リソースユーザーが代替のリソース/サービスに切り替える方法など、考えられる緩和/移行戦略に関する情報がある場合があります。
Any information regarding the above issues (and possibly additional ones) can be made available through a URI that then can be linked to using the sunset link relation type. This specification places no constraints on the scope or the type of the linked resource. The scope can be for a resource or for a service. The type is determined by the media type of the linked resource and can be targeted to humans, machines, or both.
上記の問題（および場合によっては追加の問題）に関する情報は、URIを介して利用可能にでき、URIは日没リンク関係タイプを使用してリンクできます。この仕様は、リンクされたリソースのスコープまたはタイプに制約を課しません。スコープは、リソースまたはサービスの場合があります。タイプは、リンクされたリソースのメディアタイプによって決定され、人間、マシン、またはその両方を対象とすることができます。
If the linked resource does provide machine-readable information, consumers should be careful before acting on this information. Such information may, for example, instruct consumers to use a migration rule so that sunset resources can be accessed at new URIs. However, this kind of information amounts to a possibly large-scale identity migration of resources, so it is crucial that the migration information is authentic and accurate.
リンクされたリソースが機械可読情報を提供する場合、消費者はこの情報に基づいて行動する前に注意する必要があります。そのような情報は、たとえば、サンセットリソースに新しいURIでアクセスできるように、移行ルールを使用するようにコンシューマに指示する場合があります。ただし、この種の情報はリソースの大規模なID移行に相当するため、移行情報が信頼でき、正確であることが重要です。
The Sunset response header field has been added to the "Permanent Message Header Field Names" registry (see [RFC3864]), taking into account the guidelines given by HTTP/1.1 [RFC7231].
HTTP / 1.1 [RFC7231]によって提供されたガイドラインを考慮して、Sunset応答ヘッダーフィールドが「Permanent Message Header Field Names」レジストリ（[RFC3864]を参照）に追加されました。
Header Field Name: Sunset
ヘッダーフィールド名：日没
Protocol: http
プロトコル：http
Status: informational
ステータス：情報
Author/Change controller: IETF
作成者/変更コントローラ：IETF
Reference: RFC 8594
リファレンス：RFC 8594
The sunset link relation type has been added to the permanent "Link Relation Types" registry according to Section 4.2 of [RFC8288]:
[RFC8288]のセクション4.2に従って、サンセットリンク関係タイプが永続的な「リンク関係タイプ」レジストリに追加されました。
Relation Name: sunset
関係名：日没
Description: Identifies a resource that provides information about the context's retirement policy.
説明：コンテキストの廃棄ポリシーに関する情報を提供するリソースを識別します。
Reference: RFC 8594
リファレンス：RFC 8594
Generally speaking, information about upcoming sunsets can leak information that otherwise might not be available. For example, a resource representing a registration can leak information about the expiration date when it exposes sunset information. For this reason, any use of sunset information where the sunset represents an expiration or allows the calculation of another date (such as calculating a creation date because it is known that resources expire after one year) should be treated in the same way as if this information would be made available directly in the resource's representation.
一般的に言えば、今後の日没に関する情報は、他の方法では入手できない情報を漏らす可能性があります。たとえば、登録を表すリソースは、日没情報を公開するときに、有効期限に関する情報を漏らす可能性があります。このため、日没が有効期限を表す、または別の日付の計算を許可する日没情報の使用（リソースが1年後に期限切れになることがわかっているために作成日の計算など）は、これと同じように扱う必要があります。情報は、リソースの表現で直接利用できるようになります。
The Sunset header field SHOULD be treated as a resource hint, meaning that the resource is indicating (and not guaranteeing with certainty) its potential retirement. The definitive test whether or not the resource in fact is available will be to attempt to interact with it. Applications should never treat an advertised Sunset date as a definitive prediction of what is going to happen at the specified point in time: the Sunset indication may have been inserted by an intermediary or the advertised date may get changed or withdrawn by the resource owner.
Sunsetヘッダーフィールドはリソースヒントとして扱われる必要があります（SHOULD）。これは、リソースが潜在的なリタイアを示している（そして確実に保証していない）ことを意味します。リソースが実際に利用可能かどうかの決定的なテストは、リソースとの対話を試みることです。アプリケーションは、アドバタイズされたサンセットの日付を、指定された時点で発生することの最終的な予測として決して扱わないでください。仲介者によってサンセットの表示が挿入されたか、アドバタイズされた日付がリソース所有者によって変更または撤回される場合があります。
The main purpose of the Sunset header field is to signal intent so that applications using resources may get a warning ahead of time and can react accordingly. What an appropriate reaction is (such as switching to a different resource or service), what it will be based on (such as machine-readable formats that allow the switching to be done automatically), and when it will happen (such as ahead of the advertised date or only when the resource in fact becomes unavailable) is outside the scope of this specification.
Sunsetヘッダーフィールドの主な目的は、リソースを使用するアプリケーションが事前に警告を受け取り、それに応じて対応できるように、意図を通知することです。適切な対応とは（別のリソースまたはサービスへの切り替えなど）、それに基づくもの（自動的に切り替えを実行できる機械可読形式など）、およびそれが発生するタイミング（前など）アドバタイズされた日付またはリソースが実際に利用できなくなったときのみ）は、この仕様の範囲外です。
In cases where a sunset policy is linked by using the sunset link relation type, clients SHOULD be careful about taking any actions based on this information. It SHOULD be verified that the information is authentic and accurate. Furthermore, it SHOULD be tested that this information is only applied to resources that are within the scope of the policy, making sure that sunset policies cannot "hijack" resources by for example providing migration information for them.
日没ポリシーが日没リンクリンクタイプを使用してリンクされている場合、クライアントはこの情報に基づいてアクションを実行するように注意する必要があります。情報が本物で正確であることを確認する必要があります。さらに、この情報がポリシーの範囲内のリソースにのみ適用されることをテストして、たとえば、移行情報を提供するなどして、サンセットポリシーがリソースを「ハイジャック」できないことを確認する必要があります。
If a resource has been created in an archive that, for management or compliance reasons, stores resources for ten years and permanently deletes them afterwards, the Sunset header field can be used to expose this information. If such a resource has been created on November 11, 2016, then the following header field can be included in responses:
管理またはコンプライアンス上の理由で、リソースを10年間保存し、後で完全に削除するアーカイブにリソースが作成されている場合、Sunsetヘッダーフィールドを使用してこの情報を公開できます。そのようなリソースが2016年11月11日に作成された場合、次のヘッダーフィールドを応答に含めることができます。
Sunset: Wed, 11 Nov 2026 11:11:11 GMT
This allows clients that are aware of the Sunset header field to understand that the resource likely will become unavailable at the specified point in time. Clients can decide to ignore this information, adjust their own behavior accordingly, or alert applications or users about this timestamp.
これにより、Sunsetヘッダーフィールドを認識しているクライアントは、指定された時点でリソースが使用できなくなる可能性があることを理解できます。クライアントは、この情報を無視するか、独自の動作を適宜調整するか、またはこのタイムスタンプについてアプリケーションまたはユーザーに警告することを決定できます。
Even though the Sunset header field is made available by the resource itself, there is no guarantee that the resource indeed will become unavailable, and if so, how the response will look like for requests made after that timestamp. In case of the archive used as an example here, the resource indeed may be permanently deleted, and requests for the URI after the Sunset timestamp may receive a "410 Gone" HTTP response. (This is assuming that the archive keeps track of the URIs that it had previously assigned; if not, the response may be a more generic "404 Not Found".)
Sunsetヘッダーフィールドはリソース自体によって利用可能になりますが、リソースが実際に利用できなくなるという保証はありません。利用できない場合は、そのタイムスタンプ以降に行われたリクエストに対する応答がどのようになるかは保証されません。ここで例として使用されているアーカイブの場合、リソースは実際に完全に削除される可能性があり、Sunsetタイムスタンプ後のURIのリクエストは「410 Gone」HTTP応答を受信する可能性があります。 （これは、アーカイブが以前に割り当てたURIを追跡していることを前提としています。そうでない場合、応答はより一般的な「404 Not Found」になる可能性があります。）
Before the Sunset header field even appears for the first time (it may not appear from the very beginning), it is possible that the resource (or possibly just the "home" resource of the service context) communicates its sunset policy by using the sunset link relation type. If communicated as an HTTP header field, it might look as follows:
Sunsetヘッダーフィールドが初めて表示される前でも（最初から表示されない場合があります）、リソース（またはサービスコンテキストの「ホーム」リソースのみ）が、sunsetを使用して日没ポリシーを伝達する可能性がありますリンク関係タイプ。 HTTPヘッダーフィールドとして通信する場合、次のようになります。
Link: <http://example.net/sunset>;rel="sunset";type="text/html"
In this case, the linked resource provides sunset policy information about the service context. It may be documentation aimed at developers, for example, informing them that the lifetime of a certain class of resources is ten years after creation and that Sunset header fields will be served as soon as the sunset date is less than some given period of time. It may also inform developers whether the service will respond with 410 or 404 after the sunset time, as discussed above.
この場合、リンクされたリソースは、サービスコンテキストに関するサンセットポリシー情報を提供します。これは、開発者向けのドキュメントである場合があります。たとえば、特定のリソースクラスのライフタイムは作成後10年であり、日没のヘッダーフィールドは、日没の日付が特定の期間より短くなるとすぐに提供されることを通知します。上記で説明したように、サービスが日没時間後に410または404で応答するかどうかを開発者に通知することもあります。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <https://www.rfc-editor.org/info/rfc3864>.
[RFC3864] Klyne、G.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、DOI 10.17487 / RFC3864、2004年9月、<https：//www.rfc- editor.org/info/rfc3864>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231 >。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.
[RFC8288]ノッティンガム、M。、「Webリンク」、RFC 8288、DOI 10.17487 / RFC8288、2017年10月、<https://www.rfc-editor.org/info/rfc8288>。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.
[RFC7234] Fielding、R.、Ed。、Nottingham、M.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Caching"、RFC 7234、DOI 10.17487 / RFC7234、June 2014 、<https://www.rfc-editor.org/info/rfc7234>。
Acknowledgements
謝辞
Thanks for comments and suggestions provided by Ben Campbell, Alissa Cooper, Benjamin Kaduk, Mirja Kuhlewind, Adam Roach, Phil Sturgeon, and Asbjorn Ulsberg.
Ben Campbell、Alissa Cooper、Benjamin Kaduk、Mirja Kuhlewind、Adam Roach、Phil Sturgeon、およびAsbjorn Ulsbergからのコメントと提案に感謝します。
Author's Address
著者のアドレス
Erik Wilde
エリック・ワイルド
Email: erik.wilde@dret.net
URI: http://dret.net/netdret/