RFC 4287 The Atom Syndication Format 日本語訳

本ドキュメントは、RFC 4287 『The Atom Syndication Format』 を futomi が日本語化したものです。みなさまの理解に役立てれば幸いです。なお、緑色で記載された文章は、futomi が注釈として加筆したものです。また、一部、直訳ではなく、意訳した部分がございます。原文と表現が異なることがございますので、ご了承ください。

注意: この日本語訳は、futomi が理解を深めるために、自分なりに日本語化したものです。本日本語訳には、翻訳上の誤りがある可能性があります。したがって、内容について一切保証をするものではありません。正確さを求める場合には、必ず原文を参照してください。当方は、この文書によって利用者が被るいかなる損害の責任を負いません。

もし誤りなどを見つけたら、こちらからご連絡いただければ幸いです。


Network Working Group M. Nottingham, Ed.
Request for Comments: 4287 R. Sayre, Ed.
Category: Standards Track December 2005

The Atom Syndication Format

このメモの状態

本文書はインターネットコミュニティーのためのインターネット標準化過程プロトコルを定めるもであり、改善のための議論と提案を求めるものです。標準化の状況とこのプロトコルの位置づけに関しては、"Internet Official Protocol Standards" (STD 1) の最新版を参照してください。このメモの配布は自由です。

著作権表示

Copyright (C) The Internet Society (2005).

要約

この文書は、XMLベースのウェブコンテンツとメタデータ配信フォーマットであるAtomの仕様を定めるものです。

目次

1. はじめに
1.1.
1.2. 名前空間とバージョン
1.3. 表記の決まり
2. Atom文書
3. 共通のAtomコンストラクト
3.1. Textコンストラクト
3.1.1. "type"属性
3.2. Personコンストラクト
3.2.1. "atom:name"要素
3.2.2. "atom:uri"要素
3.2.3. "atom:email"要素
3.3. Dateコンストラクト
4. Atom要素の定義
4.1. コンテナー要素
4.1.1. "atom:feed"要素
4.1.2. "atom:entry"要素
4.1.3. "atom:content"要素
4.2. メタデータ要素
4.2.1. "atom:author"要素
4.2.2. "atom:category"要素
4.2.3. "atom:contributor"要素
4.2.4. "atom:generator"要素
4.2.5. "atom:icon"要素
4.2.6. "atom:id"要素
4.2.7. "atom:link"要素
4.2.8. "atom:logo"要素
4.2.9. "atom:published"要素
4.2.10. "atom:rights"要素
4.2.11. "atom:source"要素
4.2.12. "atom:subtitle"要素
4.2.13. "atom:summary"要素
4.2.14. "atom:title"要素
4.2.15. "atom:updated"要素
5. Atom文書のセキュリティー対策
5.1. 電子署名
5.2. 暗号化
5.3. 署名と暗号化
6. Atomの拡張
6.1. Atomではない語彙からの拡張
6.2. Atomの語彙への拡張
6.3. 外部マークアップの処理
6.4. 拡張要素
6.4.1. 単式拡張要素
6.4.2. 構造化拡張要素
7. IANAについて
7.1. リンクリレーションの登録
8. セキュリティーについて
8.1. HTMLとXHTMLコンテンツ
8.2. URI
8.3. IRI
8.4. なりすまし
8.5. 暗号化と署名
9. リファレンス
9.1. 標準リファレンス
9.2. 参考リファレンス
付録 A. 貢献者
付録 B. RELAX NG Compact Schema

1. はじめに

Atomは、関連情報のリストを記述したXMLベースの文書フォーマットです。"フィード"としてよく知られています。フィードは、"エントリー"とよく言われているいくつもの項目から構成されます。そして、それらは各々、拡張可能な添付のメタデータのセットを持っています。例えば、各エントリーはタイトルを持っています。

Atomが扱う主な用途は、ブログやニュースヘッドラインといったウェブコンテンツの配信です。それは、ユーザエージェントへの直接的な配信にとどまらず、ウェブサイトへの配信をも扱います。

1.1. 例

entryが1つしかない簡単な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/"/>
  <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>

entryが1つしかありませんが、もう少し拡張したAtomフィード文書です。

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title type="text">dive into mark</title>
  <subtitle type="html">
    A &lt;em&gt;lot&lt;/em&gt; of effort
    went into making this effortless
  </subtitle>
  <updated>2005-07-31T12:29:29Z</updated>
  <id>tag:example.org,2003:3</id>
  <link rel="alternate" type="text/html"
    hreflang="en" href="http://example.org/"/>
  <link rel="self" type="application/atom+xml"
    href="http://example.org/feed.atom"/>
  <rights>Copyright (c) 2003, Mark Pilgrim</rights>
  <generator uri="http://www.example.com/" version="1.0">
    Example Toolkit
  </generator>
  <entry>
    <title>Atom draft-07 snapshot</title>
    <link rel="alternate" type="text/html"
      href="http://example.org/2005/04/02/atom"/>
    <link rel="enclosure" type="audio/mpeg" length="1337"
      href="http://example.org/audio/ph34r_my_podcast.mp3"/>
    <id>tag:example.org,2003:3.2397</id>
    <updated>2005-07-31T12:29:29Z</updated>
    <published>2003-12-13T08:29:29-04:00</published>
    <author>
      <name>Mark Pilgrim</name>
      <uri>http://example.org/</uri>
      <email>f8dy@example.com</email>
    </author>
    <contributor>
      <name>Sam Ruby</name>
    </contributor>
    <contributor>
      <name>Joe Gregorio</name>
    </contributor>
    <content type="xhtml" xml:lang="en"
      xml:base="http://diveintomark.org/">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><i>[Update: The Atom draft is finished.]</i></p>
      </div>
    </content>
  </entry>
</feed>

1.2. 名前空間とバージョン

本仕様書で規定するXMLデータフォーマット用のXML名前空間URI [W3C.REC-xml-names-19990114] は、次の通りです。

http://www.w3.org/2005/Atom

このデータフォーマットは"Atom 1.0"と呼ばれているかもしれませんが、便宜上、本仕様書の中では"Atom"を使います。

1.3. 表記の決まり

本仕様書は、2つの加工品に関する適合性を説明します。それはAtomフィード文書とAtomエントリー文書です。加えて、Atomプロセッサーに必要ないくつかの要件を掲載します。

本仕様書は、前述のセクション1.2で指定された名前空間URIに対して名前空間プレフィックス"atom:"を使います。名前空間プレフィックスの選択は任意であり、意味論的には重要ではないことに注意してください。

AtomはXML Infoset [W3C.REC-xml-infoset-20040204] からの用語を使うよう規定されています。しかし、本仕様書は、次の2つの共通用語に対しては簡略表現を使います。要素情報項目(Element Information Items)と属性情報項目(Attribute Information Items)を表すときには、"情報項目(Information Item)"というフレーズに省略します。そのため、本仕様書が"要素,"という用語を使うときは、それは情報項目の要素情報項目を表していることになります。同様に、"属性,"という用語を使うときは、属性情報項目を表していることになります。

本仕様書のいくつかのセクションは、非準拠のRELAX NG Compact schema [RELAX-NG] の一部分を使って解説されます。しかし、本仕様書のテキストは、適合性の定義を提供しているのです。完全なスキーマは付録Bをご覧下さい。

