Atom Publishing Protocol XML document

Atom Publishing Protocol XML document

[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] AtomPubXML文書名前空間整形式でなければなりません 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 と併用できる実装がどれだけあるのかも不明です。今後これらの規格が普及する見込みもなく、 政治的正当性のために記述を追加しただけかもしれません。

仕様書

利用例

[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節は TripleDESAES-128AES-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+xmlRFC 4287 では Atomフィード文書Atomエントリー文書の共通の媒体型として規定されていましたが、 実装経験から両者を区別できた方がいいことがあるとわかったため、 type 引数RFC 5023 で規定されています。 AtomPub

[36]

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

仕様書

引数

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

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 フィード文書でよく用いられる名前空間

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

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

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

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