Network Working Group M. Nottingham Request for Comments: 5005 September 2007 Category: Standards Track
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提要,它们支持跨一个或多个提要文档发布条目。这包括用于逐段访问的“分页”提要、“允许重构提要内容的存档”提要,以及明确“完整”的提要。
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
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.
本规范正式定义了两种类型的提要,它们可以跨越一个或多个提要文档;“分页”源和“存档”源。此外,它还定义了“完整”提要,以涵盖单个提要文档显式表示所有提要条目的情况。
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.
尽管它们规范地引用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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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"
"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.
“Head section”是指文档的提要范围的元数据容器;e、 例如,atom提要文档中atom:feed元素的子元素。
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]中的术语。然而,本规范使用速记;命名元素信息项时省略短语“信息项”。因此,当本规范使用术语“元素”时,它指的是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链接关系来标识不同类型的链接;有关其语法的信息,请参见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节所述。
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.
例如,表示随时间变化的排名的提要(例如“前二十条记录”或“最受欢迎的项目”)不应在旧条目旁边显示新条目。通过将此提要标记为完成,刷新时将丢弃旧条目。
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:complete元素出现在提要的头部分时,表示它出现在其中的提要文档是逻辑提要条目的完整表示。它是一个空元素;本规范没有为其定义任何内容。
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" 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 “previous”-引用一系列文档中紧靠前的文档的URI。
o "next" - A URI that refers to the immediately following document in a series of documents.
o “next”-一个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" 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.
订阅文档和存档文档必须具有“prev archive”链接关系,除非之前没有可用的存档。存档文档还应具有“下一个存档”链接关系,除非没有以下可用存档。
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:Archive元素,以表明它们是归档文件。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" 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格式的归档文档
<?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" 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.
在本例中,提要存档被分为每月一次的区块,订阅文档指向最新的完整存档”http://example.org/2003/11/index.atom使用“prev archive”关系。该文件反过来指向以前的档案”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.
归档文档保持稳定的要求允许客户安全地假设,如果他们过去检索过一个文档,那么将来它将不会发生有意义的更改。因此,如果存档文档的内容发生更改,某些客户端可能不会意识到这些更改。
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.
通常,客户机将通过轮询订阅文档以获取最近的更改来“订阅”存档提要。如果以前未处理prev archive链接关系中包含的URI,则客户端可以通过取消引用并将包含的条目添加到逻辑提要来“跟踪”丢失的条目。应递归重复此过程,直到客户端遇到已处理的prev archive链接关系(存档的结尾由缺少的prev archive链接关系指示)或遇到错误。
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格式的存档提要中,如果两个条目具有相同的Atom:id元素,则它们是重复的。条目的更新时间由其atom:updated元素决定,同样,提要文档的更新时间由其提要级别的atom:updated元素决定。
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 Description:引用前一个归档文档的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 属性值:next archive o Description:引用紧跟其后的归档文档的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.,Ed.和R.Sayre,Ed.,“原子联合格式”,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中的名称空间”,万维网联盟第一版REC-XML-names-19990114,1999年1月<http://www.w3.org/TR/1999/REC-xml-names-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] Tobin,R.和J.Cowan,“XML信息集(第二版)”,万维网联盟建议REC-XML-infoset-200402042004年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):通用语法”,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,“传输层安全(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.,Lootonen,A.,和L.Stewart,“HTTP认证:基本和摘要访问认证”,RFC 26171999年6月。
[8] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[8] Kent,S.和K.Seo,“互联网协议的安全架构”,RFC 43012005年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-specification>.
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.
作者要感谢以下人士的贡献、评论和帮助:丹尼·艾尔斯、托马斯·布罗耶、丽莎·杜肖奥、斯蒂芬·艾辛、大卫·霍尔、比尔·德霍拉、维迪亚·纳拉亚南、亚里士多德·帕格尔茨、约翰·潘泽、戴夫·帕森、加勒特·鲁尼、罗伯特·赛尔、詹姆斯·斯内尔、亨利·斯托里和富兰克林·谢。
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提要格式描述的,但它们在类似格式中也很有用。本资料性附录演示了如何在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元素,则它们是重复的。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 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
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 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"/>
<?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>
<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
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 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>
<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/
EMail: 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.
本文件及其包含的信息以“原样”为基础提供,贡献者、他/她所代表或赞助的组织(如有)、互联网协会、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秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/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的IETF-ipr@ietf.org.