本文書に出てくる"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"といったキーワードは、それらの適合性の目的の範囲内で、BCP 14 [RFC2119] に規定されているとおりに解釈してください。

2. Atom文書

本仕様書は、2種類のAtom文書を説明します。Atomフィード文書とAtomエントリー文書です。

Atomフィード文書とはAtomフィードのことですが、そのフィードに関するメタデータや、それに関連付けられたいくつかもしくはすべてのエントリーを含みます。atom:feed 要素がルート要素になります。

Atomエントリー文書は、厳密には1つのAtomエントリーを表し、Atomフィードのコンテキストの外側にあります。atom:entry要素がルート要素になります。

namespace atom = "http://www.w3.org/2005/Atom"
start = atomFeed | atomEntry

どちらの種類のAtom文書も、XML情報集合(XML Information Set)について規定されています。Atom文書は、XML 1.0 [W3C.REC-xml-20040204] として連載し、メディアタイプ "application/atom+xml" で特定します。Atom文書は整形式XML文書でなければいけません。本仕様書はAtom文書用のDTDを定義しません。従って、(XMLとして使われるという意味で)それらが妥当であるかどうかは求めません。

AtomではIRI [RFC3987] を使うことができます。すべてのURI [RFC3986] はIRIでもあり、そのため、URIは、IRIが命名された後であればどこでも使われるかもしれません。2つの特別な注意事項があります。(1) URIでもないIRIが参照解除のために与えられるとき、それは [RFC3987] のセクション3.1におけるステップを使ってURLにマップされなければいけません。そして (2) IRIがatom:id値として与えているときは、それはマップされてはいけません。そうすることで、セクション4.2.6.1.で説明されているとおりに準拠した動作が実現できです。

本仕様書で定義されているどんな要素も、xml:base属性 [W3C.REC-xmlbase-20010627] を持っても構いません。xml:baseがAtom文書内で使われているとき、それは [RFC3986] のセクション5.1.1に書いてある機能の役割を果たし、xml:base属性の有効な範囲内で見つかるどんな相対参照をも解決するための基本のURL(またはIRI)を確立します。

本仕様書で定義されているどんな要素も、 xml:lang要素を持っても構いません。そのコンテンツはその要素とその下位要素に対して自然言語を指し示します。その言語コンテキストは、本仕様書で"言語依存性がある" と宣言された要素と属性にとっては重要です。そのコンテンツとxml:langの解釈に関する要求事項は、XML 1.0 [W3C.REC-xml-20040204] のセクション2.12で規定されています。

atomCommonAttributes =
    attribute xml:base { atomUri }?,
    attribute xml:lang { atomLanguageTag }?,
    undefinedAttribute*

Atomは拡張可能なフォーマットです。Atom文書の拡張方法に関する完全な説明は、本仕様書のセクション6をご覧下さい。

Atomプロセッサーは、Atomフィード文書から供給された状態を維持しても構いませんし、また、他のAtomフィード文書と結合して、連続的にコンテンツを見せるといったことをしても構いません。複数のAtomフィード文書を1つのフィードに結合するといった(例えば、エントリーとメタデータを更新したり、無くなったエントリーを取り扱ったりする)やり方は、本仕様書の規定範囲ではありません。

3. 共通のAtomコンストラクト

Atomの要素の多くは、いくつかの共通の構造を共有します。このセクションは、適切な要素定義によって、使いやすいリファレンスとなるよう、その構造と要求事項を定義します。

要素がある特定の種類のコンストラクトであるとして識別されるとき、その要素はこのセクション内のコンストラクトの定義から、それに対応する要求事項を引き継ぎます。

DateコンストラクトやIRIの中に、ホワイトスペースは存在してはいけないことに注意してください。デフォルトで値の周りにホワイトスペースを挿入するような、間違ったXML発行の実装を見かけますが、そのような実装では妥当でないAtom文書を発行してしまうことになるのです。

3.1. Textコンストラクト

Textコンストラクトには、通常は少量なのですが、人間が読むことができるテキストが入ります。Textコンストラクトの内容は言語依存性があります。

atomPlainTextConstruct =
    atomCommonAttributes,
    attribute type { "text" | "html" }?,
    text
atomXHTMLTextConstruct =
    atomCommonAttributes,
    attribute type { "xhtml" },
    xhtmlDiv
atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct

3.1.1. "type"属性

Textコンストラクトには"type"属性を持たせることができます。それがあるときは、その値は "text", "html", "xhtml"のいずれか1つでなければいけません。もし"type"属性が与えられなかったら、Atomプロセッサーは、type属性値が"text"であるとして振舞わなければいけません。セクション4.1.3のatom:content要素とは違い、Textコンストラクト上の"type"属性の値としてMIMEメディアタイプ [MIMEREG] を使ってはいけません。

3.1.1.1. Text

テキストコンテンツをもったatom:titleの例です。

...
<title type="text">
    Less: &lt;
</title>
...

もし"type"属性の値が"text"なら、Textコンストラクトの内容は子要素を含んではいけません。このテキストは、いちおうなりとも人間に読めるよう提示されることを目的としています。そのため、Atomプロセッサーは、(改行を含めて)ホワイトスペースを折りたたんだり、行端揃えやプロポーショナルフォントのような印刷技術を使ってテキストを表示することができます。

3.1.1.2. HTML

HTMLコンテンツをもったatom:titleの例です。

...
<title type="html">
    Less: &lt;em> &amp;lt; &lt;/em>
</title>
...

もし"type"属性の値が"html"なら、Textコンストラクトの内容は子要素を含んではいけません。そしてHTML [HTML] として取り扱うのに適しているべきです。マークアップはすべてエスケープしなければいけません。例えば、"<br>"なら"&lt;br>"とします。HTMLマークアップは、エスケープを解除した後、HTMLの<DIV>要素の中に有効に直接現れるようにすべきです。このようなコンテンツを表示するAtomプロセッサーは、それを表示する際にマークアップ反映することができます。

3.1.1.3. XHTML

XHTMLコンテンツをもったatom:titleの例です。

...
<title type="xhtml" xmlns:xhtml="http://www.w3.org/1999/xhtml">
    <xhtml:div>
        Less: <xhtml:em> &lt; </xhtml:em>
    </xhtml:div>
</title>
...

もし"type"属性の値が"xhtml"なら、Textコンストラクトの内容は、1つのXHTML [XHTML] div要素でなければいけません。そしてXHTMLとして取り扱うのに適しているべきです。XHTML div要素そのものを、そのコンテンツの一部とみなしてはいけません。コンテンツを表示するAtomプロセッサーは、それを表示する際にマークアップ反映することができます。"&" や ">" のように、エスケープされた文字に関しては、マークアップではなく、それらの文字を表します。

妥当なXHTMLコンテンツの例です。

...
<summary type="xhtml">
    <div xmlns="http://www.w3.org/1999/xhtml">
        This is <b>XHTML</b> content.
    </div>
</summary>
...
<summary type="xhtml">
    <xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml">
        This is <xhtml:b>XHTML</xhtml:b> content.
    </xhtml:div>
</summary>
...

次の例は、XHTML名前空間が文書内の前のほうで"xh"プレフィックスに結び付けられたと仮定したものです。

