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
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を指定：HTTPヘッダフィールドにおけるミラー、暗号化ハッシュ、通常MetalinkのXMLベースのダウンロードの記述形式に含まれている情報を取得するための別の方法。メタリンク/ HTTPは、HTTPヘッダフィールドのための既存の規格を使用して、複数のダウンロード場所（ミラー）、ピア・ツー・ピア、暗号ハッシュ、デジタル署名、およびその他の情報を記載しています。メタリンクのクライアントは、ファイル転送は、より堅牢で信頼性の高い行うために、この情報を使用することができます。メタリンク/ 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
メタリンク/ HTTPは、通常、XMLベースの文書フォーマット[RFC5854]として示されるメタリンク情報の代替と相補的です。そのようなウェブリンク[RFC5988]、HTTPにおけるインスタンスダイジェスト[RFC3230]、および（またてETagとしても知られる）エンティティタグ[RFC2616]などの既存の規格を使用して、メタリンク/ XML形式のように多くの機能を提供するメタリンク/ HTTP試み。メタリンク/ 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、およびピアツーピアなど）のさまざまなプロトコルを介してインターネット上で頻繁に複数の場所にアクセスできます。いくつかのケースでは、ユーザは、これらの複数のダウンロード場所（ミラー）のリストが示されており、手動で地理的位置、優先度、または帯域幅に基づいて単一のものを選択しなければなりません。これは、複数のサーバ間で負荷を分散し、また、スループットと回復力を向上させる必要があります。時には、しかし、個々のサーバは、遅い時代遅れ、または到達不能であることができるが、ダウンロードが開始されるまでこれを決定することができません。ユーザーはめったに最も適切なサーバを選択するのに十分な情報を持っていないだろうと、多くの場合、彼らのニーズに最適ではないかもしれませんし、負荷の不均衡な配分を取得し、特定のサーバーにつながるれ、リストの最初のを選択します。次善のミラーの使用は、ユーザーがキャンセルし、手動でより良いソースを見つけようとしてダウンロードを再開につながることができます。ダウンロード時には、ファイルが破損する可能性があり、伝送中のエラー。これらのファイルを修復する簡単な方法はありません。大規模なダウンロードについては、これは非常に面倒なことができます。ユーザーの一部にフラストレーションにダウンロードリード中に発生する可能性がある多くの問題のいずれか。
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.
この文書は、ミラーの利点は、自動的に、より効果的に実現することができる機構を記載しています。ミラー、暗号ハッシュ、デジタル署名などを含むダウンロードに関するすべての情報は、以下、「メタリンク」と呼ばれる、協調HTTPヘッダフィールドで転送することができます。このメタリンクは、クライアントにダウンロードサーバ（およびミラーデータベース）の知識を転送します。現在の問題を持っている場合、クライアントは、他のミラーにフォールバックすることができます。この知識を使用すると、クライアントがさえ不利な状況下でダウンロードが成功への道を動作するように有効になっています。このすべては、複雑なユーザインタラクションなしに行うことができ、かつダウンロードがはるかに信頼性が高く、効率的にすることができます。一つのサーバへの1つのリンク - - は対照的に、ミラーは、最小限の情報を伝達するために従来のHTTPリダイレクトおよび障害を処理するためのHTTPプロトコルにおける規定はありません。また、ユーザにサーバ間でより良好な負荷分散および潜在高速ダウンロードを提供するために、メタリンク/ 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.
メタリンク/ 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を、ミラー、ピアツーピア情報、メタリンク/ XML、OpenPGPの署名、及び全ファイルの暗号ハッシュとの短いメタリンクサーバーの応答を示します。
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.
この仕様は、メタリンク/ 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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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メタリンク・サーバー：HTTPレスポンスヘッダフィールドにメタリンクを提供する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メタリンク：クライアントからのGETやHEADリクエストに対する返信で、暗号化ハッシュをリストアップミラーやインスタンスのダイジェストをリストアップリンク・ヘッダフィールドを含むMetalinkのサーバからのHTTPレスポンスヘッダフィールドのコレクション。
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リンクヘッダフィールド：HTTPレスポンスヘッダフィールド、[RFC5988]で定義され、それはデジタル署名とともに、潜在的に、ファイルを得るための他のダウンロード方法をミラーをリストとすることができます。
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インスタンスダイジェスト：HTTPレスポンスヘッダフィールド、ダウンロードが完了したら、ファイルの整合性を検証するためにメタリンクのクライアントによって使用されるファイルの暗号ハッシュを含んでいる[RFC3230]で定義されます。
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レスポンスヘッダフィールドは、メタリンククライアントは高度な機能を提供することを可能にします。
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ミラーサーバー：一般的に、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のクライアント：メタリンクを処理し、改善し、ダウンロード体験を提供するためにそれらを使用するアプリケーション。彼らは、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メタリンク/ XML：そのようなミラーと、暗号ハッシュのように、HTTPレスポンスヘッダメタリンクと同様の情報を含むことができる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].
この文脈において、「メタリンク」は、この文書に記載されているようにHTTPヘッダフィールド内のミラーと暗号ハッシュから成るメタリンク/ HTTPを指します。 「メタリンク/ 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.
メタリンクリソースは、リソースのクライアント要求に応答してミラーのリストを提示するリンクヘッダーフィールド[RFC5988]を含みます。メタリンクサーバは、HTTP [RFC3230]でインスタンスのダイジェストを経由して、リソースの暗号化ハッシュを含まなければなりません。インスタンスダイジェスト分野で使用されるアルゴリズムは、<http://www.iana.org/>で「ハイパーテキスト転送プロトコル（HTTP）ダイジェストアルゴリズム値」という名前のIANAレジストリに登録されています。この文書では、これらのアルゴリズムの使用を制限します。 SHA-256およびSHA-512は、[RFC5843]でレジストリに加えました。メタリンクは、セクション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.
メタリンクサーバは、一つ以上のメタリンクのリソースを持つHTTPサーバです。メタリンクサーバーでは、ミラーをリストするためのリンクヘッダフィールドをサポートしなければならないし、HTTP [RFC3230]でインスタンスのダイジェストをサポートしなければなりません。メタリンクサーバは、HEADリクエストで同じリンクヘッダフィールドとインスタンスのダイジェストを返さなければなりません。メタリンクサーバーとそれに関連する優先ミラーサーバはすべて同じETagのポリシーを共有しなければなりません。メタリンクサーバーとそれに関連する通常のミラーサーバはすべて同じETagのポリシーを共有する必要があります。 （「好ましい」と「通常」のミラーサーバの定義については、3.3節を参照してください。）これは、ミラー・サーバの管理者に共有のETagポリシーの詳細を伝えるためにメタリンクサーバーの管理者に任されているので、ミラーサーバ同じETagをポリシーで設定することができます。同じETagのポリシーを持っていることはてETagがミラーリングされているリソースのためのサーバー間で同期されていることを意味します。すなわち、バイト単位の同一のファイルは、彼らがMetalinkのサーバー上で持っている鏡で同じETagをしています。例えば、サーバー固有のファイルシステムのメタデータよりもファイルの内容の暗号化ハッシュからのETagを導出する方が良いだろう。メタリンクサーバは、エラー回復が望まれる場合、ファイルの一部の暗号化ハッシュ（およびその他の情報）を含んメタリンク/ 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のミラーサーバは、メタリンクサーバーと同じアルゴリズムを使用してHTTP [RFC3230]でインスタンスのダイジェストをサポートする必要があります。最適には、HTTPのミラーサーバは同じETagの方針を共有し、HTTPでインスタンスのダイジェストをサポートします。同じETagのポリシーを共有および/またはメタリンクサーバーと同じアルゴリズムを使用してHTTPでインスタンスダイジェストをサポートするミラーサーバが好ましく、ミラーサーバとして知られています。
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.
メタリンクのクライアントは、リンクヘッダフィールド[RFC5988]でMetalinkのサーバが提供するミラーを使用しますが、これらのクライアントは、彼らが最初に連絡しMetalinkのサーバが提供するミラーを使用するように制限されています。メタリンクのクライアントがリンクヘッダフィールドミラーとしての地位をリストターンリストの鏡で、またはメタリンクサーバーからのことをミラーから[RFC5988]を見つけた場合、彼らは可能な無限ループを防ぐために、このようなリンクヘッダフィールド[RFC5988]を捨てなければなりません。メタリンクのクライアントは、HTTPをサポートしなければならないし、FTP [RFC0959]をサポートすべきです。メタリンクのクライアントは、BitTorrentの[BitTorrentの]またはその他のダウンロード方法をサポートするかもしれません。ミラーが到達不能になった場合にメタリンクのクライアントが別のミラーからのダウンロードを切り替える必要があります。メタリンククライアントは、（ピア・ツー・ピアのソースから必要に応じて、及び、）ファイルの部分が同時に複数のミラーからダウンロードできるマルチソース、または並列、ダウンロードをサポートしてもよいです。メタリンクのクライアントが要求すると、暗号ハッシュを検証することにより、HTTP [RFC3230]でインスタンスのダイジェストをサポートしなければなりません。メタリンクのクライアントは、メタリンク/ XMLファイルに記載されているファイルの一部の暗号化ハッシュを使用してエラー回復をサポートする必要があります。メタリンクのクライアントは、デジタル署名をチェックをサポートすべきです。
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 "GEO"：ミラー地理的位置（3.2節を参照してください）。
o "pref" : a preferred mirror server (see Section 3.3).
O「県」：優先ミラーサーバ（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つのだけのミラーとの短いメタリンクサーバーの応答を示しています。
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のサーバが提供するフィールドリンクの量を設定するには、組織の責任です。このような決定は、ランダム選択やネットワークプロキシミティ、ファイルサイズ、サーバーの負荷、またはその他の要因に基づいて、ハードコードされた制限である可能性があります。
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」属性を持つミラーは、999999の値を有すると考えられるが、「PRI」属性の有効範囲は、1から「PRI」属性を有し、より高い優先順位の低い値を持つ999999ミラーサーバーにです最も低い優先度です。例えば、「PRI = 10」のミラーは、「PRI = 20」のミラーよりも高い優先度を有しています。メタリンクのクライアントは、最初に下の「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のミラーサーバのエントリは、通常の鏡のための「県」値とエントリを持っていません。好適ミラーサーバーは、元のメタリンクサーバーと同じでETagポリシーを共有しなければなりませんHTTPミラーサーバーである、またはETagのは、メタリンクサーバーと同じアルゴリズムを使用してインスタンスのダイジェストを提供しなければならない使用されていない場合。好適なミラーは、それが可能なデータが転送される前に、要求されたファイルが目的のファイルと一致した場合にメタリンクのクライアントは、早い段階で検出するために作ります。この初期のファイルの不一致の検出は、セクション7.1.1に記載されています。通常のミラーは、必ずしも同一のETagの方針を共有したり、メタリンクサーバーと同じアルゴリズムを使用してインスタンスのダイジェストをサポートしていません。彼らはてETagを発するか、インスタンスのダイジェストをサポートしていないとして、FTPミラーは、「正常な」と考えられています。
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
リンク：<http://www2.example.com/dir1/dir2/dir3/dir4/dir5/example.ext>。 relが=重複します。 PRI = 1。県;深さ= 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.
ピアツーピアネットワーク上のファイルをダウンロードするか、そうでなければする方法を記述するメタ情報ファイル、のエントリは、リンクヘッダーフィールド[RFC5988]及び「describedbyの」の関係タイプとのMIMEタイプを示すタイプパラメータで指定されていますURIで使用可能なメタデータ。メタ情報ファイルは、時には複数のファイルを記述することができ、またはファイル名がメタリンクサーバー上およびメタ情報ファイルには同じではないかもしれないが、それでも同じ内容を持っている可能性があるため、オプション「名前」属性を使用することができます。
The following list contains an OPTIONAL attribute, which is defined in this document:
以下のリストは、この文書で定義されているOPTIONAL属性を、含まれています。
o "name" : a file described within the metainfo file.
メタ情報ファイル内に記述ファイル：「名前」O。
This example shows a brief Metalink server response with .torrent and .meta4:
この例では.torrentと.meta4との短いメタリンクサーバーの応答を示しています。
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.
メタリンクのクライアントは、ファイルをダウンロードするためのメタ情報ファイルの使用をサポートするかもしれません。
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の例に示すように、特定のリソースのためのメタリンク/ XMLファイルはリンクヘッダフィールドで提供することができるメタリンク/ XMLファイルは[RFC5854]で指定され、それらは、そのような部品の暗号ハッシュなどのメタデータを提供するために特に有用ですファイルの、クライアントがエラー（7.1.2項を参照）から回復することができます。メタリンクサーバは、リンクヘッダフィールドで部分的なファイルハッシュとメタリンク/ XMLファイルを提供すべきである、とメタリンクのクライアントは、エラー回復のためにそれらを使用すべきです。
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]及び「describedbyの」および「アプリケーション/ PGP署名」の型パラメータの関係式で規定されています。
This example shows a brief Metalink server response with OpenPGP signature only:
この例では唯一のOpenPGP署名との短いメタリンクサーバーの応答を示しています。
Link: <http://example.com/example.ext.asc>; rel=describedby; type="application/pgp-signature"
リンク：<http://example.com/example.ext.asc>。 rel = describedbyの。タイプ=「アプリケーション/ PGP署名」
Metalink clients SHOULD support the use of OpenPGP signatures.
メタリンクのクライアントは、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]及び「describedbyの」および「アプリケーション/ PKCS7-MIME」の型パラメータの関係式で規定されています。
This example shows a brief Metalink server response with S/MIME signature only:
この例は、S / MIME署名との短いメタリンクサーバーの応答を示しています。
Link: <http://example.com/example.ext.p7m>; rel=describedby; type="application/pkcs7-mime"
リンク：<http://example.com/example.ext.p7m>。 rel = describedbyの。タイプ= "アプリケーション/ PKCS7-パントマイム"
Metalink clients SHOULD support the use of S/MIME signatures.
メタリンクのクライアントは、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を、ミラー、および暗号化ハッシュとの短いメタリンクサーバーの応答を示しています。
Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5=" Link: <http://www2.example.com/example.ext>; rel=duplicate Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlO DYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==
ETag： "thvDyvhfIqlvFe + A9MYgxAfm1q5 =" リンク：<http://www2.example.com/example.ext>。 SHA-256 = MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlO DYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ ==：relが=ダイジェストを複製します
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.
メタリンクのクライアントは、標準のHTTP [RFC2616] Metalinkのサーバに要求をGETして、ダウンロードを開始します。必要に応じて、メタリンクのクライアントは、範囲制限を使用するかもしれません。
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:
メタリンクサーバーは、データとこれらのヘッダフィールドで応答します。
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のサーバにHEADリクエストで始まり、その後、リンクヘッダフィールド経由で見つかったすべての可能なミラーサーバー上で、次の意思決定にスキップすることができます。
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:
メタリンクサーバーの応答から、クライアントがオブジェクトの受信を開始することに加えて、要求されたオブジェクトに関する次のメタデータの一部またはすべてを学習します。
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.
それは、発信メタリンクサーバー、地理的位置、およびミラー深さのETagのポリシーを共有するかどうか、ミラーの優先順位を記述する任意の属性を持つOミラーの位置、。
o Instance Digest, which is the whole file cryptographic hash.
ファイル全体暗号化ハッシュあるインスタンスダイジェスト、O。
o ETag.
OのETag。
o Object size from the Content-Length header field.
Content-LengthヘッダフィールドからOオブジェクトのサイズ。
o Metalink/XML, which can include partial file cryptographic hashes to repair a file.
O部分的なファイル暗号化ハッシュを含むことができ、メタリンク/ 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:
次に、メタリンクのクライアントが優先ミラーサーバーからのオブジェクトの範囲を要求し、それは、もしマッチ条件を使用することができます。
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
GET /example.ext HTTP / 1.1ホスト：www2.example.com範囲：バイト= 7433802-もしマッチ： "thvDyvhfIqlvFe + A9MYgxAfm1q5 =" リファラー：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.
可能であれば7.1.1項で説明したように、彼らは初期のファイルの不一致の検出を可能とメタリンクのクライアントは、好ましい鏡を使用すべきです。 3.3節で説明したように好適なミラーは、てETagをコーディネートしている、とのETagに基づく条件迅速メタリンクサーバーの応答からのETagを使用して期限切れのミラーを検出するために、マッチの場合はメタリンククライアントが使用すべきです。利用可能な場合、ミラーサーバーは、正しいデータを返したかどうかを検出するために、第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.
最適には、ミラーサーバーもクライアントも、早期の不整合を検出するために使用することができ、クライアントのGETリクエストにミラー応じて、インスタンスのダイジェストが含まれます。メタリンクのクライアントは、インスタンスダイジェストメタリンクサーバーと同じアルゴリズムによって報告されたインスタンスのダイジェストが一致しないミラーからのインスタンスのダイジェストが使用されている場合はサポートミラーから個々のダウンロードを拒絶しなければなりません。通常のミラーが使用されている場合は終了し、オブジェクトが検証されるまで、その後のミスマッチを検出することはできません。意図的または偶発的かどうかを、セクション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:
ここでは、優先ミラーサーバーは、「コンテンツ・レンジ」、ETagを、およびインスタンスダイジェストヘッダフィールドを正しいファイル（もしマッチ条件の一致）を有し、206部分コンテンツHTTPステータスコードと適切な「コンテンツ長」で応答します。この例では、ミラーサーバがデータと、上記要求に、応答します。
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==
HTTP / 1.1 206部分コンテンツのAccept-範囲：バイトのContent-Length：7433801コンテンツレンジ：バイト7433802から14867602/14867603のEtag： "thvDyvhfIqlvFe + A9MYgxAfm1q5 =" ダイジェスト：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.
メタリンククライアントは、「重複」の関係タイプとのリンクヘッダフィールドによって提供されるミラーを用いた並列範囲要求の数（第一以外の選択されたミラー・サーバごとに1つ）を開始してもよいです。メタリンクのクライアントは、理想的には接続などの集約スループットの変化が開いているかを観察に基づいて、ミラーサーバーへの並列接続数を制限しなければなりません。パスのボトルネックが満たされたら、それは盲目的にオープン接続には無意味だろう。新しい接続を確立した後、メタリンクのクライアントは、ダウンロードの一部であるすべての接続を介して集約スループットが増加するかどうかを監視する必要があります。クライアントは、この期間中に追加の接続を開くべきではありません。集約スループットが増加した場合、クライアントは、追加の接続を開き、これらの手順を繰り返してもよいです。設立1が閉じるまでそうでない場合、クライアントは新しい接続を開くべきではありません。メタリンククライアントは、これらの範囲要求のための「リファラー」ヘッダフィールド内のオリジナルの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 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.
目標は最速の転送の場合は最初のリクエストの後に生成された任意の範囲の要求は、代わりにパーシャルレスポンスの完全な応答、（一部のミラーがHTTP範囲をサポートしていない可能性がありますよう）で終わる場合はメタリンククライアントが最速の接続が、すべてを閉じる必要があります。メタリンクのクライアントは、ミラーの状態を監視し、動的に最速ダウンロードを達成するために、ミラーの間で切り替えることができます。同様に、メタリンクのクライアントが非常に遅いか、失速範囲要求を中止し、他のミラー上の要求を完了する必要があり。すべての範囲が最終的な1を除いて終了した場合は、転送が速く終わるので、メタリンクのクライアントは、他のミラーへの複数範囲要求に、最終的な範囲を分割することができます。
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した場合、Rangeヘッダフィールドが送信されなかった、そしてクライアントはそれが範囲要求を発行することを後で決定し、その後、クライアントは、最初の接続を閉じる必要があります。これは、最初の接続が殺したことを意味します。メタリンクのクライアントは、可能であれば任意のリンクヘッダフィールドが存在する場合、クライアントは見つけることができるように、最初のHEADリクエストを使用することができ、その後、範囲ベースの要求は、最初の接続を犠牲にすることなく、ミラーサーバに着手しています。
Metalink clients MUST reject individual downloads from mirrors where the file size does not match the file size as reported by the 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.
メタリンクのクライアントがファイルから利用可能であること（例えば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のサーバによって提供される暗号化ハッシュは、ダウンロードしたファイルの暗号化ハッシュが一致しない場合は、エラーを修復するために可能な方法については、セクション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.
エラー防止、あるいは早期のファイルの不一致の検出は、Metalinkのサーバが提供するファイルのサイズ、てETag、およびインスタンスのダイジェストを利用したファイル転送の前に可能です。エラー検出は、転送が完了した後で転送中のエラーを検出するためのインスタンスのダイジェストが必要です。誤り訂正、またはダウンロードの修復は、部分的なファイルの暗号ハッシュで可能です。
Note that cryptographic hashes obtained from Instance Digests are in base64 encoding, while those from Metalink/XML are in hexadecimal.
メタリンク/ XMLからのものは16進数である間インスタンス消化物から得られた暗号ハッシュは、base64エンコーディングであることに注意してください。
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用語では、複数の応答の範囲のマージは、このコンテキストでインスタンスダイジェスト又は好適ミラーサーバによって提供されるインスタンスダイジェストまたはのETagと一致するメタリンクサーバから共有のETagのいずれかである強力なバリデータで確認してください。ほとんどの場合、メタリンクサーバーは、ミラーとインスタンスダイジェスト情報を提供することで十分であるが、ミラーサーバが同様に共有のETagポリシーまたはインスタンスのダイジェストを実装しない場合の動作は、より堅牢かつ効率的になります。それはメタリンクサーバーとミラーサーバー間で共有する必要があるだけであること、のETagの生成方法を指定する必要はありません。ミラーサーバはインスタンスのダイジェストを返すことの利点は、クライアントが、その後て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と一致した場合には、メタリンクのクライアントは応答がそのオブジェクトに対して有効な前提としています。
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.
これは、不一致がメタリンクサーバーとミラーサーバーからのみ共有のETagを用いて検出されることを保証します。 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
共有のETagまたはインスタンスのダイジェストは、厳密には、悪意のある攻撃やコンテンツを交換するサーバやネットワークエラーから保護することはできません。攻撃者は、ミラーサーバーは、一見、期待に応えることができます
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。同じことがまた、不良データ（すなわち、破損したファイル）が返される原因となるさまざまなシステム障害のために行きます。メタリンクのクライアントは、全体としてダウンロードされたオブジェクトの検証のための最初の応答にメタリンクサーバーから返されたインスタンスのダイジェストに依存しなければなりません。異なるソースから要求されている可能性があり、個々の範囲を、確認するには、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.
部分的なファイル暗号化ハッシュは、ダウンロード中にエラーを検出するために使用することができます。セクション4.1で指定されたメタリンクサーバは、リンクヘッダフィールドで部分的なファイルハッシュとメタリンク/ XMLファイルを提供すべきである、とメタリンクのクライアントは、エラー訂正のためにそれらを使用すべきです。
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.
転送または置換攻撃の誤差はメタリンクサーバからインスタンスダイジェストと一致しないオブジェクトの暗号ハッシュによって検出されます。オブジェクトの暗号化ハッシュは、メタリンクサーバーからのインスタンスのダイジェストと一致しない場合、クライアントは、（利用可能な場合）メタリンク/ XMLをフェッチすべきです。これは、ミラーサーバーが不正なデータが返されたの検出を可能にする部分的なファイル暗号化ハッシュを含んでいてもよいです。メタリンクのクライアントが回復することができ、ダウンロードされたデータの範囲を何して再度フェッチする必要があるかを把握するためにメタリンク/ 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.
他の方法は、エラー訂正のために使用することができます。例えば、いくつかの他のメタ情報ファイルもエラーをチェックするために使用することができ、部分ファイルハッシュが含まれます。
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.
メタリンクのクライアントは、URIと国際化資源識別子（アイリス）を扱います。彼らの取り扱いと使用に関連するセキュリティ上の考慮事項については、[RFC3986]と[RFC3987]のセクション8のセクション7を参照してください。
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.
攻撃者が虚偽の情報をメタリンクを公開してスプーフィング攻撃の可能性があります。その場合には、これは悪意があるか、価値のないファイルをダウンロードするに気づかずダウンローダを欺くことができます。メタリンクのクライアントは、おそらくミラーサーバーからのメタリンクサーバーに、ループを防止することをお勧めしますし、再び、すべてのダウンロードと同様に、第2節では、ユーザーは、信頼できるソースからのみダウンロードする必要があります。また、悪質な出版社はメタリンクに関係のないURIを挿入することにより、分散型サービス拒否攻撃を試みることができます。 [RFC4732]は、増幅攻撃やDoS攻撃に関する情報が含まれています。
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.
セクション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の]コーエン、B.、 "BitTorrentのプロトコル仕様"、BitTorrentの11031、2008年2月、<http://www.bittorrent.org/beps/bep_0003.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）、 "セキュアハッシュ規格（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]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル"、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - 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]エルキンズ、M.、デルTorto、D.、Levien、R.、およびT.レスラー、 "OpenPGPの持つMIMEセキュリティ"、RFC 3156、2001年8月。
[RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", RFC 3230, January 2002.
[RFC3230]ムガール人、J.とA.バンホフ、 "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]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、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、 "国際化リソース識別Fiers（IRI）"、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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネット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.ターナー、 "/セキュア多目的インターネットメール拡張（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]ブライアン、A.、辻川、T.、マクナブ、N.、およびP. Poeml、 "Metalinkのダウンロード説明形式"、RFC 5854、2010年6月。
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC5988]ノッティンガム、M.、 "ウェブリンク"、RFC 5988、2010年10月。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]ハンドリー、M.、エド。、レスコラ、E.、エド。、およびIAB、 "インターネットサービス拒否の注意事項"、RFC 4732、2006年12月。
[RFC5843] Bryan, A., "Additional Hash Algorithms for HTTP Instance Digests", RFC 5843, April 2010.
[RFC5843]ブライアン、A.、 "HTTPインスタンスダイジェストのための追加のハッシュアルゴリズム"、RFC 5843、2010年4月。
Appendix A. Acknowledgements and Contributors
付録A.謝辞と協力者
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のコミュニティのおかげで、アレクセイ・メルニコフ、ジュリアンReschke、マーク・ノッティンガム、ダニエル・ステンバーグ、マット・Domsch、ミカ・コーワン、デビッド・モリス、イヴ・ラフォン、ユルゲンSchoenwaelder、ベン・キャンベル、ラースEggertの、ショーン・ターナー、ロバートスパークス、およびHTTPBISワーキンググループ。
Thanks to Alan Ford and Mark Handley for spurring us on to publish this document.
このドキュメントを公開するために私達の上の拍車をかけためのアラン・フォードとマーク・ハンドリーに感謝します。
This document is dedicated to Zimmy Bryan, Juanita Anthony, and Janie Burnett.
この文書はZimmyブライアン、Juanitaのアンソニー、およびJanieバーネットに捧げられています。
Authors' Addresses
著者のアドレス
Anthony Bryan Pompano Beach, FL USA
アンソニー・ブライアンポンパノビーチ、FL USA
EMail: anthonybryan@gmail.com URI: http://www.metalinker.org
電子メール：anthonybryan@gmail.com URI：http://www.metalinker.org
Neil McNab
ニール・マクナブ
EMail: neil@nabber.org URI: http://www.nabber.org
電子メール：neil@nabber.org URI：http://www.nabber.org
Tatsuhiro Tsujikawa Shiga Japan
たつひろ つじかわ しが じゃぱん
EMail: tatsuhiro.t@gmail.com URI: http://aria2.sourceforge.net
電子メール：tatsuhiro.t@gmail.com URI：http://aria2.sourceforge.net
Dr. med. Peter Poeml MirrorBrain Venloer Str. 317 Koeln 50823 DE
博士MED。ピーターPoeml MirrorBrain VenloerのStr。317ケルン50823 DE
Phone: +49 221 6778 333 8 EMail: peter@poeml.de URI: http://mirrorbrain.org/~poeml/
電話：+49 221 6778 333 8 Eメール：peter@poeml.de URI：http://mirrorbrain.org/~poeml/
Henrik Nordstrom
ヘンリク・ノードストローム
EMail: henrik@henriknordstrom.net URI: http://www.henriknordstrom.net/
電子メール：henrik@henriknordstrom.net URI：http://www.henriknordstrom.net/