Network Working Group M. Nottingham
Request for Comments: 5005 September 2007
Category: Standards Track
Feed Paging and Archiving
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This specification defines three types of syndicated Web feeds that enable publication of entries across one or more feed documents. This includes "paged" feeds for piecemeal access, "archived" feeds that allow reconstruction of the feed's contents, and feeds that are explicitly "complete".
この仕様は、一の以上のフィード文書全体のエントリの発行を可能にするシンジケートのWebフィードの3種類を定義します。これは、「ページング」断片的にアクセスするために、明示的に「完全」であり、フィードの内容の再構築を許すフィード、およびフィードを「アーカイブ」のフィードが含まれます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Complete Feeds . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Paged Feeds . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Archived Feeds . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Publishing Archived Feeds . . . . . . . . . . . . . . . . 8
4.2. Consuming Archived Feeds . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12
Appendix B. Use in RSS 2.0 . . . . . . . . . . . . . . . . . . . 12
Syndicated Web feeds (using formats such as Atom [1]) are often split into multiple documents to save bandwidth, allow "sliding window" access, or for other purposes.
シンジケートのWebフィード（Atomなどの形式を使用して[1]）は、多くの場合、アクセス「スライディングウィンドウ」、または他の目的のために、帯域幅を節約できるように、複数の文書に分割されています。
This specification formalizes two types of feeds that can span one or more feed documents; "paged" feeds and "archived" feeds. Additionally, it defines "complete" feeds to cover the case when a single feed document explicitly represents all of the feed's entries.
この仕様は、一つ以上のフィード文書をまたがることができるフィードの2種類を形式化。フィードと「アーカイブ」のフィードを「ページング」。さらに、それは「完了」を定義し、単一のフィード文書は、明示的にフィードのエントリのすべてを表している場合をカバーするためにフィード。
Each has different properties and trade-offs:
それぞれ異なる特性とのトレードオフがあります。
o Complete feeds contain the entire set of entries in one document, and can be useful when it isn't desirable to "remember" previously-seen entries.
O完全フィードは一つの文書内のエントリのセット全体が含まれており、以前に見たのエントリを「記憶」することは望ましくないときに便利です。
o Paged feeds split the entries among multiple temporary documents. This can be useful when entries in the feed are not long-lived or stable, and the client needs to access an arbitrary portion of them, usually in close succession.
Oページングされたフィードは、複数の一時的な文書の中のエントリを分割します。フィード内のエントリは、長寿命や安定しておらず、クライアントは通常、密接に連続して、それらの任意の部分にアクセスする必要がある場合に便利です。
o Archived feeds split the entries among multiple permanent documents and can be useful when entries are long-lived, and it is important for clients to see every one.
Oアーカイブは、複数の永久の文書の中でエントリーを分割し、エントリが長寿命である場合に役立つことができフィード、およびクライアントはすべてのものを見ることが重要です。
The semantics of a feed that combines these types is undefined by this specification.
これらのタイプを組み合わせた飼料のセマンティクスは、この仕様で定義されていません。
Although they refer to Atom normatively, the mechanisms described herein can be used with similar syndication formats; see Appendix B for one such use.
彼らは規範原子に言及しているが、本明細書に記載されるメカニズムは、同様のシンジケーションフォーマットを使用することができます。そのような使用については、付録Bを参照してください。
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 RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
This specification uses XML Namespaces [3] to uniquely identify XML element names. It uses the following namespace prefix for the indicated namespace URI;
この仕様は、XML名前空間は、[3]一意XML要素名を識別するために使用します。これは、指定された名前空間URIのために次の名前空間接頭辞を使用しています。
"fh": "http://purl.org/syndication/history/1.0"
In this specification, "feed document" refers to an Atom Feed Document or similar syndication instance document. It may contain any number of entries, and may or may not be a complete representation of the logical feed.
本明細書において、「フィード文書は、」Atomフィード文書または類似のシンジケーションインスタンス文書を指します。これは、任意の数のエントリを含むことができ、または論理フィードの完全な表現であってもなくてもよいです。
A "logical feed" is the complete set of entries associated with a feed (as contrasted with a feed document, which may contain a subset of entries).
「論理フィード」は、（エントリのサブセットを含むことができるフィード文書とは対照的に）フィードに関連付けられたエントリの完全なセットです。
"Head section" refers to a document's feed-wide metadata container; e.g., the child elements of the atom:feed element in an Atom Feed Document.
「頭のセクションでは、」ドキュメントのフィード全体のメタデータコンテナを参照します。原子の、例えば、子要素：Atomフィード文書における給電素子。
This specification uses terms from the XML Infoset [4]. However, this specification uses a shorthand; the phrase "Information Item" is omitted when naming Element Information Items. Therefore, when this specification uses the term "element," it is referring to an Element Information Item in Infoset terms.
この仕様は、XML情報セットからの用語を使用する[4]。しかし、この仕様は、速記を使用しています。要素情報項目に名前を付けるときに、フレーズ「情報項目は、」省略されています。したがって、この仕様は用語を使用しています「要素、」それはインフォセット用語で要素情報項目を参照しています。
This specification also uses Atom link relations to identify different types of links; see the Atom specification [1] for information about their syntax, and the IANA link relation registry for more information about specific values.
また、この仕様は異なるタイプのリンクを識別するために、Atomのリンク関係を使用しています。 Atom仕様[1]その構文の詳細については、および特定の値の詳細については、IANAリンク関係のレジストリを参照してください。
Note that URI references in link relation values may be relative, and when they are used they must be absolutised, as described in Section 5.1 of [5].
リンク関係値のURI参照は相対的であってもよいし、それらが使用される場合、[5]のセクション5.1に記載されているように、それらは、absolutisedされなければなりません。
A complete feed is a feed document that contains all of the entries of a logical feed; any entry not actually in the feed document SHOULD NOT be considered part of that feed.
完全飼料は、論理的なフィードのエントリのすべてが含まれているフィード文書です。フィード文書ではない、実際にどのエントリがそのフィードの一部とみなされるべきではありません。
For example, a feed that represents a ranking that varies over time (such as "Top Twenty Records" or "Most Popular Items") should not have newer entries displayed alongside older ones. By marking this feed as complete, old entries are discarded when it is refreshed.
例えば、（例えば、「トップ20のレコード」または「人気商品」など）、時間とともに変化する順位を表しフィードは古いものと一緒に表示された新しいエントリを持つべきではありません。それが更新されたとき、完全なように、このフィードをマークすることによって、古いエントリは破棄されます。
The fh:complete element, when present in a feed's head section, indicates that the feed document it occurs in is a complete representation of the logical feed's entries. It is an empty element; this specification does not define any content for it.
FH：フィードのヘッド部に存在する完全な要素は、それが中に発生するフィード文書は、論理フィードのエントリの完全な表現であることを示しています。これは、空の要素です。この仕様は、それのために任意のコンテンツを定義していません。
Example: Atom-formatted Complete Feed
例：Atomのフォーマットの完全飼料
<?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom" xmlns:fh="http://purl.org/syndication/history/1.0"> <title>NetMovies Queue</title> <subtitle>The DVDs you'll receive next.</subtitle> <link href="http://example.org/"/> <fh:complete/> <link rel="self" href="http://netmovies.example.org/jdoe/queue/index.atom"/> <updated>2003-12-13T18:30:02Z</updated> <author> <name>John Doe</name> </author> <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id> <entry> <title>Casablanca</title> <link href="http://netmovies.example.org/movies/Casablanca"/> <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> <updated>2003-12-13T18:30:02Z</updated> <summary>Here's looking at you, kid...</summary> </entry> </feed>
<？xml version = "1.0" エンコード= "UTF-8"？> <フィードのxmlns = "http://www.w3.org/2005/Atom" のxmlns：FH = "http://purl.org/syndication /history/1.0 "> <タイトル> NetMoviesキュー</ TITLE> <字幕>あなたは次の届きのDVD </字幕> <リンクのhref =" http://example.org/ "/> <FH：完全な/> <リンクのrel = "自己" のhref = "http://netmovies.example.org/jdoe/queue/index.atom" /> <更新> 2003-12-13T18：30：02Z </更新> <作者> <名前>ジョン・ドウ</名前> </著者> <id>の壷：UUID：60a76c80-d399-11d9-b93C-0003939e0af6 </ ID> <entry>の<タイトル>カサブランカ</ TITLE> <リンクのhref =」 http://netmovies.example.org/movies/Casablanca "/> <ID> URN：UUID：1225c695-cfb8-4ebb-AAAA-80da344efa6aは</ idは> <更新> 2003-12-13T18：30：02Z </更新> <概要>ここで見ている、子供... </要約> </ entry>の</フィード>
This specification does not address duplicate entries in complete feeds.
この仕様は、完全なフィードで重複したエントリに対応していません。
A paged feed is a set of linked feed documents that together contain the entries of a logical feed, without any guarantees about the stability of each document's contents.
ページングされたフィードは一緒に各ドキュメントの内容の安定性についていかなる保証もなしに、論理的なフィードのエントリが含まれているリンクのフィード文書のセットです。
Paged feeds are lossy; that is, it is not possible to guarantee that clients will be able to reconstruct the contents of the logical feed at a particular time. Entries may be added or changed as the pages of the feed are accessed, without the client becoming aware of them.
ページングされたフィードは非可逆です。つまり、クライアントが特定の時点で論理フィードの内容を再構築することができるようになりますことを保証することはできません。フィードのページがアクセスされるエントリは、クライアントが彼らの意識になることなく、追加または変更することができます。
Therefore, clients SHOULD NOT present paged feeds as coherent or complete, or make assumptions to that effect.
したがって、クライアントが存在ページングは、コヒーレントまたは完全なフィード、またはその旨を仮定するべきではありません。
Paged feeds can be useful when the number of entries is very large, infinite, or indeterminate. Clients can "page" through the feed, only accessing a subset of the feed's entries as necessary.
エントリ数が非常に大きい無限、または不定であるとき、ページングされたフィードが役立つことがあります。クライアントは、のみ、必要に応じてフィードのエントリのサブセットをフィードで「ページ」にアクセスすることができます。
For example, a search engine might make query results available as a paged feed, so that queries with very large result sets do not overwhelm the server, the network, or the client.
非常に大きな結果セットを持つクエリは、サーバ、ネットワーク、またはクライアントを圧倒しないように例えば、検索エンジンは、ページ化飼料としてクエリの結果が利用可能になるかもしれません。
The feed documents in a paged feed are tied together with the following link relations:
ページングされた飼料中のフィード文書は、以下のリンク関係で結ばれています。
o "first" - A URI that refers to the furthest preceding document in a series of documents.
O「第一」 - ドキュメント一連の文書を先行遠いを指すURI。
o "last" - A URI that refers to the furthest following document in a series of documents.
O「最後」 - 一連の文書内の文書、次の遠いを指しURI。
o "previous" - A URI that refers to the immediately preceding document in a series of documents.
O「前」 - ドキュメント一連の直前の文書を指すURI。
o "next" - A URI that refers to the immediately following document in a series of documents.
O「次へ」 - 一連の文書にすぐに次のドキュメントを参照するURI。
Paged feed documents MUST have at least one of these link relations present, and should contain as many as practical and applicable.
ページングされたフィード文書は、これらのリンク関係の少なくとも一つの存在が必要であり、実用的で適用可能な限り多くを含める必要があります。
Example: Atom-formatted Paged Feed
例：Atomのフォーマットのページングされたフィード
<?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> <title>Example Feed</title> <link href="http://example.org/"/> <link rel="self" href="http://example.org/index.atom"/> <link rel="next" href="http://example.org/index.atom?page=2"/> <updated>2003-12-13T18:30:02Z</updated> <author> <name>John Doe</name> </author> <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id> <entry> <title>Atom-Powered Robots Run Amok</title> <link href="http://example.org/2003/12/13/atom03"/> <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> <updated>2003-12-13T18:30:02Z</updated> <summary>Some text.</summary> </entry> </feed>
<？xml version = "1.0" エンコード= "UTF-8"？> <フィードのxmlns = "http://www.w3.org/2005/Atom"> <タイトル>例フィード</タイトル> <リンクHREF = "http://example.org/" /> <リンクのrel = "自己" のhref = "http://example.org/index.atom" /> <リンクのrel = "次" のhref = "のhttp：// example.org/index.atom?page=2" /> <更新> 2003-12-13T18：30：02Z </更新> <著者> <名前>ジョン・ドウ</名前> </著者> <id>の壷：UUID：60a76c80-d399-11d9-b93C-0003939e0af6 </ ID> <entry>の<タイトル>原子-Poweredのロボットラン逆上</ TITLE> <リンクのhref = "http://example.org/2003/12/13 / atom03" /> <ID> URN：UUID：30：：02Z </更新> <概要>一部のテキスト</要約</ ID> <更新> 2003-12-13T18 1225c695-cfb8-4ebb-AAAA-80da344efa6a > </ entry>の</フィード>
This specification does not address duplicate entries in paged feeds.
この仕様は、ページングされたフィードに重複したエントリに対応していません。
An archived feed is a set of feed documents that can be combined to accurately reconstruct the entries of a logical feed.
アーカイブフィードを正確に論理的なフィードのエントリを再構築するために組み合わせることができるフィードドキュメントのセットです。
Unlike paged feeds, archived feeds enable clients to do this without losing entries. This is achieved by publishing a single subscription document and (potentially) many archive documents.
ページングフィードとは違って、アーカイブされたフィードはエントリを失うことなく、これを行うために、クライアントを有効にします。これは、単一のサブスクリプション文書と（潜在的に）多くのアーカイブ文書を公開することによって達成されます。
A subscription document is a feed document that always contains the most recently added or changed entries available in the logical feed.
サブスクリプションの文書は常に論理フィードで利用可能な最も最近追加または変更のエントリが含まれているフィード文書です。
Archive documents are feed documents that contain less recent entries in the feed. The set of entries contained in an archive document published at a particular URI SHOULD NOT change over time. Likewise, the URI for a particular archive document SHOULD NOT change over time.
アーカイブ文書は、飼料中の少ない最近のエントリを含む文書を供給しています。特定のURIで公開アーカイブ文書に含まれるエントリのセットは、時間の経過とともに変化してはなりません。同様に、特定のアーカイブ文書のURIは、時間の経過とともに変化してはなりません。
The following link relations are used to tie subscription and archived feeds together:
以下のリンク関係は、サブスクリプションを結びつけるために使用され、アーカイブされ、一緒フィード：
o "prev-archive" - A URI that refers to the immediately preceding archive document.
O「PREVアーカイブ」 - 直前のアーカイブ文書を指すURI。
o "next-archive" - A URI that refers to the immediately following archive document.
o「の次のアーカイブ」 - URI直後のアーカイブ文書を参照します。
o "current" - A URI that, when dereferenced, returns a feed document containing the most recent entries in the feed.
O「現在」 - URI間接参照、ということは、フィード内の最新のエントリを含むフィード文書を返します。
Subscription documents and archive documents MUST have a "prev-archive" link relation, unless there are no preceding archives available. Archive documents SHOULD also have a "next-archive" link relation, unless there are no following archives available.
使用可能な前のアーカイブが存在しない場合を除きサブスクリプションの文書やアーカイブ文書は、「前のアーカイブ」リンク関係を持たなければなりません。使用可能な次のアーカイブが存在しない場合を除き、アーカイブ文書はまた、「次のアーカイブ」リンク関係を持つべきである（SHOULD）。
Archive documents SHOULD indicate their associated subscription documents using the "current" link relation.
アーカイブ文書は、「現在」のリンク関係を使用してそれに関連するサブスクリプション文書を示すべきです。
Archive documents SHOULD also contain an fh:archive element in their head sections to indicate that they are archives. fh:archive is an empty element; this specification does not define any content for it.
彼らはアーカイブであることを示すために、彼らの頭のセクションでアーカイブ要素：アーカイブ文書はまた、FHを含むべきです。 FH：アーカイブは空の要素です。この仕様は、それのために任意のコンテンツを定義していません。
Example: Atom-formatted Subscription Document
例：Atomのフォーマットのサブスクリプションのドキュメント
<?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> <title>Example Feed</title> <link href="http://example.org/"/> <link rel="self" href="http://example.org/index.atom"/> <link rel="prev-archive" href="http://example.org/2003/11/index.atom"/> <updated>2003-12-13T18:30:02Z</updated> <author> <name>John Doe</name> </author> <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id> <entry> <title>Atom-Powered Robots Run Amok</title> <link href="http://example.org/2003/12/13/atom03"/> <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> <updated>2003-12-13T18:30:02Z</updated> <summary>Some text.</summary> </entry> </feed>
<？xml version = "1.0" エンコード= "UTF-8"？> <フィードのxmlns = "http://www.w3.org/2005/Atom"> <タイトル>例フィード</タイトル> <リンクHREF = "http://example.org/" /> <リンクのrel = "自己" のhref = "http://example.org/index.atom" /> <リンクのrel = "前のアーカイブ" のhref = "のhttp： //example.org/2003/11/index.atom "/> <更新> 2003-12-13T18：30：02Z </更新> <著者> <名前>ジョン・ドウ</名前> </著者> <ID > URN：UUID：60a76c80-d399-11d9-b93C-0003939e0af6 </ ID> <entry>の<タイトル>原子-Poweredのロボットラン逆上</ TITLE> <リンクのhref = "http://example.org/2003/12 / 13 / atom03" /> <ID> URN：UUID：1225c695-cfb8-4ebb-AAAA-80da344efa6a </ ID> <更新> 2003-12-13T18：30：02Z </更新> <概要>一部のテキスト< /要約> </ entry>の</フィード>
Example: Atom-formatted Archive Document
例：アトム形式のアーカイブドキュメント
<?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom" xmlns:fh="http://purl.org/syndication/history/1.0"> <title>Example Feed</title> <link rel="current" href="http://example.org/index.atom"/> <link rel="self" href="http://example.org/2003/11/index.atom"/> <fh:archive/> <link rel="prev-archive" href="http://example.org/2003/10/index.atom"/> <updated>2003-11-24T12:00:00Z</updated> <author> <name>John Doe</name> </author> <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id> <entry> <title>Atom-Powered Robots Scheduled To Run Amok</title> <link href="http://example.org/2003/11/24/robots_coming"/> <id>urn:uuid:cdef5c6d5-gff8-4ebb-assa-80dwe44efkjo</id> <updated>2003-11-24T12:00:00Z</updated> <summary>Some text from an old, different entry.</summary> </entry> </feed>
<？xml version = "1.0" エンコード= "UTF-8"？> <フィードのxmlns = "http://www.w3.org/2005/Atom" のxmlns：FH = "http://purl.org/syndication /history/1.0 "> <タイトル>の例は、フィード</ TITLE> <リンクのrel =" 現在 "のhref = "http://example.org/index.atom"/> <リンクのrel = "自己" のhref =" HTTP ：//example.org/2003/11/index.atom "/> <FH：アーカイブ/> <リンクのrel =" 前のアーカイブ "のhref =" http://example.org/2003/10/index.atom 「/> <更新> 2003-11-24T12：00：00Z </更新> <著者> <名前>ジョン・ドウ</名前> </著者> <id>の壷：UUID：60a76c80-d399-11d9-b93C- </ TITLE> <リンクのhref = "http://example.org/2003/11/24/robots_coming" /> <id>の壷逆上して実行するようにスケジュール0003939e0af6 </ ID> <entry>の<タイトル>原子-Poweredのロボット：UUID：cdef5c6d5-gff8-4ebb-ASSA-80dwe44efkjo </ ID> <更新> 2003-11-24T12：00：00Z </更新> <概要>古い、別のエントリからいくつかのテキスト</要約> </エントリ> </フィード>
In this example, the feed archives are split into monthly chunks, and the subscription document points to the most recent complete archive "http://example.org/2003/11/index.atom" using the "prev-archive" relation. That document, in turn points to the previous archive "http://example.org/2003/10/index.atom", and so on. Note that the "2003/11" archive does not have a "next-archive" relation, because it is the most recent complete archive; although another archive ("2003/12") may be under construction, it would be an error to link to it before completion.
この例では、フィードアーカイブは毎月のチャンクに分割され、「PREV-アーカイブ」関係を使用して、最新の完全なアーカイブ「http://example.org/2003/11/index.atom」へのサブスクリプションの文書を指します。その前のアーカイブ「http://example.org/2003/10/index.atom」、とにターンポイントでそのドキュメント、。それは、最新の完全なアーカイブであるため、「2003/11」のアーカイブは、「次のアーカイブ」関係を持っていないことに注意してください。別のアーカイブ（「2003/12」）が建設中であってもよいが、それは誤りが完了する前にそれにリンクすることです。
The requirement that archive documents be stable allows clients to safely assume that if they have retrieved one in the past, it will not meaningfully change in the future. As a result, if an archive document's contents are changed, some clients may not become aware of the changes.
アーカイブ文書は安定していることが要件は、クライアントが安全に、彼らは過去に1を取得した場合、それは意味のある将来的に変更されないことを前提とすることができます。アーカイブ文書の内容が変更された場合、結果として、いくつかのクライアントは、変化に気づくかもしれません。
Therefore, if a publisher requires a change to be visible to all users (e.g., correcting factual errors), they should consider publishing the revised entry in the subscription document, in addition to (or instead of) the appropriate archive document. Conversely, unimportant changes (e.g., spelling corrections) might be only effected in archive documents.
パブリッシャが（例えば、事実誤認を訂正）すべてのユーザーに表示されるように変更を必要とする場合したがって、それらは適切なアーカイブドキュメント（またはその代わりに）に加えて、サブスクリプション文書の改訂エントリを公開検討すべきです。逆に、重要でない変化（例えば、スペル修正は）のみアーカイブ文書で行われるかもしれません。
Publishers SHOULD construct their feed documents in such a way as to make duplicate removal unambiguous (see Section 4.2).
出版社は（4.2節を参照）、重複除去を明確にするような方法で自分のフィード文書を構築すべきです。
Publishers are not required to make all archive documents available; they may refuse to serve (e.g., with HTTP status code 403 or 410) or be unable to serve (e.g., with HTTP status code 404) an archive document.
出版社は、すべてのアーカイブ文書を使用可能にする必要はありません。それらは、（HTTPステータスコード403または410を用いて、例えば）機能するように拒否またはアーカイブ文書（HTTPステータスコード404と、例えば）の役割を果たすことができないかもしれません。
Typically, clients will "subscribe" to an archived feed by polling the subscription document for recent changes. If a URI contained in the prev-archive link relation has not been processed in the past, the client can "catch up" with any missed entries by dereferencing it and adding the contained entries to the logical feed. This process should be repeated recursively until the client encounters a prev-archive link relation that has been processed (the end of the archive is indicated by a missing prev-archive link relation) or an error is encountered.
一般的に、クライアントは、最近の変更のポーリングによって、アーカイブフィードを購読文書を「購読」します。前のアーカイブリンク関係に含まれるURIが過去に処理されていない場合、クライアントはそれを逆参照し、論理的なフィードに含まれているエントリを追加することによって、任意の逃したエントリーで「追いつく」ことができます。クライアントが処理された（アーカイブの端が欠けている前のアーカイブのリンク関係で示される）、またはエラーが発生する前のアーカイブリンク関係に遭遇するまで、このプロセスを再帰的に繰り返すべきです。
If duplicate entries are found, clients SHOULD consider only the most recently updated entry to be part of the logical feed. If duplicate entries have the same update time-stamp, or no time-stamps are available, the entry sourced from the most recently updated feed document SHOULD replace all other duplicates of that entry.
重複したエントリが見つかった場合、クライアントは論理的な飼料の一部にのみ、最も最近更新されたエントリを検討すべきです。重複したエントリは、同じ更新タイムスタンプを持っている、あるいは全くタイムスタンプが用意されていない場合は、最も最近更新フィード文書から発信エントリはそのエントリの他のすべての重複を置き換える必要があります。
In Atom-formatted archived feeds, two entries are duplicates if they have the same atom:id element. The update time of an entry is determined by its atom:updated element, and likewise the update time of a feed document is determined by its feed-level atom:updated element.
id要素：彼らは同じ原子を持っている場合のAtom形式のアーカイブされた飼料では、2つのエントリが重複しています。エントリの更新時刻は、その原子によって決定される、更新要素、同様にフィード文書の更新時間は、フィードレベル原子によって決定される、更新要素。
Clients SHOULD warn users when they are not able to reconstruct the entire logical feed (e.g., by alerting the user that an archive document is unavailable, or displaying pseudo-entries that inform the user that some entries may be missing).
彼らは（アーカイブ文書が利用できないことをユーザに警告する、またはいくつかのエントリが失われることがあり、ユーザに知らせる擬似エントリを表示することにより、例えば、）全体の論理フィードを再構築することができない場合、クライアントは、ユーザに警告すべきです。
This specification defines the following new relations that have been added to the Link Relations registry:
この仕様は、リンク関係、レジストリに追加された以下の新しい関係を定義しています。
o Attribute Value: prev-archive o Description: A URI that refers to the immediately preceding archive document. o Expected display characteristics: none o Security considerations: See [RFC5005]
O属性値：PREV-アーカイブO説明：URI直前のアーカイブ文書を指します。 O予想表示特性：セキュリティ上の考慮事項Oなし：参照[RFC5005]
o Attribute Value: next-archive o Description: A URI that refers to the immediately following archive document. o Expected display characteristics: none o Security considerations: See [RFC5005]
O属性値：次のアーカイブO説明：URI直後のアーカイブ文書を参照します。 O予想表示特性：セキュリティ上の考慮事項Oなし：参照[RFC5005]
Additionally, the "previous," "next", and "current" link relations should be updated to refer to this document.
また、「前」「次」、および「現在」のリンク関係は、この文書を参照するために更新する必要があります。
Feeds using this mechanism have the same security considerations as Atom [1]. Encryption and authentication security services can be obtained by encrypting and/or signing the feed, as described in [1], and may also be obtained through channel-based mechanisms (e.g., TLS [6], HTTP authentication [7]) and/or transport (e.g., IPsec [8]).
このメカニズムを使用してアトムと同じセキュリティ上の考慮がフィード[1]。暗号化と認証のセキュリティサービスは、[1]記載のように、暗号化および/または飼料を署名することによって得ることができ、また、チャネルベースのメカニズムを介して取得することができる（例えば、TLS [6]、HTTP認証[7]）および/またはまたは輸送（例えば、IPsecの[8]）。
Feeds using these mechanisms could be crafted in such a way as to cause a client to initiate excessive (or even an unending sequence of) network requests, causing denial of service (either to the client, the target server, and/or intervening networks). Clients can mitigate this risk by requiring user intervention after a certain number of requests, or by limiting requests either according to a hard limit, or with heuristics. Servers can mitigate this risk by denying requests that they consider abusive (e.g., by closing the connection or generating an error).
クライアントがネットワーク要求を過剰に（またはのさえ果てしないシーケンス）を開始させるようサービス拒否を引き起こすように細工することができ、これらのメカニズムを使用してフィード（いずれかのクライアント、ターゲット・サーバー、および/または介在するネットワークへ） 。クライアントは、要求の特定の番号の後に、またはいずれかの要求を制限するハードリミットに応じてによって、または経験則でユーザーの介入を必要とすることにより、このリスクを軽減することができます。サーバーは、彼らが（接続を閉じるか、エラーを生成することによって、例えば）虐待を検討要求を拒否することによって、このリスクを軽減することができます。
Clients should be mindful of resource limits when storing feed documents. To reiterate, they are not required to always store or reconstruct the feed when conforming to this specification; they only need to inform the user when the reconstructed feed is not complete.
フィード文書を格納する際にクライアントがリソース制限に留意する必要があります。繰り返しに、彼らはこの仕様に準拠したときに、必ず保存したり、フィードを再構築する必要はありません。彼らは再構築されたフィードが完了していないときにユーザーに通知する必要があります。
This specification does not define what it means when a logical feed's component feed documents have different security mechanisms applied.
この仕様は、論理的なフィードの部品供給の文書が適用されるさまざまなセキュリティメカニズムを持っている場合、それが何を意味するのか定義していません。
[1] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, December 2005.
[1]ノッティンガム、M.、エド。そして、R.セイヤー、エド。、 "Atom配信フォーマット"、RFC 4287、2005年12月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", World Wide Web Consortium First Edition REC-xml-names-19990114, January 1999, <http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[3]ブレイ、T.、オランダ、D.、およびA.素人、 "XMLで名前空間"、ワールドワイドウェブコンソーシアム初版REC-XML-名-19990114、1999年1月、<のhttp：//www.w3。 ORG / TR / 1999 / REC-XML-名-19990114>。
[4] Tobin, R. and J. Cowan, "XML Information Set (Second Edition)", World Wide Web Consortium Recommendation REC-xml-infoset-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-infoset-20040204>.
[4]トービン、R.とJ.コーワン、 "XML情報セット（第二版）"、World Wide Web Consortium（W3C）の勧告REC-XML-インフォセット-20040204、2004年2月、<http://www.w3.org/TR / 2004 / REC-XML-インフォセット-20040204>。
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[5]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[6]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[7] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[7]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証" 、RFC 2617、1999年6月。
[8] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[8]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[9] Winer, D., "RSS 2.0 Specification", 2005, <http://www.rssboard.org/rss-specification>.
[9]ワイナー、D.、 "RSS 2.0仕様"、2005年<http://www.rssboard.org/rss-specification>。
Appendix A. Acknowledgements
付録A.謝辞
The author would like to thank the following people for their contributions, comments, and help: Danny Ayers, Thomas Broyer, Lisa Dusseault, Stefan Eissing, David Hall, Bill de Hora, Vidya Narayanan, Aristotle Pagaltzis, John Panzer, Dave Pawson, Garrett Rooney, Robert Sayre, James Snell, Henry Story, and Franklin Tse.
作者は彼らの貢献、コメント、およびヘルプは以下の方々に感謝したいと思います：ダニー・エアーズ、トーマスBroyer、リサDusseault、ステファンEissing、デビッド・ホール、ビル・デ・ホラ、Vidyaナラヤナン、アリストテレスPagaltzis、ジョン・パンツァー、デイブ・ポーソン、ギャレットルーニー、ロバート・セイヤー、ジェームス・スネル、ヘンリー・ストーリー、フランクリン・ツェ。
Any errors herein remain the author's, not theirs.
すべてのエラーは、ここに著者の、彼らはないまま。
Appendix B. Use in RSS 2.0
RSS 2.0の付録B.使用
As previously noted, while this specification's extensions are described in terms of the Atom feed format, they are also useful in similar formats. This informative appendix demonstrates how they can be used in an RSS 2.0-formatted [9] feed.
先に述べたように、本明細書の拡張はAtomフィード・フォーマットに関して説明されている間、彼らはまた、同様の形式で有用です。この有益な付録では、それらはRSS 2.0形式[9]飼料に使用することができる方法を示しています。
In RSS 2.0-formatted feeds, two entries are duplicates if they have the same guid element. The update time of an entry is not defined by RSS 2.0, but the feed-level update time can be determined by the lastBuildDate element, if present.
彼らは同じGUIDの要素を持っている場合はRSS 2.0形式のフィードでは、2つのエントリが重複しています。エントリの更新時刻はRSS 2.0によって定義されていないが、存在する場合、フィードレベルの更新時間は、lastBuildDate要素によって決定することができます。
RSS 2.0-formatted Complete Feed
RSS 2.0形式の完全飼料
<?xml version="1.0"?> <rss version="2.0" xmlns:fh="http://purl.org/syndication/history/1.0"> <channel> <title>NetMovies Queue</title> <link>http://netmovies.example.org/</link> <description>The DVDs you'll receive next.</description> <fh:complete/> <item> <title>Casablanca</title> <link>http://netmovies.example.org/movies/Casablanca</link> <description>Here's looking at you, kid... </description> <pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate> <guid isPermaLink="false" >urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</guid> </item> </channel> </rss>
<？xmlのバージョンは、= "1.0"> <RSSバージョン= "2.0" のxmlns：FH = "http://purl.org/syndication/history/1.0"> <チャンネル> <タイトル> NetMoviesキュー</ TITLE> <リンク> http://netmovies.example.org/ </ link>の<説明>あなたは次の届きのDVD </記述> <FH：完全な/> <item>の<タイトル>カサブランカ</ TITLE> <リンク> http://netmovies.example.org/movies/Casablanca </ link>の<説明>ここで見ている、子供... </記述> <pubDateの>火、2003年6月3日午前九時39分21秒GMT </ pubDateの> <GUID isPermaLink = "偽"> URN：UUID：1225c695-cfb8-4ebb-AAAA-80da344efa6a </ GUID> </商品> </チャネル> </ RSS>
RSS 2.0-formatted Paged Feed
RSS 2.0形式のページ送り
<?xml version="1.0"?> <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> <channel> <title>Liftoff News</title> <link>http://liftoff.example.net/</link> <description>Liftoff to Space Exploration.</description> <atom:link rel="next" href="http://liftof.example.net/index.rss?page=2"/> <item> <title>Star City</title> <link>http://liftoff.example.net/2003/06/news-starcity</link> <description>How do Americans get ready to work with Russians aboard the International Space Station? They take a crash course in culture, language and protocol at Russia's Star City. </description> <pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate> <guid>http://liftoff.example.net/2003/06/03/starcity</guid> </item> </channel> </rss>
<？xmlのバージョン= "1.0"> <RSSバージョン= "2.0" のxmlns：アトム= "http://www.w3.org/2005/Atom"> <チャンネル> <タイトル>リフトオフニュース</ TITLE> <宇宙探査へのリンク> http://liftoff.example.net/ </ link>の<説明>リフトオフ</記述> <アトム：リンクのrel = "次" のhref = "http://liftof.example.net/ index.rss？ページ= 2" /> <item>の<タイトル>スターシティ</ TITLE> <リンク> http://liftoff.example.net/2003/06/news-starcity </ link>の<説明>どのようにアメリカ人は国際宇宙ステーションに乗ってロシアと協力する準備ができて得るのですか？彼らは、ロシアのスターシティの文化、言語やプロトコルでクラッシュコースを取ります。 </記述> <pubDateの>火、2003年6月3日午前9時39分21秒GMT </ pubDateの> <GUID> http://liftoff.example.net/2003/06/03/starcity </ GUID> </ item>の</チャンネル> </ RSS>
RSS 2.0-formatted Subscription Document
RSS 2.0形式のサブスクリプションのドキュメント
<?xml version="1.0"?> <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> <channel> <title>Liftoff News</title> <link>http://liftoff.example.net/</link> <description>Liftoff to Space Exploration.</description> <atom:link rel="prev-archive" href="http://liftoff.example.net/2003/05/index.rss"/>
<？xmlのバージョン= "1.0"> <RSSバージョン= "2.0" のxmlns：アトム= "http://www.w3.org/2005/Atom"> <チャンネル> <タイトル>リフトオフニュース</ TITLE> <宇宙探査へのリンク> http://liftoff.example.net/ </ link>の<説明>リフトオフ</記述> <アトム：リンクのrel = "前のアーカイブ" のhref = "のhttp：//liftoff.example。ネット/ 2003/05 / index.rss "/>
<item> <title>Star City</title> <link>http://liftoff.example.net/2003/06/news-starcity</link> <description>How do Americans get ready to work with Russians aboard the International Space Station? They take a crash course in culture, language and protocol at Russia's Star City. </description> <pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate> <guid>http://liftoff.example.net/2003/06/03/starcity</guid> </item> </channel> </rss>
<項目> <タイトル>スターシティ</ TITLE> <リンク> http://liftoff.example.net/2003/06/news-starcity </ link>の<説明>アメリカ人が乗ってロシアと協力する準備ができて取得するにはどうすればよいです国際宇宙ステーション？彼らは、ロシアのスターシティの文化、言語やプロトコルでクラッシュコースを取ります。 </記述> <pubDateの>火、2003年6月3日午前9時39分21秒GMT </ pubDateの> <GUID> http://liftoff.example.net/2003/06/03/starcity </ GUID> </ item>の</チャンネル> </ RSS>
RSS 2.0-formatted Archive Document
RSS 2.0形式のアーカイブドキュメント
<?xml version="1.0"?> <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:fh="http://purl.org/syndication/history/1.0"> <channel> <title>Liftoff News</title> <link>http://liftoff.example.net/</link> <description>Liftoff to Space Exploration.</description> <lastBuildDate>Fri, 30 May 2003 11:06:42 GMT</lastBuildDate> <fh:archive/> <atom:link rel="current" href="http://liftoff.example.net/index.rss"/> <atom:link rel="prev-archive" href="http://liftoff.example.net/2003/04/index.rss"/>
<？xmlのバージョン= "1.0"> <RSSバージョン= "2.0" のxmlns：アトム= "http://www.w3.org/2005/Atom" のxmlns：FH = "http://purl.org/syndication宇宙探査へ/history/1.0" > <チャンネル> <タイトル>リフトオフニュース</ TITLE> <リンク> http://liftoff.example.net/ </ link>の<説明>リフトオフ。</記述> <lastBuildDate>金、2003年5月30日11時06分42秒GMT </ lastBuildDate> <FH：アーカイブ/> <アトム：リンクのrel = "現在" のhref = "http://liftoff.example.net/index.rss" /> <アトム：リンクのrel = "前のアーカイブ" のhref = "http://liftoff.example.net/2003/04/index.rss" />
<item> <title>Upcoming Eclipse</title> <link>http://liftoff.example.net/2003/05/30/eclipse</link> <description>Sky watchers in Europe, Asia, and parts of Alaska and Canada will experience a partial eclipse of the Sun on Saturday, May 31st.</description> <pubDate>Fri, 30 May 2003 11:06:42 GMT</pubDate> <guid>http://liftoff.example.net/2003/05/30/eclipse</guid> </item> <item> <title>The Engine That Does More</title> <link>http://liftoff.example.net/2003/05/27/vasmir</link> <description>Before man travels to Mars, NASA hopes to design new engines that will let us fly through the Solar System more quickly. The proposed VASIMR engine would do that.</description> <pubDate>Tue, 27 May 2003 08:37:32 GMT</pubDate> <guid>http://liftoff.example.net/2003/05/27/vasmir</guid> </item> </channel> </rss>
<項目> <タイトル>今後のEclipseの</ TITLE> <リンク> http://liftoff.example.net/2003/05/30/eclipse </ link>の<説明>ヨーロッパ、アジア、およびアラスカの部分でスカイウォッチャーそしてカナダは土曜日、5月31日に日の部分日食を体験します。</記述> <pubDateの>金、2003年5月30日11時06分42秒GMT </ pubDateの> <GUID> http://liftoff.example.net / 2003/5月30日/日食</ GUID> </ item>の<item>の<タイトル>その他</ TITLE> <リンク>いエンジンhttp://liftoff.example.net/2003/05/27/ vasmir </ link>の<説明>男は火星に移動する前に、NASAは、私たちはより迅速にソーラーシステムを飛ぶようになる新しいエンジンを設計したいと考えています。提案VASIMRエンジンはそれを行うだろう。</記述> <pubDateの>火、2003年5月27日8時37分32秒GMT </ pubDateの> <GUID> http://liftoff.example.net/2003/05/27/vasmir </ GUID> </商品> </チャネル> </ RSS>
Author's Address
著者のアドレス
Mark Nottingham
マーク・ノッティンガム
EMail: mnot@pobox.com URI: http://www.mnot.net/
電子メール：mnot@pobox.com URI：http://www.mnot.net/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。