...
<summary type="xhtml">
    <xh:div>
        This is <xh:b>XHTML</xh:b> content.
    </xh:div>
</summary>
...

3.2. Personコンストラクト

Personコンストラクトは、人、会社、または同様の団体(以降、'人'と呼びます。)を記述する要素です。

atomPersonConstruct =
    atomCommonAttributes,
    (element atom:name { text }
      & element atom:uri { atomUri }?
      & element atom:email { atomEmailAddress }?
      & extensionElement*)

この仕様では、Personコンストラクト内の子要素の出現する順番に意味はまったくありません。Personコンストラクトは拡張メタデータ要素(セクション6.4を参照のこと)を許可します。

3.2.1. "atom:name"要素

"atom:name"要素の内容は、人間が読める人の名前を伝えます。atom:nameの内容は言語依存性があります。Personコンストラクトは、厳密に1つの"atom:name"要素を含まなければいけません。

3.2.2. "atom:uri"要素

"atom:uri"要素の内容は、人に関連付けられたIRIを伝えます。Personコンストラクトは1つのatom:uri要素を含むことができますが、それ以上を含んではいけません。Personコンストラクト内のatom:uriの内容は、IRI参照 [RFC3987] でなければいけません。

3.2.3. "atom:email"要素

"atom:email"要素の内容は、人に関連付けられたe-mailアドレスを伝えます。Personコンストラクトは1つのatom:email要素を含むことができますが、それ以上を含んではいけません。その内容は、[RFC2822] の"addr-spec"形式に準拠していなければいけません。

3.3. Dateコンストラクト

Dateコンストラクトは、その内容が [RFC3339] の"date-time"形式に準拠していなければいけません。さらに、日と時間の区切り文字として大文字"T"を挿入し、そしてタイムゾーンオフセットが指定されない場合には大文字"Z"を挿入しなければいけません。

atomDateConstruct =
    atomCommonAttributes,
    xsd:dateTime

この日付値は、 [ISO.8601.1988], [W3C.NOTE-datetime-19980827], [W3C.REC-xmlschema-2-20041028] と互換性があります。

Dateコンストラクトの例です。

<updated>2003-12-13T18:30:02Z</updated>
<updated>2003-12-13T18:30:02.25Z</updated>
<updated>2003-12-13T18:30:02+01:00</updated>
<updated>2003-12-13T18:30:02.25+01:00</updated>

Date値は、できる限り精度を高くすべきです。例えば、パブリッシングシステムで、同じ日にいくつかのエントリーが発行された場合、それらのタイムスタンプがすべて同じだったとしたら、一般的には不適切といえるでしょう。

4. Atom要素の定義

4.1. コンテナー要素

4.1.1. "atom:feed"要素

"atom:feed"要素は、Atomフィード文書のドキュメント要素(つまり、トップレベル要素)であり、フィードに関連付けられたメタデータとデータ用のコンテナーとしての役割を果たします。その子要素は、0もしくは1つ以上のatom:entry子要素で連なるメタデータ要素から成り立ちます。

atomFeed =
    element atom:feed {
        atomCommonAttributes,
        (atomAuthor*
          & atomCategory*
          & atomContributor*
          & atomGenerator?
          & atomIcon?
          & atomId
          & atomLink*
          & atomLogo?
          & atomRights?
          & atomSubtitle?
          & atomTitle
          & atomUpdated
          & extensionElement*),
        atomEntry*
    }

この仕様では、フィード内のatom:entry要素の順番に意味はまったくありません。

この仕様では、次の子要素を定義します。(これらの要素のいくつかの存在は必須であることに注意してください。)。

もしAtomフィードの中に同じatom:idの値を持ったatom:entry要素が複数存在していたら、それらは同じエントリーを意味します。これらのatom:updatedのタイムスタンプは異なるべきです。もしAtomフィード文書が同じatom:idを持った複数のエントリーを含むなら、Atomプロセッサーはそれらのすべてか、もしくはそれらの一部を表示するのかを選択することができます。この場合、atom:updatedのタイムスタンプが最新のエントリーのみを表示のが、標準的な動作の1つといえるでしょう。

4.1.1.1. 原文コンテンツの提供

原文コンテンツを含むフィードは、一般的に、そうでないものより役立つということを経験が語ります。いくつかのアプリケーション(一例として、全文インデックサー)は、確実にかつ予想とおりに機能するために、最小の分量のテキストもしくは(X)HTMLを必要とします。フィードを生成する際には、これらの問題を認識すべきです。各atom:entry要素の中にatom:title要素とatom:content要素が存在すれば、それらは空ではありません。atom:content要素がなければ、空でないatom:summary要素があるはずです。しかし、atom:summaryが無くてもエラーではありませんので、Atomプロセッサーは、このように要素が存在しないからといって、正常に動作しないという結果にならないようにしなければいけません。

4.1.2. "atom:entry"要素

"atom:entry"要素は、個々のエントリーを表し、そのエントリーに関連付けられたメタデータとデータ用のコンテナーの役割を果たします。この要素はatom:feed要素の子要素、もしくは、スタンドアローンAtomエントリー文書の文書要素(つまり、トップレベル要素)として現れます。

atomEntry =
element atom:entry { atomCommonAttributes, (atomAuthor* & atomCategory* & atomContent? & atomContributor* & atomId & atomLink* & atomPublished? & atomRights? & atomSource? & atomSummary? & atomTitle & atomUpdated & extensionElement*) }

この仕様では、atom:entryの子要素の出現の順番に、意味はまったくありません。

この仕様では、次の子要素を定義します。(これらの要素のうち、いくつかは必須となることに注意してください。)。

4.1.3. "atom:content"要素

"atom:content"要素は、エントリーのコンテンツもしくはコンテンツへのリンクを含みます。atom:contentのコンテンツは、言語依存性があります。

atomInlineTextContent =
    element atom:content {
        atomCommonAttributes,
        attribute type { "text" | "html" }?,
        (text)*
    }
atomInlineXHTMLContent =
    element atom:content {
        atomCommonAttributes,
        attribute type { "xhtml" },
        xhtmlDiv
    }
atomInlineOtherContent =
    element atom:content {
        atomCommonAttributes,
        attribute type { atomMediaType }?,
        (text|anyElement)*
    }
atomOutOfLineContent =
    element atom:content {
        atomCommonAttributes,
        attribute type { atomMediaType }?,
        attribute src { atomUri },
        empty
    }
atomContent = atomInlineTextContent
    | atomInlineXHTMLContent
    | atomInlineOtherContent
    | atomOutOfLineContent
4.1.3.1. "type"属性

atom:content要素上では、"type"属性の値は"text", "html", "xhtml"のいずれか1つにすることができます。それ以外であれば、MIMEメディアタイプの構文に準拠しなければいけません。しかし、混合タイプは禁止です([MIMEREG] のセクション4.2.6をご覧下さい)。もしtype属性もsrc属性も与えられなかった場合は、Atomプロセッサーは、type属性の値が"text"であるものとして振舞わなければいけません。

4.1.3.2. "src"属性

atom:contentは"src"属性を持つことができます。その値は、IRI参照 [RFC3987] でなければいけません。もし"src"属性が存在していれば、atom:contentは空でなければいけません。Atomプロセッサーはコンテンツを取り出すためにIRIを使うことができます。そして、参照先のコンテンツを無視するのか、ローカルコンテンツとは違う方法でそれを提示するのかを選択することができます。

