[要約] RFC 4685はAtomフィードのスレッディング拡張に関するものであり、スレッド化の仕組みとその目的を定義しています。スレッド化により、関連するエントリをグループ化し、フィードの構造を改善することが目的です。
Network Working Group J. Snell
Request for Comments: 4685 September 2006
Category: Standards Track
Atom Threading Extensions
アトムスレッド拡張機能
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This memo presents a mechanism that allows feeds publishers to express threaded discussions within the Atom Syndication Format.
このメモは、フィードパブリッシャーが原子シンジケーション形式内でスレッドディスカッションを表現できるメカニズムを提示します。
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
This document defines an extension for expressing threaded discussions within the Atom Syndication Format [RFC4287].
このドキュメントでは、原子シンジケーション形式[RFC4287]内でねじ付きディスカッションを表現するための拡張機能を定義しています。
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.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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
この仕様で説明されているXML要素と属性について、XMLネームスペースuri [w3c.rec-xml-names-1990114]は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 Infoset [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を使用できます。また、URIではないIRIが控除のために与えられた場合、[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].
この仕様のいくつかのセクションには、非規範的なリラックスNGコンパクトスキーマ[claberng]で示されています。これらのセクションでは、この仕様では、[RFC4287]で定義されているAtomCommonattributes、Atommediatype、およびAtomuriパターンを使用しています。
However, the text of this specification provides the sole definition of conformance.
ただし、この仕様のテキストは、適合性の唯一の定義を提供します。
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 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.
要素は、[RFC2822]で定義された参照や電子メールへのメッセージヘッダーとは異なります。ただし、ヘッダー内のヘッダーとは異なり、単一の親リソースのみの一意の識別子を識別するためには、「繰り返し」要素が必要です。エントリが複数のリソースへの応答である場合、追加の「繰り返し」要素を使用できます。参照ヘッダーに相当する直接的なものはありません。これは、スレッド内の各前述のメッセージの一意の識別子をリストします。
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 }
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.
応答するリソースに永続的で普遍的に一意の識別子がない場合、パブリッシャーは[REF]属性の値として使用するために[RFC4287]のセクション4.2.6のすべての考慮事項を満たす識別子を割り当てる必要があります。その場合、有効な原子として使用できるIRIからリソースの表現を取得できる場合、ID値：この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.
「ソース」属性を使用して、原子フィードまたは原子を含むエントリドキュメントのIRI [RFC3987]を指定することができます：ATOMを含むエントリ：ID値「ref」属性の値に等しい。指定された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.
「タイプ」属性を使用して、「HREF」属性によって識別されたリソースのメディアタイプ[RFC4288]に関するクライアントにヒントを提供できます。「タイプ」属性は、対応する「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>
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.
繰り返しの拡張機能に精通していないアトムプロセッサが、エントリと応答されるリソースの間に関係が存在することを知るために、パブリッシャーは特定されたリソースの表現を参照する「関連」リンクを含めることを検討することをお勧めします繰り返しの要素によって。このようなリンクは、スレッド会話の前任者への参照として処理される可能性は低いですが、少なくともリンクされたリソース間の意味的に意味のある関係を確立するのに役立ちます。
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>
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属性値を持つAtomリンク要素を使用して、エントリへの応答が見つかる可能性のあるリソースを参照することができます。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.
原子フィードまたはソース要素の子として表示される「応答」リンクは、参照されるリソースに、そのフィードのエントリのいずれかに対する応答が含まれている可能性が高いことを示しています。原子エントリ要素の子として表示される「返信」リンクは、リンクされたリソースにそのエントリに固有の応答が含まれている可能性が高いことを示しています。
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.
Atom：「Replies」Rel属性値を使用したリンク要素には、XMLスキーマの標準的な表現に準拠している、署名されていない非陰性整数である「THR：カウント」属性が含まれている場合があります。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.
リンクには、[RFC4287]で定義されている原子日付コンストラクトと同じ構造ルールに適合する[RFC3339]の値が[RFC3339]である「RFC3339]の「RFC3339」の「THR：更新」属性が含まれている場合があり、クライアントにヒントを提供するために使用されます。リンクされたリソースに含まれる最近更新された返信の日付と時刻について。値はアドバイザリーであり、最新の返信の実際の日付と時刻を正確に反映していない場合があります。
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>
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.
原子フィード、エントリ、およびソース要素には、それぞれ任意の数の原子を含むことができますが、「応答」リンク関係を使用してリンク要素を含むことができますが、この仕様はそのようなリンクの存在または順序に重要性を割り当てません。アトム内に表示される複数の応答リンク：エントリは、同じ応答のセットの代替表現を参照するか、異なる応答セットを含む完全に異なるリソースを参照する場合があります。プロセッサは、複数の返信リンクが同じリソースの異なる表現を参照していると仮定してはなりません。他のリンクとは独立して各応答を処理する必要があります。
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].
「合計」要素は、パブリッシャーに知られているエントリに対する一意の応答の総数を示すために使用されます。その内容は、XMLスキーマ非陰性インテガーデータ型の標準表現に準拠する署名されていない非陰性整数値でなければなりません[w3c.rec-xmlschema-2-20041028]。
total = element thr:total { xsd:nonNegativeInteger }
Atom entries MAY contain a "total" element but MUST NOT contain more than one.
Atomエントリには「合計」要素が含まれている場合がありますが、複数の要素を含めてはなりません。
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.
原子エントリの「合計」要素の値の値と、「応答」関係を持つ原子リンク要素の「Thr：count」属性の個々または集合値の間に暗黙の関係はありません。
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：更新、および総拡張機能は、エントリに関連するディスカッションのスレッドに関する追加のメタデータを提供します。この値は、消費者がリンクリソースを繰り返し、解析し、分析することを要求することなく、フィード消費者がスレッドに関する基本的なコンテキスト情報を簡単に表示できるようにすることを目的としています。とはいえ、実装者が認識する必要がある多くの考慮事項があります。
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属性で指定された数とは異なる場合があります。フィードパブリッシャーは、値が正確であることを確認するために努力する必要があります。「外部参照メタデータ」の非承認の性質は、Repliesリンク属性と同様に、W3Cドキュメント「Tag Finding 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：count、thr：updated、およびtotal拡張の値への変更を[rfc4287]に関して「取るに足らない」アップデートを考慮する必要があります。更新された要素は、これらの拡張機能の値の変更によって影響を受けるものではありません。
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 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.
最後に、実装者は、Atom仕様[RFC4287]により、リンク要素が任意の拡張機能を含めることを明示的に許可しているが、仕様では実装がそのような拡張をサポートする必要はないことに注意する必要があります。具体的には、拡張機能の使用に関連して、ATOMは、実装が実装が理解していない拡張機能を無視するという要件を超えて、飼料消費者の一部の必須の適合性を定義しません。その結果、いくつかの実装は、これまたは任意の仕様で定義された拡張機能を完全に利用することができない場合があります。
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.
ここで説明するメカニズムは、複数のドメインに分配されたリソースにまたがるスレッドされた会話を構築するために使用できます。たとえば、1つのインターネットドメインでホストされている1つのウェブログへのエントリを投稿する個人は、別のドメインでホストされている別のウェブログからのエントリへの応答としてそのエントリをマークする可能性があります。実装者は、そのような分散した応答を攻撃者が活用して、不適切または不要なコンテンツを議論に添付できることに注意する必要があります。このような攻撃は、ユーザーが回答が取得される可能性のあるソースを明示的に構成できるようにするか、ヒューリスティックを適用して特定の応答ソースの正当性を決定することにより、防止または軽減できます。
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：In-Reply-to Extensionを使用することで有効になっている分散コメントの形式により、そのような変更は検出がより困難になり、深刻な帰属と拒否の懸念の可能性が高まります。[RFC4287]のセクション5.1で指定されているXMLデジタル署名は、そのような懸念を軽減するための1つの可能な手段を提示しますが、エントリ内での有効なXMLデジタル署名の存在は、それ自体では拒否問題に対する信頼できる防御ではありません。
This specification defines one new Atom link relation type that has been registered in the IANA Registry of Link Relation, as defined by [RFC4287].
この仕様では、[RFC4287]で定義されているように、IANAリンク関係のIANAレジストリに登録されている1つの新しい原子リンク関係タイプを定義します。
Attribute Value: replies Description: (see Section 4) Expected display characteristics: (see Section 4) Security considerations: (see Section 5)
属性値：返信説明：（セクション4を参照）予想される表示特性：（セクション4を参照）セキュリティ上の考慮事項：（セクション5を参照）
[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] Nottingham、M。およびR. Sayre、「The Atom Syndication Format」、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 Information Set（第2版）」、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] Hollander、D.、Bray、T。、およびA. layman、「XMLの名前空間」、W3C Rec 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 Schema Part 2：DataTypes Second Edition」、W3C Rec Rec-Xmlschema-2-20041028、2004年10月。
[RELAXNG] Clark, J., "RELAX NG Compact Syntax", December 2001, <http://www.oasis-open.org/committees/relax-ng/ compact-20021121.html>.
[Relabyng] Clark、J。、「Relax ng Compact Syntax」、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。and I. Jacobs、「Tag Finding 12：Athoritative Metadata」、<http://www.w3.org/2001/tag/doc/mime-respect-20060412>。
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.
著者は、アントン・ラウンド、アリストテレス・パガルツィス、バーン・リース、デビッド・パウエル、エリック・シェイド、ジェームズ・ホルダーネス、ジョン・パンツァー、リサ・デュッセル、M。この仕様の開発中のフォーマットおよびプロトコルワーキンググループ。この拡張機能の定義の障害または弱点は、著者の責任のみです。
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
ジェームズMスネル
EMail: jasnell@gmail.com
URI: http://www.snellspace.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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事務局に行われた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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。