RFC 4685: Atom Threading Extensions 中文翻译

URL : https://datatracker.ietf.org/doc/html/rfc4685
标题 : RFC 4685
翻译类型 : 自动生成

Network Working Group                                           J. Snell
Request for Comments: 4685                                September 2006
Category: Standards Track

Network Working Group                                           J. Snell
Request for Comments: 4685                                September 2006
Category: Standards Track

Atom Threading Extensions

Atom线程扩展

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 memo presents a mechanism that allows feeds publishers to express threaded discussions within the Atom Syndication Format.

此备忘录提供了一种机制，允许提要发布者在Atom联合格式中表达线程化讨论。

Table of Contents

   1. Introduction ....................................................1
   2. Notational Conventions ..........................................2
   3. The 'in-reply-to' Extension Element .............................2
   4. The 'replies' Link Relation .....................................5
   5. The 'total' Extension Element ...................................6
   6. Considerations for Using thr:count, thr:updated, and total ......7
   7. Security Considerations .........................................8
   8. IANA Considerations .............................................9
   9. References ......................................................9
      9.1. Normative References .......................................9
      9.2. Informative References ....................................10
   Appendix A.  Acknowledgements .....................................11

   1. Introduction ....................................................1
   2. Notational Conventions ..........................................2
   3. The 'in-reply-to' Extension Element .............................2
   4. The 'replies' Link Relation .....................................5
   5. The 'total' Extension Element ...................................6
   6. Considerations for Using thr:count, thr:updated, and total ......7
   7. Security Considerations .........................................8
   8. IANA Considerations .............................................9
   9. References ......................................................9
      9.1. Normative References .......................................9
      9.2. Informative References ....................................10
   Appendix A.  Acknowledgements .....................................11

1. Introduction

1. 介绍

This document defines an extension for expressing threaded discussions within the Atom Syndication Format [RFC4287].

本文档定义了一个扩展，用于在Atom联合格式[RFC4287]中表示线程化讨论。

2. Notational Conventions

2. 符号约定

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119], as scoped to those conformance targets.

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、[RFC2119]中的描述进行解释，并适用于这些合规性目标。

   The XML Namespaces URI [W3C.REC-xml-names-19990114] for the XML
   elements and attributes described in this specification is:
   http://purl.org/syndication/thread/1.0

   The XML Namespaces URI [W3C.REC-xml-names-19990114] for the XML
   elements and attributes described in this specification is:
   http://purl.org/syndication/thread/1.0

In this document, the namespace prefix "thr:" is used for the above Namespace URI. Note that the choice of namespace prefix is arbitrary and not semantically significant.

在本文档中，名称空间前缀“thr:”用于上述名称空间URI。请注意，名称空间前缀的选择是任意的，在语义上并不重要。

This specification uses a shorthand form of terms from the XML Infoset [W3C.REC-xml-infoset-20040204]. The phrase "Information Item" is omitted when naming Element and Attribute Information Items. Therefore, when this specification uses the term "element," it is referring to an Element Information Item in Infoset terms. Likewise, when this specification uses the term "attribute," it is referring to an Attribute Information Item.

本规范使用XML信息集[W3C.REC-XML-Infoset-20040204]中术语的简写形式。命名元素和属性信息项时省略短语“信息项”。因此，当本规范使用术语“元素”时，它指的是Infoset术语中的元素信息项。同样，当本规范使用术语“属性”时，它指的是属性信息项。

This specification allows the use of IRIs [RFC3987]. Every URI [RFC3986] is also an IRI, so a URI may be used wherever an IRI is named. When an IRI that is not also a URI is given for dereferencing, it MUST be mapped to a URI using the steps in Section 3.1 of [RFC3987]. When an IRI is serving as an identifier, it MUST NOT be so mapped.

本规范允许使用IRIs[RFC3987]。每个URI[RFC3986]也是一个IRI，因此可以在命名IRI的任何地方使用URI。当为解引用而给出的IRI不是URI时，必须使用[RFC3987]第3.1节中的步骤将其映射到URI。当IRI用作标识符时，不得将其映射。

Some sections of this specification are illustrated with a non-normative RELAX NG Compact schema [RELAXNG]. In those sections, this specification uses the atomCommonAttributes, atomMediaType, and atomURI patterns, defined in [RFC4287].