もし"src"属性が存在していれば、"type"属性は与えられるべきです。そして"text", "html", "xhtml"ではなくMIMEメディアタイプ [MIMEREG] でなければいけません。その値は勧告という位置づけになります。つまり、対応するURI(必要に応じてIRIからマッピングしたURI)が修飾参照されるとき、もしコンテンツを提供するサーバーもメディアタイプを提供するなら、サーバから提供されたメディアタイプが正式なものとなります。

4.1.3.3. Processing Model

Atom文書は、次のルールに準拠しなければいけません。Atomプロセッサーは、一番最初に適用されるルールに準じて、atom:contentを解釈しなければいけません。

  1. もし"type"の値が"text"なら、atom:contentのコンテンツは、子要素を含んではいけません。そのようなテキストは、いちおうなりとも人間に読めるよう提示されることを目的としています。そのため、Atomプロセッサーは、(改行を含めて)ホワイトスペースを折りたたんだり、行端揃えやプロポーショナルフォントのような印刷技術を使ってテキストを表示することができます。
  2. もし"type"の値が"html"なら、atom:contentのコンテンツは、子要素を含んではいけません。そしてHTML [HTML] として取り扱うのに適しているべきです。HTMLマークアップはすべてエスケープしなければいけません。例えば、"<br>"なら"&lt;br>"とします。HTMLマークアップは、有効にHTMLの<DIV>要素の中に直接現れるようにすべきです。このようなコンテンツを表示するAtomプロセッサーは、その表示において援助するためにマークアップを使うことができます。
  3. もし"type"の値が"xhtml"なら、atom:contentのコンテンツは、XHTML [XHTML] のdiv要素一つだけでなければいけません。そしてXHTMLとして取り扱うのに適しているべきです。XHTMLのdiv要素はそれ自身、そのコンテンツの一部とみなされてはいけません。コンテンツを表示するAtomプロセッサーは、その表示において援助するためにマークアップを使うことができます。"&" や ">" のように、エスケープされた文字に関しては、マークアップではなく、それらの文字を表します。
  4. もし"type"の値がXMLメディアタイプ [RFC3023] 、もしくは"+xml"や"/xml"(大文字・小文字は区別しない)で終わるなら、atom:contentのコンテンツは子要素を含めることができます。そして指し示されたメディアタイプとして取り扱うのに適しているべきです。もし"src"属性が与えられなかったら、通常なら、"atom:content"要素は、指し示されたタイプのXML文書のルート要素として提供した1つだけの子要素を含むということを意味します。
  5. もし"type"の値が"text/"(大文字・小文字は区別しない)で始まるなら、atom:contentのコンテンツは子要素を含んではいけません。
  6. "type"の値が上記以外の場合は、atom:contentのコンテンツは、[RFC3548] のセクション3で規定されている妥当なBase64エンコードディングしたものでなければいけません。デコードされたとき、それは指し示されたメディアタイプとして取り扱われるために適しているべきです。この場合においては、atom:content要素の中で、先頭にホワイトスペースを入れてからBase64エンコーディングの文字を続けることができます。1つの改行 (U+000A) 文字によって行を分けることができます。
4.1.3.4. 例

XHTML inline:

...
<content type="xhtml">
    <div xmlns="http://www.w3.org/1999/xhtml">
        This is <b>XHTML</b> content.
    </div>
</content>
...
<content type="xhtml">
    <xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml">
        This is <xhtml:b>XHTML</xhtml:b> content.
    </xhtml:div>
</content>
...

次の例は、XHTML名前空間が文書内の前のほうで"xh"プレフィックスに結び付けられたと仮定したものです。

...
<content type="xhtml">
    <xh:div>
        This is <xh:b>XHTML</xh:b> content.
    </xh:div>
</content>
...

4.2. メタデータ要素

4.2.1. "atom:author"要素

"atom:author"要素は、エントリーやフィードの著者を示すPersonコンストラクトです。

atomAuthor = element atom:author { atomPersonConstruct }

もしatom:entry要素にatom:author要素が含まれていなかったら、atom:source要素のatom:author要素を適用されることになります。Atomフィード文書では、前述の場所にatom:author要素がなければ、atom:feed要素のatom:author要素がそのエントリーに適用されることになります。

4.2.2. "atom:category"要素

"atom:category"要素は、エントリーやフィードに関連付けられたカテゴリーに関する情報を伝えます。この仕様は、この要素の内容になんら意味を与えるものではありません。

atomCategory =
    element atom:category {
        atomCommonAttributes,
        attribute term { text },
        attribute scheme { atomUri }?,
        attribute label { text }?,
        undefinedContent
    }
4.2.2.1. "term"属性

"term"属性は、エントリーやフィードが属するカテゴリーを表す文字列です。category要素は"term"属性が必須です。

4.2.2.2. "scheme"属性

"scheme"属性は、分類スキームを表すIRIです。category要素は"scheme"属性を持つことができます。

4.2.2.3. "label"属性

"label"属性は、エンドユーザー側のアプリケーションに表示するための、人間が読めるラベルを提供します。"label"の内容は言語依存性があります。"&amp;" や "&lt;" のような実体は、マークアップではなく、それに対応する文字("&" や "<", respectively)を表します。category要素は"label"属性を持つことができます。

4.2.3. "atom:contributor"要素

"atom:contributor"要素は、エントリーやフィードに貢献した人や他の実体を表すPersonコンストラクトです。

atomContributor = element atom:contributor { atomPersonConstruct }

4.2.4. "atom:generator"要素

"atom:generator"要素の内容は、デバッグ等の目的のために、フィード生成に使われたエージェントを表します。

atomGenerator = element atom:generator {
    atomCommonAttributes,
    attribute uri { atomUri }?,
    attribute version { text }?,
    text
}

この要素があるなら、その内容は生成エージェントの名前を表し、人間が読めるものでなければいけません。"&amp;" や "&lt;" のような実体は、マークアップではなく、それに対応する文字(それぞれ"&" や "<")を表します。

atom:generator要素は、"uri"属性を持つことができますが、その値はIRI参照 [RFC3987] でなければいけません。修飾参照されたとき、現れるURI(必要に応じて、IRIからマッピングされた)は、そのエージェントに関係がある記述を生成すべきです。

atom:generator要素は、"version"属性を持つことができますが、それは生成エージェントのバージョンを表すものです。

4.2.5. "atom:icon"要素

"atom:icon"要素の内容は、IRI参照 [RFC3987] であり、それはフィードを象徴するようなビジュアル識別子を提供する画像を表します。

atomIcon = element atom:icon {
    atomCommonAttributes,
    (atomUri)
}

その画像は1:1の縦横比で、小さいサイズで適切に表示できるようなものにすべきです。

4.2.6. "atom:id"要素

"atom:id"要素は、エントリーやフィードの永久的で完全に一意的な識別子を伝えます。

atomId = element atom:id {
    atomCommonAttributes,
    (atomUri)
}

その内容は、[RFC3987] で定義されているIRIでなければいけません。"IRI"の定義は、相対参照を除外している点に注意してください。IRIは修飾参照可能なスキームを使うかかもしれませんが、Atomプロセッサーは、それが修飾参照されうると仮定してはいけません。

