[1] RFC 4287 では、 Atom 1.0 として Atomフィード文書と Atomエントリー文書の2種類の文書を定義しています Atom 1.0 2.。

[2] Atom 0.3 で定義されていた Atomフィード文書は Atomフィード文書に相当します。

[47] RFC 5005 ではAtomフィード文書の集合の分類として、完全フィード、 ページ付けされたフィード、アーカイブされたフィードを定義しています。 アーカイブされたフィードは購読文書とアーカイブ文書によって構成されています。

[3] AtomPub では分類文書とサービス文書の2種類の文書が定義されています AtomPub。

[39] RFC 6721 では削除済みエントリー文書が定義されています。

Atom 文書と XML

[17] Atomフィード文書と Atomエントリー文書は XML 1.0 整形式でなければなりません。 Atom 1.0 2.

[16] AtomPub の XML文書は名前空間整形式でなければなりません AtomPub。

[40] 削除済みエントリー文書は XML 1.0 整形式でなければなりません。 RFC 6721

処理指令と注釈

[44] Atom 1.0 は処理指令と注釈について言及しておらず、Atom文書において利用して良いとも悪いとも明記されていません。

[46] Atom 0.3 では処理指令は原則として利用するべきではない、注釈はどこでも利用してよいと明記されていました >>45。

Atom 文書と XML 保安性

[18] RFC 4287 の 5. では XML の保安性に関する規格との関係が述べられています。 実際には XML の保安性のための仕様は限られた分野でしか使われておらず、 Atom と併用できる実装がどれだけあるのかも不明です。今後これらの規格が普及する見込みもなく、 政治的正当性のために記述を追加しただけかもしれません。

仕様書

  • [20] RFC 4287 - The Atom Syndication Format ( 版) http://tools.ietf.org/html/rfc4287#section-5
  • [41] RFC 6721 - The Atom "deleted-entry" Element ( 版) http://tools.ietf.org/html/rfc6721#section-5

利用例

[19] RFC 4287 の 5. には、割引クーポンをデジタル署名するだとか、 銀行が暗号化するだとか、実際にはとてもありそうにない例がいくつか紹介されています。

デジタル署名

[21] Atom文書の根要素や atom:entry 要素や at:deleted-entry 要素は、 XML署名・構文処理XML-Signature and Syntax Processing仕様書に従い封入署名Enveloped Signatureを有して構いません RFC 4287 5.1., >>41。

[22] Atom処理器は、署名を含む Atom文書や at:deleted-entry 要素を、 署名の検証ができなくても拒絶してはなりません。 処理を継続しなければなりませんし、 署名の検証に失敗したと利用者に通知しても構いません RFC 4287 5.1., >>41。

[23] 言い換えると、名前空間 http://www.w3.org/2000/09/xmldsig#、 局所名 Signature の要素が文書要素の子要素として存在しても、 それだけを理由に処理を止めてはなりません RFC 4287 5.1., >>41。

[24] Atom文書のそれ以外の要素は、特に規定がない限り、署名してはなりません RFC 4287 5.1.。

