[要約] RFC 5005は、フィードのページングとアーカイブに関する仕様であり、フィードの長期保存と効率的なアクセスを目的としています。
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".
この仕様では、1つ以上のフィードドキュメント間でエントリの公開を可能にする3種類のシンジケートWebフィードを定義します。これには、断片的なアクセスのための「ページ」フィード、「フィードの内容の再構築を可能にする「アーカイブ」フィード、および明示的に「完全」のフィードが含まれます。
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.
この仕様は、1つ以上のフィードドキュメントにまたがる可能性のある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 完全なフィードには、1つのドキュメントにエントリのセット全体が含まれており、以前に見られるエントリを「覚える」ことが望ましくない場合に役立ちます。
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.
それらは基準的にAtomを指しますが、ここで説明するメカニズムは同様のシンジケーション形式で使用できます。そのような使用については、付録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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
この仕様では、「フィードドキュメント」とは、原子飼料ドキュメントまたは同様のシンジケーションインスタンスドキュメントを指します。任意の数のエントリが含まれている場合があり、論理フィードの完全な表現である場合とそうでない場合があります。
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.
「ヘッドセクション」とは、ドキュメントのフィード全体のメタデータコンテナを指します。たとえば、原子の子要素：原子フィードドキュメントの供給要素。
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 Infoset [4]の用語を使用しています。ただし、この仕様では速記を使用しています。要素情報項目を命名すると、「情報項目」というフレーズは省略されています。したがって、この仕様が「要素」という用語を使用する場合、InfoSetの用語で要素情報項目を指します。
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 Link関係も使用して、さまざまな種類のリンクを識別します。構文については、Atom Specification [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で説明されているように、それらを絶対にしなければならないことに注意してください。
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 Formatted Complete Feed
<?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>
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 「First」 - 一連のドキュメントで最も先行する文書を指すURI。
o "last" - A URI that refers to the furthest following document in a series of documents.
o 「last」 - 一連のドキュメントで最も遠い次のドキュメントを指す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.
Paged Feed Documentsには、これらのリンク関係の少なくとも1つが存在する必要があり、実用的で適用可能な限り多くを含める必要があります。
Example: Atom-formatted Paged Feed
例：Atom Formatted Paged Feed
<?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>
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 -archive」 - 直前のアーカイブドキュメントを指す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.
サブスクリプションドキュメントとアーカイブドキュメントには、先行するアーカイブが利用できない場合を除き、「前の」リンク関係が必要です。アーカイブドキュメントには、以下のアーカイブが利用できない場合を除き、「次のアーティブ」リンク関係も必要です。
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-Formattedサブスクリプションドキュメント
<?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>
Example: Atom-formatted Archive Document
例：Atom Formatted Archiveドキュメント
<?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> 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.
<？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>例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> <turity> john doe </name> </author> <id> urn：uuid：60a76c80-d399-11d9-b93c-0003939E0AF6 </id> <entry> <title> amokを実行する予定の原子駆動ロボット</title> <link href = "http://example.org/2003/11/24/robots_ comping"/> <id> urn：uuid：cdef5c6d5-gff8-4ebb-assa-80dwe444444444444444t12：00：00z </updated> <summary>古いエントリからのいくつかのテキスト。</summary> </エントリ> </feed>この例では、フィードアーカイブは毎月のチャンクに分割され、サブスクリプションドキュメントは最新の完全なアーカイブ「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.
Atom Formattedアーカイブされたフィードでは、同じ原子：ID要素がある場合、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-archive 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]).
このメカニズムを使用したフィードには、Atomと同じセキュリティ上の考慮事項があります[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。、編and R. Sayre、ed。、「The Atom Syndication Format」、RFC 4287、2005年12月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Bray、T.、Hollander、D。、およびA. Layman、「XMLの名前空間」、World Wide Web Consortium First Edition Rec-XML-Names-19990114、<http://www.w3.org/tr/1999/rec-xml-names-1990114>。
[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] Tobin、R。and J. Cowan、「XML Information Set（第2版）」、World Wide Web Consortiumの推奨REC-XML-INFOSET-20040204、2004年2月、<http://www.w3.org/tr/2004/rec-xml-infoset-20040204>。
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[5] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[8] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[8] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[9] Winer, D., "RSS 2.0 Specification", 2005, <http://www.rssboard.org/rss-specification>.
[9] Winer、D。、「RSS 2.0仕様」、2005、<http://www.rssboard.org/rss-pecification>。
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.
著者は、Danny Ayers、Thomas Broyer、Lisa Dusseault、Stefan Eissing、David Hall、Bill de Hora、Vidya Narayanan、Aristotle Pagaltzis、John Panzer、Dave Pawson、Garettttttttttttusルーニー、ロバート・セイヤー、ジェームズ・スネル、ヘンリー・ストーリー、フランクリン・TSE。
Any errors herein remain the author's, not theirs.
ここのエラーは、著者ではなく著者のものであり続けます。
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 Feed形式の観点から説明されていますが、同様の形式でも役立ちます。この有益な付録は、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.
RSS 2.0形式のフィードでは、同じGUID要素がある場合、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>
RSS 2.0-formatted Paged Feed
<?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>
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"/>
<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>
RSS 2.0-formatted Archive Document
<?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"/>
<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>
Author's Address
著者の連絡先
Mark Nottingham
マークノッティンガム
EMail: mnot@pobox.com
URI: http://www.mnot.net/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。