Atom文書を移転・移住・配信・再発行・エクスポート・インポートしたとしても、そのatom:id要素の内容を変更してはいけません。つまり、atom:id要素は、ある特定のAtomのエントリーまたはフィードのすべてのインスタンス化に付随します。atom:id要素は、関連付けられたリソースとともに保存されることが推奨されています。

atom:id要素の内容は、一意性を保証する方法で生成されなければいけません。

もしURIにマッピングされているIRIと修飾参照されているIRIがあったとき、それらが同等なのかどうか混乱するリスクがあるため、atom:id要素を生成するときには、次の正規化の方針を適用すべきです。

4.2.6.1. atom:idの比較

atom:id要素のインスタンスは、エントリーまたはフィードが以前のものと同じかどうかを見極めるために比較されることがあります。プロセッサーは、atom:id要素を1文字単位で(大文字小文字を区別して)比較しなければいけません。比較の処理は、単にIRI文字列に基づかなければいけません。そして、それらからマッピングされたIRIやURIの修飾参照を当てにしてはいけません。

結果的に、同じリソースを指してはいるものの、文字列ベースで異なる2つのIRIは、識別子比較の趣旨からすると、違うとみなされるでしょう。

例えば、以下の4つの識別子は明らかに異なります。しかし、それらは大文字・小文字の違いしかありません。

http://www.example.org/thing
http://www.example.org/Thing
http://www.EXAMPLE.org/thing
HTTP://www.example.org/thing

同様に、以下の3つの識別子も明らかに異なります。なぜなら、IRIのパーセントエンコーディングが、比較の趣旨からすると、大きな意味を持つからです。

http://www.example.com/~bob
http://www.example.com/%7ebob
http://www.example.com/%7Ebob

4.2.7. "atom:link"要素

"atom:link"要素は、エントリーやフィードからウェブリソースへの参照を定義します。この仕様では、この要素の内容にまったく意味を割り当てません。

atomLink =
    element atom:link {
        atomCommonAttributes,
        attribute href { atomUri },
        attribute rel { atomNCName | atomUri }?,
        attribute type { atomMediaType }?,
        attribute hreflang { atomLanguageTag }?,
        attribute title { text }?,
        attribute length { text }?,
        undefinedContent
    }
4.2.7.1. "href"属性

"href"属性はリンクのIRIを含みます。atom:link要素は、必ず1つのhref属性を持たなければいけません。href属性の値は、IRI参照 [RFC3987] でなければいけません。

4.2.7.2. "rel"属性

atom:link要素は、リンクリレーションタイプを指し示す"rel"属性を持つことができます。もし"rel"属性がなければ、link要素は、リンクリレーションタイプが"alternate"として解釈されなければいけません。

"rel"の値は、空であってはいけません。そして"isegment-nz-nc"もしくは [RFC3987] の"IRI"形式のいずれかに一致した文字列でなければいけません。単一の名前以外の相対参照の使用は禁止です。もし名前が与えられれば、そのリンクリレーションタイプは、リンクリレーション(セクション7)のIANAレジストリで登録される同じ名前と同等であることを考慮して実装しなければいけません。従って、文字列"http://www.iana.org/assignments/relation/"にrel属性の値を追加することによって得られるであろうIRIと同等であるのです。"rel"の値は、リンクの意味を表します。しかし、"rel"の値がAtomプロセッサーにどんな挙動要件も課すことはありません。

本ドキュメントは、リンクリレーションのレジストリーに対して、5つの初期値を定義します。

  1. "alternate"という値は、href属性の値にあるIRIが、含んでいる要素によって記述されたリソースの代替バージョンを特定していることを示します。
  2. "related"という値は、href属性の値にあるIRIが、含んでいる要素によって記述されたリソースに関連するリソースを特定していることを示します。例えば、"http://search.example.com"のサーチエンジンのパフォーマンスを議論するサイトのフィードは、atom:feedの子要素として含みます。
    <link rel="related" href="http://search.example.com/"/>
    同一のリンクは、コンテンツが同じサーチエンジンの議論を含んでいるatom:entryの子要素として現れるでしょう。
  3. "self"という値は、href属性の値にあるIRIが、含んでいる要素と同等のリソースを特定していることを示します。
  4. "enclosure"という値は、href属性の値にあるIRIが、潜在的にサイズが大きく、特別な扱いを必要とする関連リソースを特定していることを示します。 rel="enclosure"を持ったatom:link要素に対しては、length属性を与えるべきです。
  5. "via"という値は、href属性の値にあるIRIが、含んでいる要素の中で提供されている情報元であるリソースを特定していることを示します。
4.2.7.3. "type"属性

link要素上では、"type"属性の値は、勧告メディアタイプです。それは、href属性の値が修飾参照されるときに返されると期待される表現のタイプに関するヒントです。type属性は、表現と一緒に返される実際のメディアタイプを覆すことはないことに注意してください。link要素は、type属性を持つことができます。type属性の値は、MIMEメディアタイプ [MIMEREG] の構文に準拠しなければいけません。

4.2.7.4. "hreflang"属性

"hreflang"属性の内容は、href属性によって指し示されるリソースの言語を表します。rel="alternate"といっしょに使われたときは、それは、翻訳されたバージョンのエントリーを暗示します。link要素は、hreflang属性を持つことができます。hreflang属性の値は、言語タグ [RFC3066] でなければいけません。

4.2.7.5. "title"属性

"title"属性は、リンクに関する、人が読める情報を伝えます。"title"属性の内容は、言語依存性があります。"&amp;" や "&lt;"のような実体文字参照は、マークアップではなく、それらに対応する文字(それぞれ"&", "<")を表します。link要素はtitle属性を持つことができます。

4.2.7.6. "length"属性

"length"属性は、オクテットで、リンクされたコンテンツのサイズの勧告を示します。それは、href属性がURIにマッピングされたり修飾参照されたときに返される表現のコンテンツ長に関するヒントです。length属性は、元となっているプロトコルによって報告されるような表現の実際のコンテンツ長を覆すことはないことに注意してください。link要素はlength属性を持つことができます。

4.2.8. "atom:logo"要素

"atom:logo"要素の内容は、IRI参照 [RFC3987] であり、それはフィードを象徴するようなビジュアル識別子を提供する画像を表します。

atomLogo = element atom:logo {
    atomCommonAttributes,
    (atomUri)
}

その画像は2(幅):1(高)の縦横比とすべきです。

4.2.9. "atom:published"要素

"atom:published"要素は、エントリーのライフサイクル初期のイベントに関連付けられたそのときの時間を指し示すDateコンストラクトです。

atomPublished = element atom:published { atomDateConstruct }

通常は、atom:publishedは、リソースが最初に生成されたときか、最初に利用可能になったときに関連付けられます。

4.2.10. "atom:rights"要素

"atom:rights"要素は、エントリーやフィードに付随する権利に関する情報を伝えるTextコンストラクトです。

atomRights = element atom:rights { atomTextConstruct }

atom:rights要素は、機械が読める使用許諾情報を伝えるために使うべきではありません。

atom:entryにatom:rights要素がない場合、atom:feed要素のatom:rights要素が各エントリーに適用されることになります。