本规范的某些部分用非标准RELAXNG紧凑模式[RELAXNG]进行了说明。在这些章节中，本规范使用了[RFC4287]中定义的AtomCommonatAttributes、atomMediaType和atomURI模式。

However, the text of this specification provides the sole definition of conformance.

然而，本规范的文本提供了一致性的唯一定义。

3. The 'in-reply-to' Extension Element

3. 扩展名中的“reply to”元素

The "in-reply-to" element is used to indicate that an entry is a response to another resource. The element MUST contain a "ref" attribute identifying the resource that is being responded to.

“in reply to”元素用于指示条目是对另一资源的响应。元素必须包含一个“ref”属性，该属性标识正在响应的资源。

The element is not unlike the references and in-reply-to email message headers, defined by [RFC2822]. However, unlike the in-reply-to header, the "in-reply-to" element is required to identify the unique identifier of only a single parent resource. If the entry

该元素与[RFC2822]定义的引用和回复电子邮件消息头没有什么不同。但是，与in-reply-to头不同，“in-reply-to”元素只需要标识单个父资源的唯一标识符。如果输入

is a response to multiple resources, additional "in-reply-to" elements MAY be used. There is no direct equivalent to the references header, which lists the unique identifiers of each preceding message in a thread.

是对多个资源的响应，可以使用附加的“回复”元素。没有直接等价于references头的东西，它列出了线程中每个前面消息的唯一标识符。

   in-reply-to =
     element thr:in-reply-to {
       atomCommonAttributes,
       ref,
       href?,
       source?,
       type?,
       ( undefinedContent )
     }

   in-reply-to =
     element thr:in-reply-to {
       atomCommonAttributes,
       ref,
       href?,
       source?,
       type?,
       ( undefinedContent )
     }

   ref = attribute ref { atomURI }
   href = attribute href { atomURI }
   type = attribute type { atomMediaType }
   source = attribute source { atomURI }

   ref = attribute ref { atomURI }
   href = attribute href { atomURI }
   type = attribute type { atomMediaType }
   source = attribute source { atomURI }

The "ref" attribute specifies the persistent, universally unique identifier of the resource being responded to. The value MUST conform to the same construction and comparison rules as the value of the atom:id element, as defined in Section 4.2.6 of [RFC4287]. Though the IRI might use a dereferenceable scheme, processors MUST NOT assume that it can be dereferenced.

“ref”属性指定要响应的资源的持久的、通用的唯一标识符。该值必须符合与[RFC4287]第4.2.6节中定义的atom:id元素值相同的构造和比较规则。尽管IRI可能使用可解引用的方案，但处理器不能假设它可以被解引用。

If the resource being responded to does not have a persistent, universally unique identifier, the publisher MUST assign an identifier that satisfies all the considerations in Section 4.2.6 of [RFC4287] for use as the value of the "ref" attribute. In that case, if a representation of the resource can be retrieved from an IRI that can be used as a valid atom:id value, then this IRI SHOULD be used as the value of both the "ref" and "href" attributes.

如果响应的资源没有持久的、通用唯一的标识符，则发布者必须分配一个满足[RFC4287]第4.2.6节中所有注意事项的标识符，以用作“ref”属性的值。在这种情况下，如果可以从可用作有效atom:id值的IRI中检索资源的表示，则该IRI应同时用作“ref”和“href”属性的值。

The "source" attribute MAY be used to specify the IRI [RFC3987] of an Atom Feed or Entry Document containing an atom:entry with an atom:id value equal to the value of the "ref" attribute. The IRI specified, once appropriately mapped to a corresponding URI, MUST be dereferenceable.

“source”属性可用于指定包含Atom:Entry且Atom:id值等于“ref”属性值的Atom提要或条目文档的IRI[RFC3987]。指定的IRI一旦正确映射到相应的URI，就必须是可取消引用的。

The "href" attribute specifies an IRI that may be used to retrieve a representation of the resource being responded to. The IRI specified, once appropriately mapped to a corresponding URI, MUST be dereferenceable.

“href”属性指定可用于检索所响应资源的表示形式的IRI。指定的IRI一旦正确映射到相应的URI，就必须是可取消引用的。

The "type" attribute MAY be used to provide a hint to the client about the media type [RFC4288] of the resource identified by the "href" attribute. The "type" attribute is only meaningful if a corresponding "href" attribute is also provided.