[25] XML署名・構文処理仕様書の6.5.1節で正準XMLへの対応が義務付けられていますが、 XML文書が署名された上で他の XML文書に含まれていると、 署名された文書の署名が壊れてしまうため、多くの実装はこれを使っていません。 ですから、Atom文書の署名を検証する Atom処理器は、 排他的XML正準化法 排他的XML正準化 (URI http://www.w3.org/2001/10/xml-exc-c14n#) によって正準化することができなければなりません RFC 4287 5.1., >>41。

[26] 集約器などが途中でエントリーに atom:source 要素を追加すると、エントリーや at:deleted-entry 要素の署名は壊れてしまいます。 ですから、各エントリーの出版者が署名する時は予め atom:source 要素を追加しておくことを十分検討するべきです RFC 4287 5.1., >>41。

[27] 実装者は xml 名前空間のマーク付けの利用と正準化の関係にまつわる問題にも気をつけるべきです RFC 4287 5.1., >>41。

[28] XML署名・構文処理仕様書の4.4.2節では DSA署名への対応が要求されると共に RSA署名への対応が推奨されていますが、 RSA の方が DSA よりよく普及していることを鑑みて、 Atom文書の署名を検証する Atom処理器は RSA署名を検証できなければならず、 DSA署名は検証できなくても構いません。

[29] MAC認証の keying material が正しく扱われなかった場合の保安性上の問題を避けるため、 Atom文書では署名に MAC を使うべきではありません RFC 4287 5.1., >>41。

暗号化

[30] Atom文書や削除済みエントリー文書の根要素は、 XML暗号化構文・処理XML Encryption Syntax and Processing仕様書に従い暗号化を行って構いません RFC 4287 5.2., >>41。

[31] XML暗号化構文・処理仕様書の5.1節は TripleDES、AES-128、 AES-256 への対応を義務付けています。 Atom文書を解読する Atom処理器は Cipher Block Chaining (CBC) モードの AES-128 を解読できなければなりません。 RFC 4287 5.2., >>41

[32] XML暗号化構文・処理に基づく暗号化では元の文書の一貫性は保障されません。 メッセージを解読できなくても、解読されたメッセージの一部または全部が異なる意味を成すような変更を行う暗号学的攻撃が知られています。 ですから、Atom文書を解読する Atom処理器は、 文書の署名に含まれるハッシュ値があればそれを検証したり、 文書に含まれる文書のハッシュ値があればそれを検証したりすることで、 解読した文書の一貫性を検査するべきです。 RFC 4287 5.2., >>41

署名と暗号化

[33] Atom文書に署名と暗号化の両方が施されるときは、 普通は文書に署名を加えた上で暗号化するのがいいです。 そうすると暗号化を行いつつもとの文書の一貫性の保証が署名者の識別も含めて行えます。 なお、認証に MAC を用いる場合には、署名の後に暗号化を行い、その逆の順序では行わないようにしなければなりません。 RFC 4287 5.2., >>41

application/atom+xml 媒体型

[34] Atom文書を XML 1.0 で直列化したものは application/atom+xml 媒体型で識別できます RFC 4287 7.。

[4] application/atom+xml は RFC 4287 では Atomフィード文書と Atomエントリー文書の共通の媒体型として規定されていましたが、 実装経験から両者を区別できた方がいいことがあるとわかったため、 type 引数が RFC 5023 で規定されています。 AtomPub

[36]

状態
IETF 提案標準
媒体型
application/atom+xml
拡張子
.atom
Macinroshファイル型
TEXT
素片識別子
application/xml と同じ

仕様書

引数

[51] 次の引数があります。

  • charset
  • kind
  • profile
  • type

charset 引数

[37] charset 引数は application/xml と同じと定義されています RFC 4287 7.。

type 引数

[6] type 引数は、 Atom文書の種類を指定します。

[7] 仕様書: RFC 5023 - The Atom Publishing Protocol ( 版) http://tools.ietf.org/html/rfc5023#section-12.1

引数値

[8] 次の値が定義されています。 AtomPub

entry
Atomエントリー文書を表します。
feed
Atomフィード文書を表します。

[9] 値は大文字・小文字を区別しません。 AtomPub

既定値

[10] この引数が指定されていない場合、型は未指定であり、 実際に根要素を調べる必要があります。 AtomPub

[12] Atomエントリー文書の生産者は、この引数を使うべきです。 AtomPub

処理モデル

[13] type 引数を認識しない Atom処理器は、 根要素によって文書型を決定しなければなりません。 AtomPub

[14] type 引数を認識する Atom処理器は、 根要素と type の不整合を検出し報告するべきです。 AtomPub

関連

[11] 新しい仕様書は type の使用を要求しても構いません。 AtomPub

[42] 削除済みエントリー文書には application/atomdeleted+xml が別途用意されています。

素片識別子

[38] charset 引数は application/xml と同じと定義されています RFC 4287 7.。

Atom 文書でよく用いられる名前空間

Atom 1.0 フィード文書でよく用いられる名前空間

  • 既定名前空間 or atom http://www.w3.org/2005/Atom
  • batch http://schemas.google.com/gdata/batch
  • gCal http://schemas.google.com/gCal/2005
  • gd http://schemas.google.com/g/2005
  • openSearch http://a9.com/-/spec/opensearchrss/1.0/
  • pheedo http://www.pheedo.com/namespace/pheedo
  • xhtml http://www.w3.org/1999/xhtml
  • xml http://www.w3.org/XML/1998/namespace
  • xmlns http://www.w3.org/2000/xmlns/

Atom 1.0 フィード文書で使える名前空間

[15] 複数用例があれば前節に移動する。

  • at http://purl.org/atompub/tombstones/1.0
  • sx http://www.microsoft.com/schemas/sse

Atom 0.3 文書でよく用いられる名前空間

  • 既定名前空間 http://purl.org/atom/ns#]
  • dc http://purl.org/dc/elements/1.1/
    • dc:subject を見かけました。

[43] draft-wilde-atom-profile-02 - Profile Support for the Atom Syndication Format ( ( 版)) http://tools.ietf.org/html/draft-wilde-atom-profile-02

[49] 2.2.5.1 Accept ( ( 版)) http://msdn.microsoft.com/en-us/library/dd541269.aspx

[50] OPDS Catalog 1.1 ( 版) http://opds-spec.org/specs/opds-catalog-1-1-20110627/

Links to Acquisition Feeds SHOULD use the "type" attribute "application/atom+xml;profile=opds-catalog;kind=acquisition".

[52] OPDS Catalog 1.1 ( 版) http://opds-spec.org/specs/opds-catalog-1-1-20110627/#Acquisition_Feeds

Links to Acquisition Feeds SHOULD use the "type" attribute "application/atom+xml;profile=opds-catalog;kind=acquisition".

[53] OPDS Catalog 1.1 ( 版) http://opds-spec.org/specs/opds-catalog-1-1-20110627/#Search

<Url type="application/atom+xml;profile=opds-catalog"

template="http://example.com/search?q={searchTerms}" />

[54] OPDS Catalog 1.1 ( 版) http://opds-spec.org/specs/opds-catalog-1-1-20110627/#The_OPDS_Catalog_Profile_Parameter

Relations to OPDS Catalog Feed Document and OPDS Catalog Entry Document Resources SHOULD use a "profile" parameter following Section 4.3 of [RFC4288] with the value "opds-catalog". This profile parameter provides clients with an advisory hint that the Resource should be a component of an OPDS Catalog.

The complete media type for a relation to an OPDS Catalog Entry Document Resource SHOULD be:

application/atom+xml;type=entry;profile=opds-catalog

The complete media type for a relation to an OPDS Catalog Feed Document Resource SHOULD be:

application/atom+xml;profile=opds-catalog

[55] OPDS Catalog 1.1 ( 版) http://opds-spec.org/specs/opds-catalog-1-1-20110627/#The_OPDS_Kind_Parameter

In addition to the new "profile" parameter, this specification also introduces a new "kind" parameter following Section 4.3 of [RFC4288] with the value "acquisition" or "navigation". This "kind" parameter provides clients with an advisory hint whether the Resource should be an Acquisition Feed or a Navigation Feed.

The complete media type for a relation to an Acquisition Feed SHOULD be:

application/atom+xml;profile=opds-catalog;kind=acquisition

The complete media type for a relation to a Navigation Feed SHOULD be:

application/atom+xml;profile=opds-catalog;kind=navigation

[56] Protocol Summary - Salmon Protocol () http://www.salmon-protocol.org/salmon-protocol-summary

Content-Type: application/atom+xml

<?xml version='1.0' encoding='UTF-8'?>

me:env xmlns:me="http://salmon-protocol.org/ns/magic-env"

    me:data type='application/atom+xml'

[57] EPUB Previews 1.0 () http://www.idpf.org/epub/previews/epub-previews-20150826.html#sec-4

While this relationship value may be used with any potential media type, this specification recommends using either "text/html" for publications that can be acquired in a browser, or "application/atom+xml;type=entry;profile=opds-catalog" for an [OPDS] entry.