4.2.11. "atom:source"要素

もしatom:entryを、あるフィードから別のフィードに複製するなら、その元となるatom:feedのメタデータ(atom:entry要素以外のatom:feedのすべての子要素)は、atom:sourceの子要素を追加することで、複製されたエントリー内に維持することができます。もしそれがまだエントリー内に存在しない場合は、atom:source要素の子要素として元となるフィードのメタデータ要素のいくつかまたはすべてを含めます。もし元となるatom:feedが子要素atom:author, atom:contributor, atom:rights, atom:categoryを含み、それらの子要素が元となるatom:entryに存在しないのであれば、そのようなメタデータは保持されるべきです。

atomSource =
    element atom:source {
        atomCommonAttributes,
        (atomAuthor*
          & atomCategory*
          & atomContributor*
          & atomGenerator?
          & atomIcon?
          & atomId?
          & atomLink*
          & atomLogo?
          & atomRights?
          & atomSubtitle?
          & atomTitle?
          & atomUpdated?
          & extensionElement*)
    }

atom:source要素は、エントリーの元となるフィードに関する情報を保持しつつ、違うフィードからエントリーを集約できるよう設計されています。従って、そのような集約を実行しているAtomプロセッサーは、atom:source要素内に、少なくとも、feedレベルの必須メタデータ要素(atom:id, atom:title, atom:updated)を含めるべきです。

4.2.12. "atom:subtitle"要素

"atom:subtitle"要素は、人間が読めるフィードの説明やサブタイトルを伝えるTextコンストラクトです。

atomSubtitle = element atom:subtitle { atomTextConstruct }

4.2.13. "atom:summary"要素

"atom:summary"要素は、エントリーの要約、抜粋、引用を伝えるTextコンストラクトです。

atomSummary = element atom:summary { atomTextConstruct }

atom:summaryに対して、atom:titleやatom:contentを複製することは望ましくありません。なぜなら、Atomプロセッサーは、それらがないときには役に立つ要約があると仮定するからです。

4.2.14. "atom:title"要素

"atom:title"要素は、エントリーやフィードの人間が読めるタイトルを伝えるTextコンストラクトです。

atomTitle = element atom:title { atomTextConstruct }

4.2.15. "atom:updated"要素

"atom:updated"要素は、エントリーやフィードが発行者が重要と考える方法で修正されたそのときの最も直近の時間を示すDateコンストラクトです。それゆえに、すべての修正が必ずしもatom:updatedの値を変更することになるわけではありません。

atomUpdated = element atom:updated { atomDateConstruct }

発行者は、いずれこの要素の値を変更することができます。

5. Atom文書のセキュリティー対策

AtomはXMLベースのフォーマットですので、現存のXMLセキュリティーメカニズムを使って保護することができます。

フィードやエントリーの製作者、そしてフィードやエントリーをアグリゲートする仲介者は、コンテンツに電子署名を入れたり、暗号化したり、そうでなければ保護しないというからには、それなりの確かな理由をもっているでしょう。例えば、販売業者はその商品に対する割引クーポン券を含んでいるメッセージに電子署名を入れるかもしれません。銀行が、顧客に明細書を配信するためにAtomを使うのであれば、彼らの顧客の金融情報を守り、顧客に信頼性を保証するために、それらのメッセージに署名したり暗号化することを強く望むでしょう。仲介者は、受信者がどんなトピックに興味を持つかを傍観者に知られないよう、アグリゲートされたフィードを暗号化したいと思うでしょう。もちろん、他にも多くの例が存在します。

このセクションのアルゴリズム要求事項はAtomプロセッサーに関連するものです。それらは、少なくとも受信者が特定の暗号化アルゴリズムを使うメッセージを取り扱うことができることを要求します。これらの要求事項は、送信者が選択できるアルゴリズムに限定しません。

5.1. 電子署名

Atom文書のルート(つまり、Atomフィード文書のatom:feed, Atomエントリー文書のatom:entry)や、atom:entry要素は、XML-Signature and Syntax Processing [W3C.REC-xmldsig-core-20020212] で説明されているように、エンベロープ署名を持つことができます。

Atomプロセッサーは、署名を含んでいるAtom文書を拒絶してはいけません。なぜなら、Atomプロセッサーは、署名を照合することができないからです。Atomプロセッサーは処理を続けなければいけません。そして、署名を有効にするために、利用者に間違いを通知することができます。

言い換えると、名前空間URI "http://www.w3.org/2000/09/xmldsig#" を持った要素と、文書要素の子要素として"Signature"というローカル名が存在したときには、ただ単にそれがあるという理由で、Atomプロセッサーは失敗を引き起こしてはいけません。

Atom文書の他の要素は、それらの定義がそのような機能を明示的に指定していない限り、署名されてはいけません。

[W3C.REC-xmldsig-core-20020212] のセクション6.5.1は、Canonical XML [W3C.REC-xml-c14n-20010315] をサポートすることを要求します。しかし、多くの実装はそれを使っていません。なぜなら他のXML文書に囲まれた署名XML文書は、それらの署名を壊してしまうからです。それゆえに、署名Atom文書を検証するAtomプロセッサーは、URI "http://www.w3.org/2001/10/xml-exc-c14n#" によって特定される排他的XML正規化メソッドを使って、正規化することができなければいけません。これは、排他的XML正規化 [W3C.REC-xml-exc-c14n-20020718] で規定されています。

アグリゲーターのような仲介者は、atom:source要素を含まないエントリーに、atom:source要素を加える必要があるかもしれません。もしそのようなエントリーが署名されていた場合、追加によって署名を壊してしまうでしょう。それゆえに、個別に著名されたエントリーの発行者は、著名する前にエントリーにatom:source要素を追加することを強く考慮すべきです。実装者もまた、それが正規化で影響しあうように、"xml:"名前空間内のマークアップの利用に関する問題に注意すべきです。

[W3C.REC-xmldsig-core-20020212] のセクション4.4.2は、DSA署名のサポートを要求しており、そして、RSA署名のサポートを推奨しています。しかし、DSAに対してRSAの方が市場における認知度が大きいため、署名されたAtom文書を検証するAtomプロセッサーは、RSA署名を検証することができなければいけません。しかし、DSA署名を検証することができる必要はありません。 メッセージ認証符号(MAC)の認証のための鍵を作る材料が適切に処理されていないと起こる可能性があるセキュリティー問題があるため、Atom文書では署名にMACを使うべきではありません。

5.2. 暗号化

Atom文書のルート(つまり、Atomフィード文書のatom:feedや、Atomエントリー文書のatom:entry)は、XML Encryption Syntax and Processing [W3C.REC-xmlenc-core-20021210] で規定されているメカニズムを使って、暗号化することができます。

[W3C.REC-xmlenc-core-20021210] のセクション5.1は、トリプルDES、AES-128、AES-256のサポートを要求しています。Atom文書を暗号化するAtomプロセッサーは、Cipher Block Chaining (CBC)モードのAES-128を使って複合化することができなければいけません。