“type”属性可用于向客户端提供关于由“href”属性标识的资源的媒体类型[RFC4288]的提示。“type”属性只有在还提供了相应的“href”属性时才有意义。

This specification assigns no significance to the order in which multiple "in-reply-to" elements appear within an entry.

本规范对条目中出现多个“回复”元素的顺序不赋予任何意义。

An example of an entry with a response follows:

带有响应的条目示例如下所示：

   <feed xmlns="http://www.w3.org/2005/Atom"
         xmlns:thr="http://purl.org/syndication/thread/1.0">
     <id>http://www.example.org/myfeed</id>
     <title>My Example Feed</title>
     <updated>2005-07-28T12:00:00Z</updated>
     <link href="http://www.example.org/myfeed" />
     <author><name>James</name></author>
     <entry>
       <id>tag:example.org,2005:1</id>
       <title>My original entry</title>
       <updated>2006-03-01T12:12:12Z</updated>
       <link
         type="application/xhtml+xml"
         href="http://www.example.org/entries/1" />
       <summary>This is my original entry</summary>
     </entry>
     <entry>
       <id>tag:example.org,2005:1,1</id>
       <title>A response to the original</title>
       <updated>2006-03-01T12:12:12Z</updated>
       <link href="http://www.example.org/entries/1/1" />
       <thr:in-reply-to
         ref="tag:example.org,2005:1"
         type="application/xhtml+xml"
         href="http://www.example.org/entries/1"/>
       <summary>This is a response to the original entry</summary>
     </entry>
   </feed>

   <feed xmlns="http://www.w3.org/2005/Atom"
         xmlns:thr="http://purl.org/syndication/thread/1.0">
     <id>http://www.example.org/myfeed</id>
     <title>My Example Feed</title>
     <updated>2005-07-28T12:00:00Z</updated>
     <link href="http://www.example.org/myfeed" />
     <author><name>James</name></author>
     <entry>
       <id>tag:example.org,2005:1</id>
       <title>My original entry</title>
       <updated>2006-03-01T12:12:12Z</updated>
       <link
         type="application/xhtml+xml"
         href="http://www.example.org/entries/1" />
       <summary>This is my original entry</summary>
     </entry>
     <entry>
       <id>tag:example.org,2005:1,1</id>
       <title>A response to the original</title>
       <updated>2006-03-01T12:12:12Z</updated>
       <link href="http://www.example.org/entries/1/1" />
       <thr:in-reply-to
         ref="tag:example.org,2005:1"
         type="application/xhtml+xml"
         href="http://www.example.org/entries/1"/>
       <summary>This is a response to the original entry</summary>
     </entry>
   </feed>

To allow Atom processors that are not familiar with the in-reply-to extension to know that a relationship exists between the entry and the resource being responded to, publishers are advised to consider including a "related" link referencing a representation of the resource identified by the in-reply-to element. Although such links are unlikely to be processed as a reference to a predecessor in a threaded conversation, they are helpful in at least establishing a semantically meaningful relationship between the linked resources.

为了允许不熟悉Exchange应答的原子处理器知道在条目和被响应的资源之间存在关系，建议出版商考虑包括引用由In答复元素标识的资源的表示的“相关”链接。尽管这样的链接不太可能在线程化对话中作为对前置会话的引用进行处理，但它们至少有助于在链接的资源之间建立语义上有意义的关系。

For example,

