[要約] RFC 6249は、Metalink/HTTPプロトコルに関する仕様であり、ミラーリングとハッシュ機能を提供します。その目的は、ファイルのダウンロードの信頼性と効率性を向上させることです。
Internet Engineering Task Force (IETF) A. Bryan
Request for Comments: 6249 N. McNab
Category: Standards Track T. Tsujikawa
ISSN: 2070-1721
P. Poeml
MirrorBrain
H. Nordstrom
June 2011
Metalink/HTTP: Mirrors and Hashes
Metalink/HTTP：ミラーとハッシュ
Abstract
概要
This document specifies Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP header fields, a different way to get information that is usually contained in the Metalink XML-based download description format. Metalink/HTTP describes multiple download locations (mirrors), Peer-to-Peer, cryptographic hashes, digital signatures, and other information using existing standards for HTTP header fields. Metalink clients can use this information to make file transfers more robust and reliable. Normative requirements for Metalink/HTTP clients and servers are described here.
このドキュメントは、HTTPヘッダーフィールドのMetalink/HTTP：ミラーと暗号化ハッシュを指定します。これは、Metalink XMLベースのダウンロード説明形式に通常含まれる情報を取得する別の方法です。Metalink/HTTPは、HTTPヘッダーフィールドの既存の標準を使用して、複数のダウンロード場所（ミラー）、ピアツーピア、暗号化ハッシュ、デジタル署名、およびその他の情報を説明しています。Metalinkクライアントは、この情報を使用して、ファイル転送をより堅牢で信頼性を高めることができます。Metalink/HTTPクライアントとサーバーの規範的要件については、ここで説明します。
Status of This Memo
本文書の位置付け
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 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6249.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6249で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Example Metalink Server Response ...........................4
1.2. Notational Conventions .....................................4
1.3. Terminology ................................................5
2. Requirements ....................................................5
3. Mirrors / Multiple Download Locations ...........................7
3.1. Mirror Priority ............................................8
3.2. Mirror Geographical Location ...............................8
3.3. Coordinated Mirror Policies ................................8
3.4. Mirror Depth ...............................................9
4. Peer-to-Peer / Metainfo .........................................9
4.1. Metalink/XML Files ........................................10
5. Signatures .....................................................10
5.1. OpenPGP Signatures ........................................10
5.2. S/MIME Signatures .........................................10
6. Cryptographic Hashes of Whole Documents ........................11
7. Client / Server Multi-Source Download Interaction ..............11
7.1. Error Prevention, Detection, and Correction ...............15
7.1.1. Error Prevention (Early File Mismatch Detection) ...15
7.1.2. Error Correction ...................................16
8. IANA Considerations ............................................16
9. Security Considerations ........................................17
9.1. URIs and IRIs .............................................17
9.2. Spoofing ..................................................17
9.3. Cryptographic Hashes ......................................17
9.4. Signing ...................................................17
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................19
Appendix A. Acknowledgements and Contributors .....................20
Metalink/HTTP is an alternative and complementary representation of Metalink information, which is usually presented as an XML-based document format [RFC5854]. Metalink/HTTP attempts to provide as much functionality as the Metalink/XML format by using existing standards, such as Web Linking [RFC5988], Instance Digests in HTTP [RFC3230], and Entity Tags (also known as ETags) [RFC2616]. Metalink/HTTP is used to list information about a file to be downloaded. This can include lists of multiple URIs (mirrors), Peer-to-Peer information, cryptographic hashes, and digital signatures.
Metalink/HTTPは、Metalink情報の代替および補完的な表現であり、通常はXMLベースのドキュメント形式[RFC5854]として提示されます。Metalink/HTTPは、Webリンク[RFC5988]、HTTP [RFC3230]のインスタンスダイジェスト、エンティティタグ（ETAGSとも呼ばれる）[RFC2616]などの既存の標準を使用して、Metalink/XML形式と同じくらいの機能を提供しようとします。Metalink/HTTPは、ダウンロードするファイルに関する情報をリストするために使用されます。これには、複数のURI（ミラー）、ピアツーピア情報、暗号化ハッシュ、デジタル署名のリストが含まれます。
Identical copies of a file are frequently accessible in multiple locations on the Internet over a variety of protocols (such as FTP, HTTP, and Peer-to-Peer). In some cases, users are shown a list of these multiple download locations (mirrors) and must manually select a single one on the basis of geographical location, priority, or bandwidth. This distributes the load across multiple servers, and should also increase throughput and resilience. At times, however, individual servers can be slow, outdated, or unreachable, but this cannot be determined until the download has been initiated. Users will rarely have sufficient information to choose the most appropriate server and will often choose the first in a list, which might not be optimal for their needs, and will lead to a particular server getting a disproportionate share of load. The use of suboptimal mirrors can lead to the user canceling and restarting the download to try to manually find a better source. During downloads, errors in transmission can corrupt the file. There are no easy ways to repair these files. For large downloads, this can be extremely troublesome. Any of the number of problems that can occur during a download lead to frustration on the part of users.
ファイルの同一のコピーは、さまざまなプロトコル（FTP、HTTP、ピアツーピアなど）でインターネット上の複数の場所で頻繁にアクセス可能です。場合によっては、ユーザーにこれらの複数のダウンロード場所（ミラー）のリストが表示され、地理的位置、優先度、または帯域幅に基づいて1つの場所を手動で選択する必要があります。これにより、複数のサーバーに負荷が分散され、スループットと回復力も向上するはずです。ただし、個々のサーバーは遅く、時代遅れ、または到達不能になる場合がありますが、ダウンロードが開始されるまでこれを決定することはできません。ユーザーは、最も適切なサーバーを選択するのに十分な情報を持っていることはめったになく、多くの場合、リスト内の最初のものを選択しますが、これはニーズに最適ではない可能性があり、特定のサーバーが不均衡な負荷のシェアを取得することになります。最適ではないミラーを使用すると、ユーザーがダウンロードをキャンセルして再起動して、より良いソースを手動で見つけようとする可能性があります。ダウンロード中、送信のエラーはファイルを破損する可能性があります。これらのファイルを修復する簡単な方法はありません。大規模なダウンロードの場合、これは非常に面倒です。ダウンロード中に発生する可能性のある問題の数は、ユーザー側のフラストレーションにつながります。
Some popular sites automate the process of selecting mirrors using DNS load balancing, both to approximately balance load between servers, and to direct clients to nearby servers with the hope that this improves throughput. Indeed, DNS load balancing can balance long-term server load fairly effectively, but it is less effective at delivering the best throughput to users when the bottleneck is not the server but the network.
一部の一般的なサイトでは、DNSロードバランシングを使用してミラーを選択するプロセスを自動化します。両方ともサーバー間の負荷をほぼバランスさせ、これがスループットが改善されることを期待して近くのサーバーにクライアントを誘導します。実際、DNSロードバランシングは、長期サーバーの負荷のバランスをかなり効果的にバランスさせることができますが、ボトルネックがサーバーではなくネットワークである場合、ユーザーに最高のスループットを配信するのに効果が低いです。
This document describes a mechanism by which the benefit of mirrors can be automatically and more effectively realized. All the information about a download, including mirrors, cryptographic hashes, digital signatures, and more can be transferred in coordinated HTTP header fields, hereafter referred to as a "Metalink". This Metalink transfers the knowledge of the download server (and mirror database) to the client. Clients can fall back to other mirrors if the current one has an issue. With this knowledge, the client is enabled to work its way to a successful download even under adverse circumstances. All this can be done without complicated user interaction, and the download can be much more reliable and efficient. In contrast, a traditional HTTP redirect to a mirror conveys only minimal information -- one link to one server -- and there is no provision in the HTTP protocol to handle failures. Furthermore, in order to provide better load distribution across servers and potentially faster downloads to users, Metalink/HTTP facilitates multi-source downloads, where portions of a file are downloaded from multiple mirrors (and, optionally, Peer-to-Peer) simultaneously.
このドキュメントは、ミラーの利点を自動的に効果的に実現できるメカニズムについて説明しています。ミラー、暗号化ハッシュ、デジタル署名など、ダウンロードに関するすべての情報は、「Metalink」と呼ばれる調整されたHTTPヘッダーフィールドで転送できます。このMetalinkは、ダウンロードサーバー（およびミラーデータベース）の知識をクライアントに転送します。現在のミラーに問題がある場合、クライアントは他のミラーに戻ることができます。この知識により、クライアントは、不利な状況下でもダウンロードを成功させるために進むことができます。これはすべて、複雑なユーザーインタラクションなしで行うことができ、ダウンロードははるかに信頼性が高く効率的です。対照的に、従来のHTTPがミラーにリダイレクトすることで、最小限の情報（1つのサーバーへの1つのリンク）のみが伝えられ、HTTPプロトコルに障害を処理する規定はありません。さらに、サーバー全体でより良い負荷分布を提供し、ユーザーへのダウンロードを潜在的に高速化するために、Metalink/HTTPはマルチソースのダウンロードを促進します。ここでは、ファイルの一部が複数のミラー（およびオプションでピアツーピア）から同時にダウンロードされます。
Upon connection to a Metalink/HTTP server, a client will receive information about other sources of the same resource and a cryptographic hash of the whole resource. The client will then be able to request chunks of the file from the various sources, scheduling appropriately in order to maximize the download rate.
Metalink/HTTPサーバーに接続すると、クライアントは同じリソースの他のソースとリソース全体の暗号化ハッシュに関する情報を受け取ります。その後、クライアントはさまざまなソースからファイルのチャンクを要求し、ダウンロードレートを最大化するために適切にスケジュールできます。
This example shows a brief Metalink server response with ETag, mirrors, Peer-to-Peer information, Metalink/XML, OpenPGP signature, and a cryptographic hash of the whole file:
この例は、ETAG、ミラー、ピアツーピア情報、Metalink/XML、OpenPGP署名、およびファイル全体の暗号化ハッシュを備えた簡単なMetalink Server応答を示しています。
Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
Link: <http://www2.example.com/example.ext>; rel=duplicate
Link: <ftp://ftp.example.com/example.ext>; rel=duplicate
Link: <http://example.com/example.ext.torrent>; rel=describedby;
type="application/x-bittorrent"
Link: <http://example.com/example.ext.meta4>; rel=describedby;
type="application/metalink4+xml"
Link: <http://example.com/example.ext.asc>; rel=describedby;
type="application/pgp-signature"
Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlO
DYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==
This specification describes conformance of Metalink/HTTP.
この仕様では、Metalink/HTTPの適合性について説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119], as scoped to those conformance targets.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、[RFC2119]に記載されているように解釈されると、それらの適合目標にスコープされます。
The following terms, as used in this document, are defined here:
このドキュメントで使用されている次の用語は、ここで定義されています。
o Metalink server: HTTP server that provides a Metalink in HTTP response header fields.
o Metalink Server：HTTP応答ヘッダーフィールドでMetalinkを提供するHTTPサーバー。
o Metalink : A collection of HTTP response header fields from a Metalink server, which is the reply to a GET or HEAD request from a client and which includes Link header fields listing mirrors and Instance Digests listing a cryptographic hash.
o Metalink：Metalink ServerからのHTTP応答ヘッダーフィールドのコレクション。これは、クライアントからのGETまたはヘッドリクエストへの返信であり、リンクヘッダーフィールドをリストするリンクヘッダーフィールドと暗号化ハッシュをリストするインスタンスダイジェストを含む。
o Link header field: HTTP response header field, defined in [RFC5988], that can list mirrors and, potentially, other download methods for obtaining a file, along with digital signatures.
o リンクヘッダーフィールド：[RFC5988]で定義されているHTTP応答ヘッダーフィールドは、ミラー、および潜在的に、ファイルを取得するための他のダウンロード方法をデジタル署名とともにリストできます。
o Instance Digest: HTTP response header field, defined in [RFC3230], that contains the cryptographic hash of a file, which is used by the Metalink client to verify the integrity of the file once the download has completed.
o インスタンスダイジェスト：[RFC3230]で定義されているHTTP応答ヘッダーフィールドには、ダウンロードが完了したらファイルの整合性を確認するためにMetalinkクライアントが使用するファイルの暗号化ハッシュが含まれています。
o Entity Tag or ETag: HTTP response header field, defined in [RFC2616], that, if synchronized between the Metalink server and mirror servers, allows Metalink clients to provide advanced features.
o エンティティタグまたはETAG：[RFC2616]で定義されているHTTP応答ヘッダーフィールドは、Metalinkサーバーとミラーサーバー間で同期した場合、Metalinkクライアントが高度な機能を提供できるようにします。
o Mirror server: Typically, FTP or HTTP servers that "mirror" the Metalink server, i.e., provide identical copies of (at least some) files that are also on the mirrored server.
o ミラーサーバー：通常、Metalinkサーバーを「ミラーリング」するFTPまたはHTTPサーバー、つまり、ミラー化されたサーバー上にある（少なくとも一部）ファイルの同一のコピーを提供します。
o Metalink clients: Applications that process Metalinks and use them to provide an improved download experience. They support HTTP and could also support other download protocols like FTP or various Peer-to-Peer methods.
o Metalinkクライアント：Metalinksを処理し、それらを使用してダウンロードエクスペリエンスを向上させるアプリケーション。HTTPをサポートし、FTPやさまざまなピアツーピアメソッドなどの他のダウンロードプロトコルをサポートできます。
o Metalink/XML: An XML file that can contain similar information to an HTTP response header Metalink, such as mirrors and cryptographic hashes.
o Metalink/XML：ミラーや暗号化などのHTTP応答ヘッダーMetalinkに同様の情報を含めることができるXMLファイル。
In this context, "Metalink" refers to Metalink/HTTP, which consists of mirrors and cryptographic hashes in HTTP header fields as described in this document. "Metalink/XML" refers to the XML format described in [RFC5854].
これに関連して、「Metalink」とは、このドキュメントで説明されているように、HTTPヘッダーフィールドのミラーと暗号化のハッシュで構成されるMetalink/HTTPを指します。「Metalink/XML」とは、[RFC5854]で説明されているXML形式を指します。
Metalink resources include Link header fields [RFC5988] to present a list of mirrors in the response to a client request for the resource. Metalink servers MUST include the cryptographic hash of a resource via Instance Digests in HTTP [RFC3230]. Algorithms used in the Instance Digest field are registered in the IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" at <http://www.iana.org/>. This document restricts the use of these algorithms. SHA-256 and SHA-512 were added to the registry by [RFC5843]. Metalinks contain whole file hashes as described in Section 6, and MUST include SHA-256, as specified in [FIPS-180-3]. It MAY also include other hashes.
Metalinkリソースには、リンクヘッダーフィールド[RFC5988]が含まれており、リソースのクライアントリクエストへの応答にミラーのリストを提示します。Metalinkサーバーには、HTTP [RFC3230]のインスタンスダイジェストを介してリソースの暗号化ハッシュを含める必要があります。インスタンスダイジェストフィールドで使用されるアルゴリズムは、<http://www.iana.org/>で「HyperText Transfer Protocol（HTTP）Digestアルゴリズム値」という名前のIANAレジストリに登録されています。このドキュメントは、これらのアルゴリズムの使用を制限しています。SHA-256およびSHA-512は、[RFC5843]によってレジストリに添加されました。Metalinksには、セクション6で説明されているようにファイル全体のハッシュが含まれており、[FIPS-180-3]で指定されているように、SHA-256を含める必要があります。他のハッシュも含まれる場合があります。
Metalink servers are HTTP servers with one or more Metalink resources. Metalink servers MUST support the Link header fields for listing mirrors and MUST support Instance Digests in HTTP [RFC3230]. Metalink servers MUST return the same Link header fields and Instance Digests on HEAD requests. Metalink servers and their associated preferred mirror servers MUST all share the same ETag policy. Metalink servers and their associated normal mirror servers SHOULD all share the same ETag policy. (See Section 3.3 for the definition of "preferred" and "normal" mirror servers.) It is up to the administrator of the Metalink server to communicate the details of the shared ETag policy to the administrators of the mirror servers so that the mirror servers can be configured with the same ETag policy. To have the same ETag policy means that ETags are synchronized across servers for resources that are mirrored; i.e., byte-for-byte identical files will have the same ETag on mirrors that they have on the Metalink server. For example, it would be better to derive an ETag from a cryptographic hash of the file contents than on server-unique filesystem metadata. Metalink servers SHOULD offer Metalink/ XML documents that contain cryptographic hashes of parts of the file (and other information) if error recovery is desirable.
Metalinkサーバーは、1つ以上のMetalinkリソースを備えたHTTPサーバーです。Metalink Serversは、リンクヘッダーフィールドをサポートしてミラーをリストし、HTTP [RFC3230]のインスタンスダイジェストをサポートする必要があります。Metalinkサーバーは、同じリンクヘッダーフィールドを返し、ヘッドリクエストでインスタンスダイジェストを返す必要があります。Metalink Serversとそれに関連する優先ミラーサーバーは、すべて同じETAGポリシーを共有する必要があります。Metalinkサーバーとそれに関連する通常のミラーサーバーはすべて、同じETAGポリシーを共有する必要があります。（「優先」および「通常の」ミラーサーバーの定義については、セクション3.3を参照してください。）Metalink Serverの管理者次第で、共有ETAGポリシーの詳細をミラーサーバーの管理者に通信して、ミラーサーバーがミラーサーバーになるようにします。同じETAGポリシーで構成できます。同じETAGポリシーを持つことは、ETAGがミラーリングされたリソースのサーバー間で同期されることを意味します。つまり、Byte-for-byteの同一ファイルには、Metalinkサーバー上にあるミラーと同じETAGがあります。たとえば、Server-Uniqueファイルシステムメタデータよりも、ファイルコンテンツの暗号化ハッシュからETAGを導き出す方が良いでしょう。Metalinkサーバーは、エラー回復が望ましい場合は、ファイルの一部（およびその他の情報）の暗号化ハッシュを含むMetalink/ XMLドキュメントを提供する必要があります。
Mirror servers are typically FTP or HTTP servers that "mirror" another server. That is, they provide identical copies of (at least some) files that are also on the mirrored server. Mirror servers SHOULD support serving partial content. HTTP mirror servers SHOULD share the same ETag policy as the originating Metalink server. HTTP mirror servers SHOULD support Instance Digests in HTTP [RFC3230] using the same algorithm as the Metalink server. Optimally, HTTP mirror servers will share the same ETag policy and support Instance Digests in HTTP. Mirror servers that share the same ETag policy and/or support Instance Digests in HTTP using the same algorithm as a Metalink server are known as preferred mirror servers.
ミラーサーバーは通常、別のサーバーを「ミラーリング」するFTPまたはHTTPサーバーです。つまり、ミラー化されたサーバー上にある（少なくとも一部の）ファイルの同一のコピーを提供します。ミラーサーバーは、部分コンテンツの提供をサポートする必要があります。HTTPミラーサーバーは、発信元のMetalinkサーバーと同じETAGポリシーを共有する必要があります。HTTPミラーサーバーは、Metalinkサーバーと同じアルゴリズムを使用して、HTTP [RFC3230]のインスタンスダイジェストをサポートする必要があります。最適に、HTTPミラーサーバーは、同じETAGポリシーとサポートインスタンスのDigestsをHTTPで共有します。Metalink Serverと同じアルゴリズムを使用して、HTTPで同じETAGポリシーおよび/またはサポートインスタンスの消化を共有するミラーサーバーは、優先ミラーサーバーとして知られています。
Metalink clients use the mirrors provided by a Metalink server in Link header fields [RFC5988] but these clients are restricted to using the mirrors provided by the initial Metalink server they contacted. If Metalink clients find Link header fields [RFC5988] from mirrors that in turn list mirrors, or from a Metalink server listing itself as a mirror, they MUST discard such Link header fields [RFC5988] to prevent a possible infinite loop. Metalink clients MUST support HTTP and SHOULD support FTP [RFC0959]. Metalink clients MAY support BitTorrent [BITTORRENT] or other download methods. Metalink clients SHOULD switch downloads from one mirror to another if a mirror becomes unreachable. Metalink clients MAY support multi-source, or parallel, downloads, where portions of a file can be downloaded from multiple mirrors simultaneously (and, optionally, from Peer-to-Peer sources). Metalink clients MUST support Instance Digests in HTTP [RFC3230] by requesting and verifying cryptographic hashes. Metalink clients SHOULD support error recovery by using the cryptographic hashes of parts of the file listed in Metalink/XML files. Metalink clients SHOULD support checking digital signatures.
Metalinkクライアントは、Link Headerフィールド[RFC5988]のMetalink Serverが提供するミラーを使用しますが、これらのクライアントは、連絡した最初のMetalinkサーバーによって提供されるミラーを使用することに制限されています。Metalinkクライアントは、ミラーをリストするミラーから、またはMetalink ServerからミラーとしてリストしているMetalink Serverからリンクヘッダーフィールド[RFC5988]を見つけた場合、そのようなリンクヘッダーフィールド[RFC5988]を破棄して、無限ループを防ぐ必要があります。MetalinkクライアントはHTTPをサポートする必要があり、FTP [RFC0959]をサポートする必要があります。Metalinkクライアントは、BitTorrent [Bittorrent]またはその他のダウンロード方法をサポートする場合があります。Metalinkクライアントは、ミラーが到達不可能になった場合、あるミラーから別のミラーにダウンロードを切り替える必要があります。Metalinkクライアントは、マルチソース、または並列のダウンロードをサポートする場合があります。ここでは、ファイルの一部を複数のミラーから同時にダウンロードできます（オプションでは、ピアツーピアソースから）。Metalinkクライアントは、暗号化のハッシュを要求および検証することにより、HTTP [RFC3230]のインスタンスダイジェストをサポートする必要があります。Metalinkクライアントは、Metalink/XMLファイルにリストされているファイルの部分の暗号化ハッシュを使用して、エラー回復をサポートする必要があります。Metalinkクライアントは、デジタル署名のチェックをサポートする必要があります。
Mirrors are specified with the Link header fields [RFC5988] and a relation type of "duplicate" as defined in Section 8.
ミラーは、リンクヘッダーフィールド[RFC5988]と、セクション8で定義されている「複製」の関係タイプで指定されています。
The following list contains OPTIONAL attributes, which are defined elsewhere in this document:
次のリストには、このドキュメントの他の場所で定義されているオプションの属性が含まれています。
o "depth" : mirror depth (see Section 3.4).
o 「深さ」：ミラー深度（セクション3.4を参照）。
o "geo" : mirror geographical location (see Section 3.2).
o 「ジオ」：ミラー地理的位置（セクション3.2を参照）。
o "pref" : a preferred mirror server (see Section 3.3).
o 「Pref」：優先ミラーサーバー（セクション3.3を参照）。
o "pri" : mirror priority (see Section 3.1).
o 「PRI」：ミラー優先度（セクション3.1を参照）。
This example shows a brief Metalink server response with two mirrors only:
この例は、2つのミラーのみを備えた短いMetalink Server応答を示しています。
Link: <http://www2.example.com/example.ext>; rel=duplicate;
pri=1; pref
Link: <ftp://ftp.example.com/example.ext>; rel=duplicate;
pri=2; geo=gb; depth=1
As some organizations can have many mirrors, it is up to the organization to configure the amount of Link header fields the Metalink server will provide. Such a decision could be a random selection or a hard-coded limit based on network proximity, file size, server load, or other factors.
一部の組織には多くのミラーがある可能性があるため、Metalink Serverが提供するリンクヘッダーフィールドの量を構成するのは組織次第です。このような決定は、ネットワークの近接、ファイルサイズ、サーバーの負荷、またはその他の要因に基づいて、ランダム選択またはハードコーディング制限である可能性があります。
Entries for mirror servers MAY have a "pri" value to designate the priority of a mirror. Valid ranges for the "pri" attribute are from 1 to 999999. Mirror servers with a lower value of the "pri" attribute have a higher priority, while mirrors with an undefined "pri" attribute are considered to have a value of 999999, which is the lowest priority. For example, a mirror with "pri=10" has higher priority than a mirror with "pri=20". Metalink clients SHOULD use mirrors with lower "pri" values first, but depending on other conditions, they MAY decide to use other mirrors.
ミラーサーバーのエントリには、ミラーの優先度を指定する「PRI」値がある場合があります。「PRI」属性の有効な範囲は1から999999です。「PRI」属性の値が低いミラーサーバーは優先度が高く、未定義の「PRI」属性を持つミラーは999999の値を持つと見なされます。最優先事項です。たとえば、「pri = 10」のミラーは、「pri = 20」のミラーよりも優先度が高くなります。Metalinkクライアントは、最初に「PRI」値が低いミラーを使用する必要がありますが、他の条件によっては、他のミラーを使用することを決定する場合があります。
This is purely an expression of the server's preferences; it is up to the client what it does with this information, particularly with reference to how many servers to use at any one time.
これは純粋にサーバーの設定の表現です。特に一度に使用するサーバーの数に関して、この情報で何をするかはクライアント次第です。
Entries for a mirror server MAY have a "geo" value, which is an [ISO3166-1] alpha-2 two-letter country code for the geographical location of the physical server the URI is used to access. A client MAY use this information to select a mirror, or set of mirrors, that is geographically near (if the client has access to such information), with the aim of reducing network load at inter-country bottlenecks.
ミラーサーバーのエントリには、「ジオ」値がある場合があります。これは、URIがアクセスするために使用される物理サーバーの地理的位置の[ISO3166-1]アルファ-2の2文字の国コードです。クライアントは、この情報を使用して、地理的に近く（クライアントがそのような情報にアクセスできる場合）ミラーまたはミラーのセットを選択することができます。
There are two types of mirror servers: preferred and normal. Entries for preferred HTTP mirror servers have a "pref" value and entries for normal mirrors don't. Preferred mirror servers are HTTP mirror servers that MUST share the same ETag policy as the originating Metalink server, or if the ETag is not used MUST provide an Instance Digest using the same algorithm as the Metalink server. Preferred mirrors make it possible for Metalink clients to detect early on, before data is transferred, if the file requested matches the desired file. This early file mismatch detection is described in Section 7.1.1. Normal mirrors do not necessarily share the same ETag policy or support Instance Digests using the same algorithm as the Metalink server. FTP mirrors are considered "normal", as they do not emit ETags or support Instance Digests.
ミラーサーバーには2種類のタイプがあります。優先されたHTTPミラーサーバーのエントリには、通常のミラーの「プリフ」値とエントリがありません。優先ミラーサーバーは、発信元のMetalinkサーバーと同じETAGポリシーを共有する必要があるHTTPミラーサーバーです。または、ETAGが使用されていない場合は、Metalinkサーバーと同じアルゴリズムを使用してインスタンスダイジェストを提供する必要があります。優先ミラーにより、Metalinkクライアントがデータが転送される前に、ファイルが要求された場合、目的のファイルと一致する場合、早期に検出できるようになります。この初期のファイルの不一致の検出は、セクション7.1.1で説明されています。通常のミラーは、Metalink Serverと同じアルゴリズムを使用して、必ずしも同じETAGポリシーまたはサポートインスタンスダイジェストを共有するわけではありません。FTPミラーは、ETAGSを放出したり、インスタンスダイジェストをサポートしたりしないため、「正常」と見なされます。
Some mirrors can mirror single files, whole directories, or multiple directories.
一部のミラーは、単一のファイル、ディレクトリ全体、または複数のディレクトリをミラーリングできます。
Entries for mirror servers can have a "depth" value, where "depth=0" is the default. A value of 0 means that only that file is mirrored and that other URI path segments are not. A value of 1 means that the file and all other files and URI path segments contained in the rightmost URI path segment are mirrored. For values of N, N-1 URI path segments closer to the Host are mirrored. A value of 2 means one URI path segment closer to the Host is mirrored, and all files and URI path segments contained are mirrored. For each higher value, another URI path segment closer to the Host is mirrored.
ミラーサーバーのエントリは「深さ」値を持つことができ、「深さ= 0」がデフォルトです。0の値は、そのファイルのみがミラーリングされ、他のURIパスセグメントがないことを意味します。1の値は、右端のURIパスセグメントに含まれるファイルと他のすべてのファイルおよびURIパスセグメントがミラーリングされることを意味します。Nの値の場合、ホストに近いN-1 URIパスセグメントがミラーリングされます。2の値は、ホストに近い1つのURIパスセグメントがミラーリングされ、含まれるすべてのファイルとURIパスセグメントがミラーリングされることを意味します。より高い値ごとに、ホストに近い別のURIパスセグメントがミラーリングされます。
This example shows a mirror with a depth value of 4:
この例は、深さの値が4の鏡を示しています。
Link: <http://www2.example.com/dir1/dir2/dir3/dir4/dir5/example.ext>;
rel=duplicate; pri=1; pref; depth=4
In the above example, four URI path segments closer to the Host are mirrored, from /dir2/ and all files and directories included.
上記の例では、ホストに近い4つのURIパスセグメントが / dir2 /およびすべてのファイルとディレクトリが含まれるすべてのファイルからミラーリングされています。
Entries for metainfo files, which describe ways to download a file over Peer-to-Peer networks or otherwise, are specified with the Link header fields [RFC5988] and a relation type of "describedby" and a type parameter that indicates the MIME type of the metadata available at the URI. Since metainfo files can sometimes describe multiple files, or the filename MAY not be the same on the Metalink server and in the metainfo file but MAY still have the same content, an OPTIONAL "name" attribute can be used.
ピアツーピアネットワークまたはその他のファイルをダウンロードする方法を説明するMetainFOファイルのエントリは、リンクヘッダーフィールド[RFC5988]と「記述」の関係タイプと、MIMEタイプのタイプを示すタイプパラメーターで指定されています。URIで利用可能なメタデータ。MetainFOファイルは複数のファイルを記述できる場合がある場合や、Metalink ServerおよびMetainFOファイルでファイル名が同じではない場合がありますが、それでも同じコンテンツを持っている可能性があるため、オプションの「名前」属性を使用できます。
The following list contains an OPTIONAL attribute, which is defined in this document:
次のリストには、このドキュメントで定義されているオプションの属性が含まれています。
o "name" : a file described within the metainfo file.
o 「名前」：metainfoファイル内で説明されているファイル。
This example shows a brief Metalink server response with .torrent and .meta4:
この例は、.torrentと.meta4を使用した短いMetalink Server応答を示しています。
Link: <http://example.com/example.ext.torrent>; rel=describedby; type="application/x-bittorrent"; name="differentname.ext" Link: <http://example.com/example.ext.meta4>; rel=describedby; type="application/metalink4+xml" Metalink clients MAY support the use of metainfo files for downloading files.
リンク：<http://example.com/example.ext.torrent>;rel = courtionby;type = "application/x-bittorrent";name = "differentname.ext"リンク：<http://example.com/example.ext.meta4>;rel = courtionby;type = "Application/Metalink4 XML" Metalinkクライアントは、ファイルをダウンロードするためのMetainFOファイルの使用をサポートする場合があります。
Metalink/XML files for a given resource MAY be provided in a Link header field as shown in the example in Section 4. Metalink/XML files are specified in [RFC5854], and they are particularly useful for providing metadata such as cryptographic hashes of parts of a file, allowing a client to recover from errors (see Section 7.1.2). Metalink servers SHOULD provide Metalink/XML files with partial file hashes in Link header fields, and Metalink clients SHOULD use them for error recovery.
セクション4の例に示すように、特定のリソースのMetalink/XMLファイルは、リンクヘッダーフィールドで提供される場合があります。Metalink/XMLファイルは[RFC5854]で指定されており、部分の暗号化ハッシュなどのメタデータを提供するのに特に役立ちます。ファイルの場合、クライアントがエラーから回復できるようにします（セクション7.1.2を参照）。Metalinkサーバーは、リンクヘッダーフィールドに部分的なファイルハッシュを備えたMetalink/XMLファイルを提供する必要があり、Metalinkクライアントはエラー回復のためにそれらを使用する必要があります。
OpenPGP signatures [RFC3156] of requested files are specified with the Link header fields [RFC5988] and a relation type of "describedby" and a type parameter of "application/pgp-signature".
リクエストされたファイルのOpenPGP署名[RFC3156]は、リンクヘッダーフィールド[RFC5988]と「記述」の関係タイプと「アプリケーション/PGPシグネチャ」のタイプパラメーターで指定されています。
This example shows a brief Metalink server response with OpenPGP signature only:
この例は、OpenPGP署名のみを使用した短いMetalink Server応答を示しています。
Link: <http://example.com/example.ext.asc>; rel=describedby;
type="application/pgp-signature"
Metalink clients SHOULD support the use of OpenPGP signatures.
Metalinkクライアントは、OpenPGP署名の使用をサポートする必要があります。
Secure/Multipurpose Internet Mail Extensions (S/MIME) signatures [RFC5751] of requested files are specified with the Link header fields [RFC5988] and a relation type of "describedby" and a type parameter of "application/pkcs7-mime".
リクエストされたファイルの安全/多目的インターネットメール拡張（S/MIME）署名[RFC5751]は、リンクヘッダーフィールド[RFC5988]と「記述」の関係タイプと「Application/PKCS7-MIME」のタイプパラメーターで指定されています。
This example shows a brief Metalink server response with S/MIME signature only:
この例は、S/MIME署名のみを備えた短いMetalink Server応答を示しています。
Link: <http://example.com/example.ext.p7m>; rel=describedby;
type="application/pkcs7-mime"
Metalink clients SHOULD support the use of S/MIME signatures.
Metalinkクライアントは、S/MIME署名の使用をサポートする必要があります。
If Instance Digests are not provided by the Metalink servers, the Link header fields pertaining to this specification MUST be ignored.
インスタンスダイジェストがMetalinkサーバーによって提供されていない場合、この仕様に関連するリンクヘッダーフィールドは無視する必要があります。
This example shows a brief Metalink server response with ETag, mirror, and cryptographic hash:
この例は、ETAG、ミラー、暗号化のハッシュによる短いMetalinkサーバーの応答を示しています。
Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
Link: <http://www2.example.com/example.ext>; rel=duplicate
Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlO
DYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==
Metalink clients begin a download with a standard HTTP [RFC2616] GET request to the Metalink server. Metalink clients MAY use a range limit if desired.
Metalinkクライアントは、標準のHTTP [RFC2616]を使用してダウンロードを開始します。Metalinkクライアントは、必要に応じて範囲制限を使用できます。
GET /distribution/example.ext HTTP/1.1 Host: www.example.com
get /distribution/example.ext http/1.1ホスト：www.example.com
The Metalink server responds with the data and these header fields:
Metalinkサーバーは、データとこれらのヘッダーフィールドで応答します。
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 14867603
Content-Type: application/x-cd-image
Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
Link: <http://www2.example.com/example.ext>; rel=duplicate; pref
Link: <ftp://ftp.example.com/example.ext>; rel=duplicate
Link: <http://example.com/example.ext.torrent>; rel=describedby;
type="application/x-bittorrent"
Link: <http://example.com/example.ext.meta4>; rel=describedby;
type="application/metalink4+xml"
Link: <http://example.com/example.ext.asc>; rel=describedby;
type="application/pgp-signature"
Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlO
DYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==
Alternatively, Metalink clients can begin with a HEAD request to the Metalink server to discover mirrors via Link header fields and then skip to making the following decisions on every available mirror server found via the Link header fields.
または、Metalinkクライアントは、Metalink Serverへのヘッドリクエストから始めて、リンクヘッダーフィールドを介してミラーを発見し、リンクヘッダーフィールドを介して見つかったすべてのミラーサーバーで次の決定を行うことができます。
After that, the client follows with a GET request to the desired mirrors.
その後、クライアントは目的のミラーへのGETリクエストをフォローします。
From the Metalink server response, the client learns some or all of the following metadata about the requested object, in addition to starting to receive the object:
Metalink Serverの応答から、クライアントは、オブジェクトの受信を開始することに加えて、要求されたオブジェクトについて次のメタデータの一部またはすべてを学習します。
o Mirror locations, with optional attributes describing the mirror's priority, whether it shares the ETag policy of the originating Metalink server, geographical location, and mirror depth.
o ミラーの場所は、ミラーの優先事項を説明するオプションの属性を備えた、発生するMetalinkサーバー、地理的位置、ミラーの深さのETAGポリシーを共有するかどうかにかかわらず。
o Instance Digest, which is the whole file cryptographic hash.
o インスタンスダイジェスト。これはファイル暗号ハッシュ全体です。
o ETag.
o etag。
o Object size from the Content-Length header field.
o コンテンツ長ヘッダーフィールドからのオブジェクトサイズ。
o Metalink/XML, which can include partial file cryptographic hashes to repair a file.
o Metalink/XML。これには、ファイルを修復するための部分的なファイル暗号化ハッシュを含めることができます。
o Peer-to-Peer information.
o ピアツーピア情報。
o Digital signature.
o デジタル署名。
Next, the Metalink client requests a range of the object from a preferred mirror server, so it can use If-Match conditions:
次に、Metalinkクライアントは、優先ミラーサーバーからオブジェクトの範囲を要求するため、IFマッチ条件を使用できます。
GET /example.ext HTTP/1.1
Host: www2.example.com
Range: bytes=7433802-
If-Match: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
Referer: http://www.example.com/distribution/example.ext
Metalink clients SHOULD use preferred mirrors, if possible, as they allow early file mismatch detection as described in Section 7.1.1. Preferred mirrors have coordinated ETags, as described in Section 3.3, and Metalink clients SHOULD use If-Match conditions based on the ETag to quickly detect out-of-date mirrors by using the ETag from the Metalink server response. Metalink clients SHOULD use partial file cryptographic hashes as described in Section 7.1.2, if available, to detect if the mirror server returned the correct data.
Metalinkクライアントは、セクション7.1.1で説明されているように、可能であれば、可能であれば、可能であれば、可能であれば、優先ミラーを使用する必要があります。セクション3.3で説明されているように、優先ミラーにはETAGが調整されており、MetalinkクライアントはETAGに基づいてIFマッチ条件を使用して、Metalink Server ResponseのETAGを使用して時代遅れのミラーを迅速に検出する必要があります。Metalinkクライアントは、ミラーサーバーが正しいデータを返したかどうかを検出するために、セクション7.1.2で説明されているように、部分的なファイル暗号化ハッシュを使用する必要があります。
Optimally, the mirror server also will include an Instance Digest in the mirror response to the client GET request, which the client can also use to detect a mismatch early. Metalink clients MUST reject individual downloads from mirrors that support Instance Digests if the Instance Digest from the mirror does not match the Instance Digest as reported by the Metalink server and the same algorithm is used. If normal mirrors are used, then a mismatch cannot be detected until the completed object is verified. Errors in transmission and substitutions of incorrect data on mirrors, whether deliberate or accidental, can be detected with error correction as described in Section 7.1.2.
最適には、ミラーサーバーには、クライアントゲットリクエストに対するミラー応答のインスタンスダイジェストも含まれます。クライアントは、クライアントが早期にミスマッチを検出するために使用できます。Metalinkクライアントは、ミラーからのインスタンスダイジェストがMetalink Serverによって報告されたインスタンスダイジェストと一致しない場合、インスタンスのダイジェストをサポートするミラーからの個々のダウンロードを拒否する必要があり、同じアルゴリズムが使用されます。通常のミラーを使用すると、完成したオブジェクトが検証されるまで不一致を検出できません。セクション7.1.2で説明されているように、故意であろうと偶発的であろうと、故意であろうと偶発的であろうと、ミラー上の誤ったデータの伝送と置換のエラーを検出できます。
Here, the preferred mirror server has the correct file (the If-Match conditions match) and responds with a 206 Partial Content HTTP status code and appropriate "Content-Length", "Content-Range", ETag, and Instance Digest header fields. In this example, the mirror server responds, with data, to the above request:
ここで、優先ミラーサーバーには正しいファイル（IFマッチ条件が一致）があり、206の部分コンテンツHTTPステータスコードと適切な「コンテンツレングス」、「コンテンツレンジ」、ETAG、およびインスタンスダイジェストヘッダーフィールドで応答します。この例では、ミラーサーバーは、上記のリクエストにデータを使用して応答します。
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Length: 7433801
Content-Range: bytes 7433802-14867602/14867603
Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlO
DYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==
Metalink clients MAY start a number of parallel range requests (one per selected mirror server other than the first) using mirrors provided by the Link header fields with "duplicate" relation type. Metalink clients MUST limit the number of parallel connections to mirror servers, ideally based on observing how the aggregate throughput changes as connections are opened. It would be pointless to blindly open connections once the path bottleneck is filled. After establishing a new connection, a Metalink client SHOULD monitor whether the aggregate throughput increases over all connections that are part of the download. The client SHOULD NOT open additional connections during this period. If the aggregate throughput has increased, the client MAY open an additional connection and repeat these steps. Otherwise, the client SHOULD NOT open a new connection until an established one closes. Metalink clients SHOULD use the location of the original GET request in the "Referer" header field for these range requests.
Metalinkクライアントは、リンクヘッダーフィールドによって「複製」関係タイプを持つミラーを使用して、多数の並列範囲要求（最初のもの以外の選択されたミラーサーバーごとに1つ）を開始できます。Metalinkクライアントは、ミラーサーバーへの並列接続の数を制限する必要があります。理想的には、接続が開かれたときに集約されたスループットの変化がどのように変化するかを観察することに基づいています。パスボトルネックが満たされた後、盲目的に接続を開くことは無意味です。新しい接続を確立した後、Metalinkクライアントは、ダウンロードの一部であるすべての接続で集計スループットが増加するかどうかを監視する必要があります。クライアントは、この期間中に追加の接続を開くべきではありません。集計スループットが増加した場合、クライアントは追加の接続を開き、これらの手順を繰り返すことがあります。それ以外の場合、クライアントは、確立された接続が閉じるまで新しい接続を開くべきではありません。Metalinkクライアントは、これらの範囲リクエストに対して「参照」ヘッダーフィールドの元のGETリクエストの場所を使用する必要があります。
The Metalink client can determine the size and number of ranges requested from each server, based upon the type and number of mirrors and performance observed from each mirror. Note that range requests impose an overhead on servers, and clients need to be aware of that and not abuse them. When downloading a particular file, Metalink clients MUST NOT make more than one concurrent request to each mirror server from which it downloads.
Metalinkクライアントは、各ミラーから観察されるミラーとパフォーマンスの種類と数に基づいて、各サーバーから要求された範囲のサイズと数を決定できます。範囲要求はサーバーにオーバーヘッドを課すことに注意してください。クライアントはそれを認識し、それらを悪用しない必要があります。特定のファイルをダウンロードする場合、Metalinkクライアントは、ダウンロードする各ミラーサーバーに複数の同時リクエストを実行してはなりません。
Metalink clients SHOULD close all but the fastest connection if any range requests generated after the first request end up with a complete response, instead of a partial response (as some mirrors might not support HTTP ranges), if the goal is the fastest transfer. Metalink clients MAY monitor mirror conditions and dynamically switch between mirrors to achieve the fastest download possible. Similarly, Metalink clients SHOULD abort extremely slow or stalled range requests and finish the request on other mirrors. If all ranges have finished except for the final one, the Metalink client can split the final range into multiple range requests to other mirrors so the transfer finishes faster.
Metalinkクライアントは、目標が最速の転送である場合、部分的な応答の代わりに（一部のミラーがHTTP範囲をサポートしない可能性があるため）、最初のリクエストの後に生成された範囲の要求が完全な応答で終了する場合、最速の接続を除くすべてを閉じる必要があります。Metalinkクライアントは、ミラー条件を監視し、ミラー間を動的に切り替えて、可能な限り最速のダウンロードを実現できます。同様に、Metalinkクライアントは非常に遅いまたは失速した範囲要求を中止し、他のミラーでリクエストを終了する必要があります。最終範囲を除いてすべての範囲が終了した場合、Metalinkクライアントは最終範囲を複数の範囲リクエストに他のミラーに分割できるため、転送がより速く終了します。
If the first request was a GET, no Range header field was sent, and the client determines later that it will issue a range request, then the client SHOULD close the first connection when it catches up with the other parallel range requests of the same object. This means the first connection was sacrificed. Metalink clients can use a HEAD request first, if possible, so that the client can find out if there are any Link header fields, and then range-based requests are undertaken to the mirror servers without sacrificing a first connection.
最初の要求がGETである場合、範囲ヘッダーフィールドが送信されなかった場合、クライアントは後で範囲要求を発行すると判断します。。これは、最初の接続が犠牲になったことを意味します。Metalinkクライアントは、可能であれば、最初にヘッドリクエストを使用できます。そのため、クライアントはリンクヘッダーフィールドがあるかどうかを確認でき、最初の接続を犠牲にすることなく範囲ベースのリクエストがミラーサーバーに行われます。
Metalink clients MUST reject individual downloads from mirrors where the file size does not match the file size as reported by the Metalink server.
Metalinkクライアントは、Metalink Serverによって報告されているように、ファイルサイズがファイルサイズと一致しないミラーからの個々のダウンロードを拒否する必要があります。
If a Metalink client does not support certain download methods (such as FTP or BitTorrent) that a file is available from, and there are no available download methods that the client supports, then the download will have no way to complete.
Metalinkクライアントがファイルから利用可能な特定のダウンロード方法（FTPやBitTorrentなど）をサポートしておらず、クライアントがサポートする利用可能なダウンロード方法がない場合、ダウンロードは完了する方法がありません。
Metalink clients MUST verify the cryptographic hash of the file once the download has completed. If the cryptographic hash offered by the Metalink server with Instance Digests does not match the cryptographic hash of the downloaded file, see Section 7.1.2 for a possible way to repair errors.
Metalinkクライアントは、ダウンロードが完了したら、ファイルの暗号化ハッシュを確認する必要があります。Instance Digestsを使用してMetalink Serverが提供する暗号化ハッシュが、ダウンロードされたファイルの暗号化ハッシュと一致しない場合は、エラーを修復する可能性のある方法については、セクション7.1.2を参照してください。
If the download cannot be repaired, it is considered corrupt. The client can attempt to re-download the file.
ダウンロードを修復できない場合、破損していると見なされます。クライアントはファイルの再ダウンロードを試みることができます。
Metalink clients that support verifying digital signatures MUST verify digital signatures of requested files if they are included. Digital signatures MUST validate back to a trust anchor as described in the validation rules in [RFC3156] and [RFC5280].
デジタル署名の検証をサポートするMetalinkクライアントは、要求されたファイルが含まれている場合は、デジタル署名を検証する必要があります。デジタル署名は、[RFC3156]および[RFC5280]の検証ルールで説明されているように、信頼アンカーに戻る必要があります。
Error prevention, or early file mismatch detection, is possible before file transfers with the use of file sizes, ETags, and Instance Digests provided by Metalink servers. Error detection requires Instance Digests to detect errors in transfer after the transfers have completed. Error correction, or download repair, is possible with partial file cryptographic hashes.
エラー予防、または早期のファイルの不一致の検出は、ファイルサイズ、ETAG、およびMetalinkサーバーが提供するインスタンスダイジェストを使用してファイル転送する前に可能です。エラー検出には、転送が完了した後に転送中のエラーを検出するためのインスタンスダイジェストが必要です。エラー修正、またはダウンロード修理は、部分的なファイル暗号化ハッシュで可能です。
Note that cryptographic hashes obtained from Instance Digests are in base64 encoding, while those from Metalink/XML are in hexadecimal.
インスタンスダイジェストから得られた暗号化ハッシュはBase64エンコードであり、Metalink/XMLのものは16進んでいることに注意してください。
In HTTP terms, the merging of ranges from multiple responses SHOULD be verified with a strong validator, which in this context is either an Instance Digest or a shared ETag from that Metalink server that matches with the Instance Digest or ETag provided by a preferred mirror server. In most cases, it is sufficient that the Metalink server provides mirrors and Instance Digest information, but operation will be more robust and efficient if the mirror servers do implement a shared ETag policy or Instance Digests as well. There is no need to specify how the ETag is generated, just that it needs to be shared between the Metalink server and the mirror servers. The benefit of having mirror servers return an Instance Digest is that the client then can detect mismatches early even if ETags are not used. Mirrors that support both a shared ETag and Instance Digests do provide value, but just one is sufficient for early detection of mismatches. If the mirror server provides neither shared ETag nor Instance Digest, then early detection of mismatches is not possible unless file length also differs. Finally, errors are still detectable after the download has completed, when the cryptographic hash of the merged response is verified.
HTTPの用語では、複数の応答からの範囲のマージを強力なバリデーターで検証する必要があります。これは、このコンテキストでは、インスタンスダイジェストまたはそのMetalink Serverからの共有ETAGであるインスタンスダイジェストまたは優先ミラーサーバーが提供するETAGと一致するMetalink Serverの共有ETAGです。。ほとんどの場合、Metalink Serverがミラーとインスタンスのダイジェスト情報を提供するだけで十分ですが、ミラーサーバーが共有ETAGポリシーまたはインスタンスダイジェストを実装する場合、操作はより堅牢で効率的になります。ETAGの生成方法を指定する必要はありません。まさに、Metalinkサーバーとミラーサーバー間で共有する必要があることです。ミラーサーバーがインスタンスダイジェストを返すことの利点は、ETAGが使用されていなくても、クライアントがミスマッチを早期に検出できることです。共有されたETAGとインスタンスの両方のダイジェストの両方をサポートするミラーは価値を提供しますが、1つだけでは不一致の早期検出に十分です。ミラーサーバーが共有ETAGまたはインスタンスダイジェストのいずれも提供しない場合、ファイルの長さも異なっていない限り、不一致の早期検出は不可能です。最後に、マージされた応答の暗号化ハッシュが検証されたとき、ダウンロードが完了した後もエラーが検出されます。
ETags cannot be used for verifying the integrity of the received content. If the ETag given by the mirror server matches the ETag given by the Metalink server, then the Metalink client assumes the responses are valid for that object.
ETAGは、受信したコンテンツの整合性を確認するために使用できません。ミラーサーバーによって与えられたETAGがMetalinkサーバーによって与えられたETAGと一致する場合、Metalinkクライアントは、そのオブジェクトに対して応答が有効であると想定します。
This guarantees that a mismatch will be detected by using only the shared ETag from a Metalink server and mirror server. Metalink clients will detect an error if ETags do not match, which will prevent accidental merges of ranges from different versions of files with the same name.
これにより、Metalink ServerとMirror Serverの共有ETAGのみを使用して不一致が検出されることが保証されます。Metalinkクライアントは、ETAGが一致しない場合、エラーを検出します。これにより、同じ名前のファイルの異なるバージョンの範囲の偶発的な合併が防止されます。
A shared ETag or Instance Digest cannot strictly protect against malicious attacks or server or network errors replacing content. An attacker can make a mirror server seemingly respond with the expected Instance Digest or ETags even if the file contents have been modified. The same goes for various system failures, which would also cause bad data (i.e., corrupted files) to be returned. The Metalink client has to rely on the Instance Digest returned by the Metalink server in the first response for the verification of the downloaded object as a whole. To verify the individual ranges, which might have been requested from different sources, see Section 7.1.2.
共有されたETAGまたはインスタンスダイジェストは、コンテンツを置き換える悪意のある攻撃やサーバーまたはネットワークエラーから厳密に保護することはできません。攻撃者は、ファイルの内容が変更されていても、予想されるインスタンスダイジェストまたはETAGでミラーサーバーを一見応答するようにすることができます。同じことがさまざまなシステム障害にも当てはまります。これにより、悪いデータ（すなわち、破損したファイル）が返されます。Metalinkクライアントは、ダウンロードされたオブジェクト全体を検証するために、最初の応答でMetalink Serverによって返されたインスタンスダイジェストに依存する必要があります。さまざまなソースから要求されている可能性のある個々の範囲を確認するには、セクション7.1.2を参照してください。
Partial file cryptographic hashes can be used to detect errors during the download. Metalink servers SHOULD provide Metalink/XML files with partial file hashes in Link header fields as specified in Section 4.1, and Metalink clients SHOULD use them for error correction.
部分的なファイル暗号化ハッシュを使用して、ダウンロード中にエラーを検出できます。Metalinkサーバーは、セクション4.1で指定されているように、リンクヘッダーフィールドに部分的なファイルハッシュを備えたMetalink/XMLファイルを提供する必要があり、Metalinkクライアントはエラー修正にそれらを使用する必要があります。
An error in transfer or a substitution attack will be detected by a cryptographic hash of the object not matching the Instance Digest from the Metalink server. If the cryptographic hash of the object does not match the Instance Digest from the Metalink server, then the client SHOULD fetch the Metalink/XML (if available). This may contain partial file cryptographic hashes, which will allow detection of which mirror server returned incorrect data. Metalink clients SHOULD use the Metalink/XML data to figure out what ranges of the downloaded data can be recovered and what needs to be fetched again.
転送または置換攻撃のエラーは、Metalinkサーバーからのインスタンスダイジェストと一致しないオブジェクトの暗号化ハッシュによって検出されます。オブジェクトの暗号化ハッシュがMetalinkサーバーからのインスタンスダイジェストと一致しない場合、クライアントはMetalink/XMLを取得する必要があります（利用可能な場合）。これには、部分的なファイル暗号化ハッシュが含まれる場合があります。これにより、ミラーサーバーが誤ったデータを返したものの検出が可能になります。Metalinkクライアントは、Metalink/XMLデータを使用して、ダウンロードされたデータの範囲を回復できるものと再度フェッチする必要があるものを把握する必要があります。
Other methods can be used for error correction. For example, some other metainfo files also include partial file hashes that can be used to check for errors.
他の方法は、エラー修正に使用できます。たとえば、他のMETAINFOファイルには、エラーをチェックするために使用できる部分ファイルハッシュも含まれています。
Accordingly, IANA has made the following registration to the "Link Relation Types" registry at <http://www.iana.org/>.
したがって、IANAは、<http://www.iana.org/>の「リンク関係タイプ」レジストリに次の登録を行いました。
o Relation Name: duplicate
o 関係名：複製
o Description: Refers to a resource whose available representations are byte-for-byte identical with the corresponding representations of the context IRI.
o 説明：利用可能な表現が、コンテキストIRIの対応する表現と同一のバイトバイトであるリソースを指します。
o Reference: This specification.
o 参照：この仕様。
o Notes: This relation is for static resources. That is, an HTTP GET request on any duplicate will return the same representation. It does not make sense for dynamic or POSTable resources and should not be used for them.
o 注：この関係は静的リソース用です。つまり、重複するHTTP GETリクエストは同じ表現を返します。動的なリソースやポスト可能なリソースには意味がなく、それらに使用するべきではありません。
Metalink clients handle URIs and Internationalized Resource Identifiers (IRIs). See Section 7 of [RFC3986] and Section 8 of [RFC3987] for security considerations related to their handling and use.
Metalinkクライアントは、URIと国際化されたリソース識別子（IRIS）を処理します。取り扱いと使用に関連するセキュリティに関する考慮事項については、[RFC3986]のセクション7および[RFC3987]のセクション8を参照してください。
There is potential for spoofing attacks where the attacker publishes Metalinks with false information. In that case, this could deceive unaware downloaders into downloading a malicious or worthless file. Metalink clients are advised to prevent loops, possibly from a mirror server to a Metalink server and back again, in Section 2. As with all downloads, users should only download from trusted sources. Also, malicious publishers could attempt a distributed denial-of-service attack by inserting unrelated URIs into Metalinks. [RFC4732] contains information on amplification attacks and denial-of-service attacks.
攻撃者が誤った情報でMetalinksを公開する攻撃をスプーフィングする可能性があります。その場合、これにより、気付いていないダウンローダーが悪意のあるまたは価値のないファイルをダウンロードするように欺く可能性があります。Metalinkクライアントは、おそらくミラーサーバーからMetalink Serverに戻り、セクション2でループを防止することをお勧めします。すべてのダウンロードと同様に、ユーザーは信頼できるソースからのみダウンロードする必要があります。また、悪意のある出版社は、無関係なURIをMetalinksに挿入することにより、分散型のサービス拒否攻撃を試みることができます。[RFC4732]には、増幅攻撃とサービス拒否攻撃に関する情報が含まれています。
Currently, some of the digest values defined in Instance Digests in HTTP [RFC3230] are considered insecure. These include the whole Message Digest family of algorithms, which are not suitable for cryptographically strong verification. Malicious people could provide files that appear to be identical to another file because of a collision; i.e., the weak cryptographic hashes of the intended file and a substituted malicious file could match.
現在、HTTP [RFC3230]のインスタンスダイジェストで定義されているダイジェスト値の一部は、安全ではないと考えられています。これらには、暗号的に強力な検証には適していない、アルゴリズムのメッセージダイジェストファミリー全体が含まれます。悪意のある人々は、衝突のために別のファイルと同一であると思われるファイルを提供できます。つまり、意図したファイルの弱い暗号化ハッシュと、置換された悪意のあるファイルが一致する可能性があります。
Metalinks SHOULD include digital signatures, as described in Section 5.
Metalinksには、セクション5で説明されているように、デジタル署名を含める必要があります。
Digital signatures provide authentication and message integrity, and enable non-repudiation with proof of origin.
デジタル署名は、認証とメッセージの整合性を提供し、原産地の証明で非繰り返しを可能にします。
[BITTORRENT] Cohen, B., "The BitTorrent Protocol Specification", BITTORRENT 11031, February 2008, <http://www.bittorrent.org/beps/bep_0003.html>.
[Bittorrent] Cohen、B。、「Bittorrent Protocol Specification」、Bittorrent 11031、2008年2月、<http://www.bittorrent.org/beps/bep_303.html>。
[FIPS-180-3] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS PUB 180-3, October 2008.
[FIPS-180-3]国立標準技術研究所（NIST）、「Secure Hash Standard（SHS）」、FIPS Pub 180-3、2008年10月。
[ISO3166-1] International Organization for Standardization, "ISO 3166-1:2006. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", November 2006.
[ISO3166-1]国際標準化機関、「ISO 3166-1：2006。国の名前とその下位区分の表現のためのコード - パート1：国コード」、2006年11月。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 0959, October 1985.
[RFC0959] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 0959、1985年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3156] Elkins、M.、Del Torto、D.、Levien、R.、およびT. Roessler、「OpenPGPを使用したMime Security」、RFC 3156、2001年8月。
[RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", RFC 3230, January 2002.
[RFC3230] Mogul、J。およびA. Van Hoff、「HTTPでのインスタンスダイジェスト」、RFC 3230、2002年1月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] Duerst、M。およびM. Suignard、「国際化されたリソース識別子（IRIS）」、RFC 3987、2005年1月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開キーインフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.2メッセージ仕様」、RFC 5751、2010年1月。
[RFC5854] Bryan, A., Tsujikawa, T., McNab, N., and P. Poeml, "The Metalink Download Description Format", RFC 5854, June 2010.
[RFC5854] Bryan、A.、Tsujikawa、T.、McNab、N。、およびP. Poeml、「The Metalinkダウンロード説明形式」、RFC 5854、2010年6月。
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC5988]ノッティンガム、M。、「Web Linking」、RFC 5988、2010年10月。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732] Handley、M.、Ed。、Rescorla、E.、ed。、およびIAB、「インターネット拒否に関する考慮事項」、RFC 4732、2006年12月。
[RFC5843] Bryan, A., "Additional Hash Algorithms for HTTP Instance Digests", RFC 5843, April 2010.
[RFC5843] Bryan、A。、「HTTPインスタンスダイジェストの追加のハッシュアルゴリズム」、RFC 5843、2010年4月。
Thanks to the Metalink community, Alexey Melnikov, Julian Reschke, Mark Nottingham, Daniel Stenberg, Matt Domsch, Micah Cowan, David Morris, Yves Lafon, Juergen Schoenwaelder, Ben Campbell, Lars Eggert, Sean Turner, Robert Sparks, and the HTTPBIS Working Group.
Metalink Community、Alexey Melnikov、Julian Reschke、Mark Nottingham、Daniel Stenberg、Matt Domsch、Micah Cowan、David Morris、Yves Lafon、Juergen Schoenwaelder、Ben Campbell、Lars Eggert、Sean Turner、Robert Sparks、Httpbis Working Group Group Group Group Group Group。
Thanks to Alan Ford and Mark Handley for spurring us on to publish this document.
Alan FordとMark Handleyに、このドキュメントを公開してくれたことに感謝します。
This document is dedicated to Zimmy Bryan, Juanita Anthony, and Janie Burnett.
この文書は、Zimmy Bryan、Juanita Anthony、Janie Burnettに捧げられています。
Authors' Addresses
著者のアドレス
Anthony Bryan Pompano Beach, FL USA
アンソニーブライアンポンパノビーチ、フロリダ州
EMail: anthonybryan@gmail.com
URI: http://www.metalinker.org
Neil McNab
ニール・マクナブ
EMail: neil@nabber.org
URI: http://www.nabber.org
Tatsuhiro Tsujikawa Shiga Japan
タツヒロ・ツジカワ・シガ・ジャパン
EMail: tatsuhiro.t@gmail.com
URI: http://aria2.sourceforge.net
Dr. med. Peter Poeml MirrorBrain Venloer Str. 317 Koeln 50823 DE
医学博士。Peter Poeml Mirrorbrain Venloer str。317 Koeln 50823 de
Phone: +49 221 6778 333 8
EMail: peter@poeml.de
URI: http://mirrorbrain.org/~poeml/
Henrik Nordstrom
ヘンリック・ノードストローム
EMail: henrik@henriknordstrom.net
URI: http://www.henriknordstrom.net/