[W3C.REC-xmlenc-core-20021210] に基づいた暗号化は、オリジナルの文書の完全性を保証しません。メッセージを複合化することができない誰かが、複合化したメッセージの一部もしくはすべてが、つじつまがあっているが、違う意味を持つような方法で、それでもなおビットを変更することができるという、暗号攻撃が知られています。それゆえに、Atom文書を複合化するAtomプロセッサーは、文書内の署名のハッシュがあればそれを検証する、もしくは文書内の文書のハッシュがあればそれを検証することによって、複合化された文書の完全性をチェックすべきです。

5.3. 署名と暗号化

Atom文書が署名されかつ暗号化されている場合は、その文書を最初に署名し、それから署名された文書を暗号化することが、一般的には良い方法といえます。これは、文書を署名するエンティティーの同一性を含めて、すべての情報を暗号化しながらも、基本の文書に完全性を提供します。もしMACが認証に使われているなら、まず文書を署名し、次に暗号化する順番でなければいけません。その反対ではありませんので、注意してください。

6. Atomの拡張

6.1. Atomではない語彙からの拡張

この仕様は、AtomのXMLマークアップ語彙を記載しています。他の語彙 ("外部マークアップ") をAtom文書内で使うことができます。atom:content要素は、任意の外部マークアップを含めることをサポートするよう設計されています。

6.2. Atomの語彙への拡張

Atomの名前空間は、今後のAtomの改定における上位互換性のために予約されています。この仕様の将来のバージョンでは、Atomマークアップ語彙に新しい要素や属性が追加されるかもしれません。このバージョンの仕様に準拠するよう書かれたソフトウェアは、正確にそのようなマークアップを処理することができず、実際には、それをマークアップエラーと区別することができないでしょう。この議論の目的のために、Atom語彙から認識できないマークアップは、"外部マークアップ"とみなされるでしょう。

6.3. 外部マークアップの処理

本仕様に照らし合わせて正当な場所で外部マークアップに出くわしたAtomプロセッサーは、処理を中断したり、エラーを発してはいけません。それはAtomプロセッサーは外部マークアップを正確に処理することができる場合かもしれません。そうでなければ、そのようなマークアップは"未知の外部マークアップ"と名づけられます。

atom:entryやatom:feedの子要素やPersonコンストラクトに未知のforeign markupが出てきたときには、Atomプロセッサーは、そのマークアップやテキストコンテンツを無視することができます。そしてそのマークアップの存在の結果として、その挙動を変えてはいけません。

Textコンストラクトやatom:content要素に未知のforeign markupが出てきたときには、ソフトウェアはそのマークアップを無視すべきです。そしてあたかも周りのマークアップが存在していなかったかのように、どんな外部要素のテキストコンテンツをも処理すべきです。

6.4. 拡張要素

Atomは、明示的に禁止されていない限り、Atom文書のどこでも外部マークアップを許容します。atom:entry, atom:feed, atom:sourceの子要素やPersonコンストラクトはメタデータ要素とみなされますが、これについては後述します。Personコンストラクトの子要素は、そのコンストラクトに適用されることになります。他の外部マークアップの役割については、この仕様では定義しません。

6.4.1. 単式拡張要素

単式拡張要素は、属性や子要素も持ってはいけません。その要素は、文字データを含むか、もしくは空にすることができます。単式拡張要素は言語依存性があります。

simpleExtensionElement =
    element * - atom:* {
        text
    }

この要素は、それを囲む親要素の単一のプロパティー(またはname/valueのペア)として解釈することができます。その要素の名前空間URIと、その要素のローカル名から成り立つこの組み合わせは、プロパティーの名前として解釈できます。その要素の文字データコンテンツはプロパティーの値として解釈できます。もしその要素が空なら、そのプロパティー値は、空文字として解釈できます。

6.4.2. 構造化拡張要素

構造化拡張要素のルート要素は、少なくとも一つの属性もしくは子要素を持たなければいけません。それは属性を持ってもかまいませんし、整形式XMLコンテンツ(文字データを含む)を含んでもかまいませんし、空でもかまいません。構造化拡張要素は言語依存性があります。

structuredExtensionElement =
    element * - atom:* {
        (attribute * { text }+,
            (text|anyElement)*)
      | (attribute * { text }*,
            (text?, anyElement+, (text|anyElement)*))
    }

構造化拡張要素の構造は、その子要素の順番を含めて、重要です。

この仕様では、構造化拡張要素の説明をしません。要素内に含まれるXMLの構文(そしてその要素が、自身が含んでいる要素とどう関係するのかに関しての説明)は、Atom拡張の仕様によって定義されます。

7. IANAについて

Atom文書は、XML 1.0としてシリアル化されたとき、次のメディアタイプで区別することができます。

MIMEメディアタイプ名:  application
MIMEサブタイプ名:  atom+xml
必須パラメータ:  なし
任意パラメータ:
    "charset": このパラメーターは、[RFC3023] で規定されているのと同じように、
    "application/xml" メディアタイプのcharsetパラメーターと同一の語義を持ちます。
エンコーディングについて: [RFC3023] のセクション3.2に記述されている通り、
    "application/xml"と同じです。
セキュリティーについて: 本仕様にて定義されたとおり。
    加えて、このメディアタイプが"+xml"conventionを使うとき、それは[RFC3023]
    とセクション10で説明されたのと同じセキュリティー考察を共有します。
相互運用性について: 既知の相互運用性問題はありません。
既刊の仕様書:  本仕様書
このメディアタイプを使うアプリケーション: 現在、このメディアタイプを使う
    アプリケーションはありません。

追加情報

Magic number(s):  [RFC3023]のセクション3.2にある"application/xml"
		    に対して規定されている通り。
ファイル拡張子:  .atom
フラグメント識別子:  [RFC3023]のセクション5にある"application/xml"
    に対して規定されている通り。
基本URI:  [RFC3023] セクション6で規定されている通り。
Macintoshファイルタイプコード:  TEXT
詳しくはこちらまで:  Mark Nottingham <mnot@pobox.com>
目的の用途:  COMMON
著者/更新管理者:  IESG

7.1. リンクリレーションの登録

この登録は、IANAによって整備され、冒頭に"alternate", "related", "self", "enclosure", "via"という5つの値を含んでいます。新規の割り当ては、 [RFC2434] で説明されているとおり、IESG承認を条件としています。リクエストは、IANAにemailで送ってください。そのリクエストがIESGへ転送され、承認申請されるでしょう。リクエストの際は、次のテンプレートを使ってください。

8. セキュリティーについて

8.1. HTMLとXHTMLコンテンツ

Textコンストラクトとatom:contentはHTMLとXHTMLの配信を許します。これらの言語の多くの要素は、それらが1つ以上のタイプの攻撃に対してクライアントに開放しているという点では、'安全ではない'と考えられます。Atomを処理するソフトウェアの実装者は、Atom文書内に入ってくる(X)HTMLを処理する際に、あらゆるタイプの要素の取り扱いに十分考慮すべきです。指針として、[RFC2854] と [HTML] をご覧下さい。

AtomプロセッサーはIMG, SCRIPT, EMBED, OBJECT, FRAME, FRAMESET, IFRAME, META, LINK要素のセキュリティーに特別な注意を払うべきです。しかし他の要素も負のセキュリティー特性を持っている恐れがあります。

(X)HTMLは、実行可能コンテンツを、直接的に含むこともでき、間接的に参照することもできるのです。

8.2. URI