例如

   <feed xmlns="http://www.w3.org/2005/Atom"
         xmlns:thr="http://purl.org/syndication/thread/1.0">
     <id>http://www.example.org/myfeed</id>
     <title>My Example Feed</title>
     <updated>2005-07-28T12:00:00Z</updated>
     <link href="http://www.example.org/myfeed" />
     <author><name>James</name></author>
     <entry>
       <id>tag:example.org,2005:1,1</id>
       <title>A response to the original</title>
       <updated>2006-03-01T12:12:12Z</updated>
       <link href="http://www.example.org/entries/1/1" />
       <thr:in-reply-to
         ref="tag:example.org,2005:1,0"
         type="application/xhtml+xml"
         href="http://www.example.org/entries/1"
         source="http://www.example.org/myfeed" />
       <link
         rel="related"
         type="application/xhtml+xml"
         href="http://www.example.org/entries/1" />
       <summary>This is a response to the original entry</summary>
     </entry>
   </feed>

   <feed xmlns="http://www.w3.org/2005/Atom"
         xmlns:thr="http://purl.org/syndication/thread/1.0">
     <id>http://www.example.org/myfeed</id>
     <title>My Example Feed</title>
     <updated>2005-07-28T12:00:00Z</updated>
     <link href="http://www.example.org/myfeed" />
     <author><name>James</name></author>
     <entry>
       <id>tag:example.org,2005:1,1</id>
       <title>A response to the original</title>
       <updated>2006-03-01T12:12:12Z</updated>
       <link href="http://www.example.org/entries/1/1" />
       <thr:in-reply-to
         ref="tag:example.org,2005:1,0"
         type="application/xhtml+xml"
         href="http://www.example.org/entries/1"
         source="http://www.example.org/myfeed" />
       <link
         rel="related"
         type="application/xhtml+xml"
         href="http://www.example.org/entries/1" />
       <summary>This is a response to the original entry</summary>
     </entry>
   </feed>

4. The 'replies' Link Relation

4. “回复”链接关系

An Atom link element with a rel attribute value of "replies" may be used to reference a resource where responses to an entry may be found. If the type attribute of the atom:link is omitted, its value is assumed to be "application/atom+xml".

rel属性值为“repress”的Atom-link元素可用于引用可以找到条目响应的资源。如果省略atom:link的type属性，则假定其值为“application/atom+xml”。

A "replies" link appearing as a child of the Atom feed or source element indicates that the referenced resource likely contains responses to any of that feed's entries. A "replies" link appearing as a child of an Atom entry element indicates that the linked resource likely contains responses specific to that entry.

作为Atom提要或源元素的子元素出现的“replies”链接表示引用的资源可能包含对该提要的任何条目的响应。作为Atom条目元素的子元素出现的“replies”链接表示链接的资源可能包含特定于该条目的响应。

An atom:link element using the "replies" rel attribute value MAY contain a "thr:count" attribute whose value is an unsigned, non-negative integer, conforming to the canonical representation of the XML Schema nonNegativeInteger data type [W3C.REC-xmlschema-2- 20041028], that provides a hint to clients as to the total number of replies contained by the linked resource. The value is advisory and may not accurately reflect the actual number of replies.

使用“repries”rel属性值的atom:link元素可能包含一个“thr:count”属性，该属性的值是一个无符号非负整数，符合XML模式非负整数数据类型[W3C.REC-xmlschema-2-20041028]的规范表示形式，这为客户端提供了链接资源包含的回复总数的提示。该值为建议值，可能无法准确反映实际答复数。

The link MAY also contain a "thr:updated" attribute, whose value is a [RFC3339] date-time stamp conforming to the same construction rules as the Atom Date Construct defined in [RFC4287], and is used to provide a hint to clients as to the date and time of the most recently updated reply contained by the linked resource. The value is advisory and may not accurately reflect the actual date and time of the most recent reply.

该链接还可以包含一个“thr:updated”属性，其值是一个[RFC3339]日期时间戳，符合与[RFC4287]中定义的原子日期构造相同的构造规则，并用于向客户端提供链接资源包含的最近更新的回复的日期和时间的提示。该值为建议值，可能无法准确反映最近回复的实际日期和时间。

For example,

例如

   <feed xmlns="http://www.w3.org/2005/Atom"
         xmlns:thr="http://purl.org/syndication/thread/1.0">
     <id>http://www.example.org/myfeed</id>
     <title>My Example Feed</title>
     <updated>2005-07-28T12:00:00Z</updated>
     <link href="http://www.example.org/myfeed" />
     <author><name>James</name></author>
     <entry>
       <id>tag:entries.com,2005:1</id>
       <title>My original entry</title>
       <updated>2006-03-01T12:12:12Z</updated>
       <link href="http://www.example.org/entries/1" />
       <link rel="replies"
             type="application/atom+xml"
             href="http://www.example.org/mycommentsfeed.xml"
             thr:count="10" thr:updated="2005-07-28T12:10:00Z" />
       <summary>This is my original entry</summary>
     </entry>
   </feed>

   <feed xmlns="http://www.w3.org/2005/Atom"
         xmlns:thr="http://purl.org/syndication/thread/1.0">
     <id>http://www.example.org/myfeed</id>
     <title>My Example Feed</title>
     <updated>2005-07-28T12:00:00Z</updated>
     <link href="http://www.example.org/myfeed" />
     <author><name>James</name></author>
     <entry>
       <id>tag:entries.com,2005:1</id>
       <title>My original entry</title>
       <updated>2006-03-01T12:12:12Z</updated>
       <link href="http://www.example.org/entries/1" />
       <link rel="replies"
             type="application/atom+xml"
             href="http://www.example.org/mycommentsfeed.xml"
             thr:count="10" thr:updated="2005-07-28T12:10:00Z" />
       <summary>This is my original entry</summary>
     </entry>
   </feed>

