[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 では削除済みエントリー文書が定義されています。
[17] Atomフィード文書と Atomエントリー文書は XML 1.0 整形式でなければなりません。 Atom 1.0 2.
[44] Atom 1.0 は処理指令と注釈について言及しておらず、Atom文書において利用して良いとも悪いとも明記されていません。
[46] Atom 0.3 では処理指令は原則として利用するべきではない、注釈はどこでも利用してよいと明記されていました >>45。
[18] RFC 4287 の 5. では XML の保安性に関する規格との関係が述べられています。 実際には XML の保安性のための仕様は限られた分野でしか使われておらず、 Atom と併用できる実装がどれだけあるのかも不明です。今後これらの規格が普及する見込みもなく、 政治的正当性のために記述を追加しただけかもしれません。
[19] RFC 4287 の 5. には、割引クーポンをデジタル署名するだとか、 銀行が暗号化するだとか、実際にはとてもありそうにない例がいくつか紹介されています。
[21] Atom文書の根要素や atom:entry
要素や at:deleted-entry 要素は、
XML署名・構文処理仕様書に従い封入署名を有して構いません
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暗号化構文・処理仕様書に従い暗号化を行って構いません 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
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>
entryfeed[13] type 引数を認識しない Atom処理器は、
根要素によって文書型を決定しなければなりません。
AtomPub
[14] type 引数を認識する Atom処理器は、
根要素と type の不整合を検出し報告するべきです。
AtomPub
[11] 新しい仕様書は type の使用を要求しても構いません。
AtomPub
[42] 削除済みエントリー文書には application/atomdeleted+xml
が別途用意されています。
[38] charset 引数は application/xml
と同じと定義されています RFC 4287 7.。
atom http://www.w3.org/2005/Atombatch http://schemas.google.com/gdata/batchgCal http://schemas.google.com/gCal/2005gd http://schemas.google.com/g/2005openSearch http://a9.com/-/spec/opensearchrss/1.0/pheedo http://www.pheedo.com/namespace/pheedoxhtml http://www.w3.org/1999/xhtmlxml http://www.w3.org/XML/1998/namespacexmlns http://www.w3.org/2000/xmlns/[15] 複数用例があれば前節に移動する。
[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>
Links to Acquisition Feeds SHOULD use the "type" attribute "application/atom+xml;profile=opds-catalog;kind=acquisition".
Links to Acquisition Feeds SHOULD use the "type" attribute "application/atom+xml;profile=opds-catalog;kind=acquisition".
<Url type="application/atom+xml;profile=opds-catalog"
template="http://example.com/search?q={searchTerms}" />
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
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
Content-Type: application/atom+xml
<?xml version='1.0' encoding='UTF-8'?>
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.