AtomプロセッサーはURIを処理します。[RFC3986] のセクション7をご覧下さい。

8.3. IRI

AtomプロセッサーはIRIを処理します。[RFC3987] のセクション8をご覧下さい。

8.4. なりすまし

Atomプロセッサーは、攻撃者が別のフィードからエントリーのatom:id値を持ったatom:entryを発行するといった、なりすまし攻撃の可能性に注意すべきです。恐らく、そのatom:entryは、他のフィードのatom:idを複製した偽造atom:source要素を持っているでしょう。例えば、Atomプロセッサーは、まったく同じatom:id値をもったエントリーのセットから、1つのエントリーだけを表示することによって、二重のエントリーの表示を抑えることがあるでしょう。この状況では、Atomプロセッサーは、そのエントリーが、それらを複製とみなす前に、同じ発行者によるものかどうかを決定するステップを踏むこともあるでしょう。

8.5. 暗号化と署名

Atom文書は、[W3C.REC-xmlenc-core-20021210] と [W3C.REC-xmldsig-core-20020212] を使って、暗号化したり署名したりすることができます。個々に、それらの利用によって暗示されたセキュリティーの考察に制約されます。

電子署名は、認証、メッセージ完全性、そして否認防止を、オリジナルであることの証拠とともに提供します。暗号化はデータの機密性を提供します。

9. リファレンス

9.1. 標準リファレンス

[HTML] Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 Specification", W3C REC REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>.
[MIMEREG] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC 2854, June 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[W3C.REC-xml-20040204]
Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C REC REC-xml-20040204, February 2004,
<http://www.w3.org/TR/2004/REC-xml-20040204>.
[W3C.REC-xml-c14n-20010315]
Boyer, J., "Canonical XML Version 1.0", W3C REC REC-xml-c14n-20010315, March 2001,
<http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
[W3C.REC-xml-exc-c14n-20020718]
Eastlake, D., Boyer, J., and J. Reagle, "Exclusive XML Canonicalization Version 1.0", W3C REC REC-xml-exc-c14n-20020718, July 2002,
<http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718>.
[W3C.REC-xml-infoset-20040204]
Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", W3C REC REC-xml-infoset-20040204, February 2004,
<http://www.w3.org/TR/2004/REC-xml-infoset-20040204>.
[W3C.REC-xml-names-19990114]
Hollander, D., Bray, T., and A. Layman, "Namespaces in XML", W3C REC REC-xml-names-19990114, January 1999,
<http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[W3C.REC-xmlbase-20010627]
Marsh, J., "XML Base", W3C REC REC-xmlbase-20010627, June 2001,
<http://www.w3.org/TR/2001/REC-xmlbase-20010627>.
[W3C.REC-xmldsig-core-20020212]
Solo, D., Reagle, J., and D. Eastlake, "XML-Signature Syntax and Processing", W3C REC REC-xmldsig-core-20020212, February 2002,
<http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.
[W3C.REC-xmlenc-core-20021210]
Reagle, J. and D. Eastlake, "XML Encryption Syntax and Processing", W3C REC REC-xmlenc-core-20021210, December 2002,
<http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>.
[XHTML] Altheim, M., Boumphrey, F., McCarron, S., Dooley, S., Schnitzenbaumer, S., and T. Wugofski, "Modularization of XHTML[TM]", W3C REC REC-xhtml-modularization-20010410, April 2001,
<http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410>.

9.2. 参考リファレンス

[ISO.8601.1988]
International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO Standard 8601, June 1988.
[RELAX-NG] Clark, J., "RELAX NG Compact Syntax", December 2001,
<http://www.oasis-open.org/committees/relax-ng/compact-20021121.html>.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[W3C.NOTE-datetime-19980827]
Wolf, M. and C. Wicksteed, "Date and Time Formats", W3C NOTE NOTE-datetime-19980827, August 1998,
<http://www.w3.org/TR/1998/NOTE-datetime-19980827>.
[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,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

付録 A. 貢献者

Tim Bray, Mark Pilgrim, Sam Rubyは、本文書の準備段階に貢献しました。Norman WalshはRelax NG schemaを提供しました。本仕様書にあるコンテンツとコンセプトは、AtomコミュニティーとAtompubワーキンググループの成果です。

Atompubワーキンググループには、本仕様書のためにアイデアと語法を提案した多数の活動的な貢献者がいます。

Danny Ayers, James Aylett, Roger Benningfield, Arve Bersvendsen, Tim Bray, Dan Brickley, Thomas Broyer, Robin Cover, Bill de hOra, Martin Duerst, Roy Fielding, Joe Gregorio, Bjoern Hoehrmann, Paul Hoffman, Anne van Kesteren, Brett Lindsley, Dare Obasanjo, David Orchard, Aristotle Pagaltzis, John Panzer, Graham Parks, Dave Pawson, Mark Pilgrim, David Powell, Julian Reschke, Phil Ringnalda, Antone Roundy, Sam Ruby, Eric Scheid, Brent Simmons, Henri Sivonen, Ray Slakinski, James Snell, Henry Story, Asbjorn Ulsberg, Walter Underwood, Norman Walsh, Dave Winer, Bob Wyman.

付録 B. RELAX NG Compact Schema

この付録は参考情報です。

Relax NG schemaは、このバージョンの仕様で定義されていないAtom名前空間の要素を、明示的に排除します。そのようなマークアップに出くわすAtomプロセッサーの要求事項は、セクション6.26.3で与えられています。

(以下、省略。以降の省略部分は原文を参照のこと。)

著作権表示全文

Copyright (C) The Internet Society (2005).

この文書は、BCP 78に含まれる権利、許諾、制限に制約されます。ただし、以降の部分を除き、著者が全権利を保有します。

この文書と、それに含む情報は、"現状有姿(AS IS)"で提供されます。貢献者と、彼/彼女が代表するもしくは(もしあれば)資金援助されている組織と、そしてInternet SocietyとInternet Engineering Task Forceは、明示・暗示にかかわらず、ここの情報の使用が、特定用途に対するいかなる権利や暗黙の商品適格性・適合性を侵害していないという、あらゆる保証を含んでいるが限定しないすべての保証を放棄します。

知的所有権

IETFは、いかなる知的所有権や、本文書で説明されている技術の実装や使用に付随すると主張されるかもしれない他の権利や、そのような権利下の許諾が有効か否かの範囲といった、これらの妥当性や範囲に関して、特定の立場を取ることはありません。また、当該の権利を特定するために独自の努力をしたと主張することもありません。RFC文書内の権利についての手続きに関する情報は、BCP 78とBCP 79で見ることができます。

IETF事務局へなされたIPR開示と、利用可能になった許諾のあらゆる保証、または、本仕様の実装者や利用者による当該の独自権利の利用に対する一般的な許諾や承認を得ようとした試みの結果のコピーは、http://www.ietf.org/ipr のthe IETF on-line IPR repositoryで得ることができます。

IETFは、この標準を実装するために必要な技術を保護するかもしれない、あらゆる著作権、特許、特許出願、他の独自の権利が注目されるよう、あらゆる関連団体を招待します。ぜひ、IETF宛に情報をお寄せください。ietf-ipr@ietf.org

謝辞

RFC Editor職務の財政的支援は、現在、Internet Societyによって提供されています。