Although Atom feed, entry, and source elements MAY each contain any number of atom:link elements using the "replies" link relation, this specification assigns no significance to the presence or order of such links. Multiple replies links appearing within an atom:entry may reference alternative representations of the same set of responses or may reference entirely distinct resources containing distinct sets of responses. Processors MUST NOT assume that multiple replies links are referencing different representations of the same resource and MUST process each replies link independently of any others.

尽管Atom提要、条目和源元素都可以包含任意数量的Atom:link元素，使用“回复”链接关系，但本规范对此类链接的存在或顺序没有任何意义。atom中出现的多个回复链接：条目可能引用同一组响应的替代表示，也可能引用包含不同响应集的完全不同的资源。处理器不得假设多个回复链接引用同一资源的不同表示形式，并且必须独立于任何其他链接处理每个回复链接。

5. The 'total' Extension Element

5. “total”扩展元素

The "total" element is used to indicate the total number of unique responses to an entry known to the publisher. Its content MUST be an unsigned non-negative integer value conforming to the canonical representation of the XML Schema nonNegativeInteger data type [W3C.REC-xmlschema-2-20041028].

“total”元素用于指示发布者已知的条目的唯一响应总数。其内容必须是无符号非负整数值，符合XML模式非负整数数据类型的规范表示[W3C.REC-xmlschema-2-20041028]。

      total = element thr:total { xsd:nonNegativeInteger }

      total = element thr:total { xsd:nonNegativeInteger }

Atom entries MAY contain a "total" element but MUST NOT contain more than one.

Atom条目可以包含一个“total”元素，但不能包含多个。

There is no implied relationship between the value of the "total" element of an Atom entry and any individual or aggregate values of the "thr:count" attributes of its Atom link elements having a "replies" relation.

Atom条目的“total”元素的值与其具有“replies”关系的Atom链接元素的“thr:count”属性的任何单个或聚合值之间没有隐含的关系。

6. Considerations for Using thr:count, thr:updated, and total

6. 使用thr:count、thr:updated和total的注意事项

The thr:count, thr:updated, and total extensions provide additional metadata about the thread of discussion associated with an entry. The values are intended to make it easier for feed consumers to display basic contextual information about the thread without requiring that those consumers dereference, parse, and analyze linked resources. That said, there are a number of considerations implementors need to be aware of.

thr:count、thr:updated和total扩展提供了关于与条目关联的讨论线程的附加元数据。这些值旨在使提要使用者更容易显示有关线程的基本上下文信息，而无需这些使用者取消引用、解析和分析链接资源。也就是说，实现者需要注意一些注意事项。

First, these extensions MUST NOT be assumed to provide completely accurate information about the thread of discussion. For instance, the actual total number of responses contained by a linked resource MAY differ from the number specified in the thr:count attribute. Feed publishers SHOULD make an effort to ensure that the values are accurate. The non-authoritative nature of "external reference metadata", like the replies link attributes, is discussed in detail in Section 3.3 of the W3C document "Tag Finding 12: Authoritative Metadata" [TAG12].

首先，不能假设这些扩展提供了关于讨论主题的完全准确的信息。例如，链接资源包含的响应的实际总数可能与thr:count属性中指定的数目不同。提要发布者应该努力确保这些值是准确的。W3C文档“标记查找12：权威元数据”[TAG12]第3.3节详细讨论了“外部参考元数据”的非权威性质，如回复链接属性。

Second, the values of the these extensions are volatile and may change at a faster rate than that of the containing entry. Frequent updates to these values, or to any part of the Atom document, could have a detrimental impact on the cacheability of the document using the attributes, leading to an increase in overall bandwidth consumption.

第二，这些扩展的值是不稳定的，并且可能以比包含项更快的速度变化。频繁更新这些值或Atom文档的任何部分可能会对使用属性的文档的可缓存性产生有害影响，从而导致总体带宽消耗的增加。

Feed publishers SHOULD consider a change to the values of the thr: count, thr:updated, and total extensions an "insignificant" update in terms of [RFC4287], meaning that the value of the containing feed, entry, or source element's atom:updated element SHOULD NOT be affected by a change to the values of these extensions.

饲料出版商应该考虑对THR的值的改变：计数、THR、更新，以及总的扩展（RCF4277）中的“无关紧要”的更新，这意味着包含的feed、条目或源元素Atom：更新的元素的值不应该受到这些扩展值的改变的影响。

Lastly, implementors need to be aware that although the Atom specification [RFC4287] explicitly allows the link element to contain arbitrary extensions, the specification does not require that implementations support such extensions. Specifically, relating to the use of extensions, Atom does not define any level of mandatory

最后，实现者需要知道，尽管Atom规范[RFC4287]明确允许link元素包含任意扩展，但该规范并不要求实现支持此类扩展。具体地说，关于扩展的使用，Atom没有定义任何级别的强制扩展

conformance on the part of feed consumers beyond a requirement that implementations ignore any extension the implementation does not understand. As a result, some implementations MAY NOT be capable of fully utilizing the extensions defined by this or any specification.

提要使用者的一致性超出了实现忽略实现不理解的任何扩展的要求。因此，一些实现可能无法充分利用本规范或任何规范定义的扩展。

7. Security Considerations

7. 安全考虑

As this specification defines an extension to the Atom Syndication Format, it is subject to the same security considerations defined in [RFC4287].

由于本规范定义了Atom Syndication格式的扩展，因此需要遵守[RFC4287]中定义的相同安全注意事项。

Feeds using the mechanisms described here could be crafted in such a way as to cause a consumer to initiate excessive (or even an unending sequence of) network requests, causing denial of service (to the consumer, the target server, and/or intervening networks). Consumers 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.

使用本文所述机制的提要可以以这样一种方式精心编制，即导致使用者发起过多（甚至是无休止的）网络请求，从而导致拒绝服务（对使用者、目标服务器和/或干预网络）。消费者可以通过在一定数量的请求之后要求用户干预，或者根据硬限制或使用启发式方法限制请求，来降低这种风险。

The mechanisms described here can be used to construct threaded conversations spanning resources distributed across multiple domains. For example, an individual posting an entry to one weblog hosted on one Internet domain could mark that entry as a response to an entry from a different weblog hosted on a different domain. Implementors should note that such distributed responses can be leveraged by an attacker to attach inappropriate or unwanted content to a discussion. Such attacks can be prevented or mitigated by allowing users to explicitly configure the sources from which responses may be retrieved, or by applying heuristics to determine the legitimacy of a given response source.

这里描述的机制可用于构建跨多个域分布的资源的线程对话。例如，个人将条目发布到一个Internet域上托管的一个日志中，可以将该条目标记为对来自另一个域上托管的另一个日志的条目的响应。实施者应该注意，攻击者可以利用这种分布式响应将不适当或不需要的内容附加到讨论中。通过允许用户显式配置可从中检索响应的源，或通过应用启发式来确定给定响应源的合法性，可以防止或减轻此类攻击。

Implementors should also note the potential for abuse that exists when malicious content publishers edit or change previously published content. In closed, centralized comment systems, after-the-fact editing of comments is typically not an issue, as such changes are easily prevented, detected, or tracked. With the form of distributed comments enabled through the use of the thr:in-reply-to extension, however, such changes become more difficult to detect, raising the possibility of serious attribution and repudiation concerns. XML Digital Signatures, as specified in Section 5.1 of [RFC4287], present one possible avenue for mitigating such concerns, although the presence of a valid XML Digital Signature within an entry is not, by itself, a reliable defense against repudiation issues.

实施者还应注意恶意内容发布者编辑或更改以前发布的内容时可能存在的滥用。在封闭、集中的评论系统中，事后编辑评论通常不是问题，因为这样的更改很容易被阻止、检测或跟踪。然而，随着通过使用thr（回复扩展）启用分布式评论的形式，此类更改变得更难检测，从而增加了严重的归属和否认问题的可能性。[RFC4287]第5.1节中规定的XML数字签名为缓解此类担忧提供了一种可能的途径，尽管条目中存在有效的XML数字签名本身并不是针对否认问题的可靠防御。

8. IANA Considerations

8. IANA考虑

This specification defines one new Atom link relation type that has been registered in the IANA Registry of Link Relation, as defined by [RFC4287].

本规范定义了一种新的Atom链接关系类型，该类型已在链接关系的IANA注册表中注册，如[RFC4287]所定义。

Attribute Value: replies Description: (see Section 4) Expected display characteristics: (see Section 4) Security considerations: (see Section 5)

属性值：回复说明：（参见第4节）预期显示特性：（参见第4节）安全注意事项：（参见第5节）

9. References

9. 工具书类

9.1. Normative References

9.1. 规范性引用文件

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。

[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.

[RFC3339]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 3339，2002年7月。

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。

[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.

[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。

[RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication Format", RFC 4287, December 2005.

[RFC4287]诺丁汉，M.和R.Sayre，“原子联合格式”，RFC 4287，2005年12月。

[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.

[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。

[W3C.REC-xml-infoset-20040204] Tobin, R. and J. Cowan, "XML Information Set (Second Edition)", W3C REC REC-xml-infoset-20040204, February 2004.

[W3C.REC-xml-infoset-20040204]Tobin，R.和J.Cowan，“xml信息集（第二版）”，W3C REC-xml-infoset-20040204，2004年2月。

[W3C.REC-xml-names-19990114] Hollander, D., Bray, T., and A. Layman, "Namespaces in XML", W3C REC REC-xml-names-19990114, January 1999.

[W3C.REC-xml-names-19990114]霍兰德，D.，布雷，T.，和A.外行，“xml中的名称空间”，W3C REC-xml-names-19990114，1999年1月。

[W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", W3C REC REC-xmlschema-2-20041028, October 2004.

[W3C.REC-xmlschema-2-20041028]Malhotra，A.和P.Biron，“XML模式第2部分：数据类型第二版”，W3C REC-xmlschema-2-20041028，2004年10月。

9.2. Informative References

9.2. 资料性引用

[RELAXNG] Clark, J., "RELAX NG Compact Syntax", December 2001, <http://www.oasis-open.org/committees/relax-ng/ compact-20021121.html>.

[RELAXNG]Clark，J.，“RELAXNG紧凑语法”，2001年12月<http://www.oasis-open.org/committees/relax-ng/ compact-20021121.html>。

[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.

[RFC2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。

[TAG12] Fielding, R. and I. Jacobs, "Tag Finding 12: Authoritative Metadata", <http://www.w3.org/2001/tag/doc/mime-respect-20060412>.

[TAG12]Fielding，R.和I.Jacobs，“标记查找12：权威元数据”<http://www.w3.org/2001/tag/doc/mime-respect-20060412>.

Appendix A. Acknowledgements

附录A.确认书

The author gratefully acknowledges the feedback from Antone Roundy, Aristotle Pagaltzis, Byrne Reese, David Powell, Eric Scheid, James Holderness, John Panzer, Lisa Dusseault, M. David Peterson, Sam Ruby, Sylvain Hellegouarch, and the remaining members of the Atom Publishing Format and Protocol working group during the development of this specification. Any fault or weakness in the definition of this extension is solely the blame of the author.

作者感谢Antone Roundy、Aristole Pagaltzis、Byrne Reese、David Powell、Eric Scheid、James Holderness、John Panzer、Lisa Dusseault、M.David Peterson、Sam Ruby、Sylvain Hellegouarch、，以及本规范制定期间Atom发布格式和协议工作组的其他成员。本扩展定义中的任何错误或缺陷都应完全归咎于作者。

Some portions of text in this document have been adapted from [RFC4287] in order to maintain a stylistic and technical alignment with that specification.

本文件中的部分文本已根据[RFC4287]进行了改编，以保持与该规范在风格和技术上的一致性。

Author's Address

作者地址

James M Snell

詹姆斯·姆斯内尔

   EMail: jasnell@gmail.com
   URI:   http://www.snellspace.com

   EMail: jasnell@gmail.com
   URI:   http://www.snellspace.com

Full Copyright Statement

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 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.

本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。

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.

Acknowledgement

确认

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).

RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。