]>
この文書は「EPUB Open Container Format (OCF) 3.0」を日本語訳したものです。最新の文書は http://www.idpf.org/epub/30/spec/epub30-ocf.html です。原文もしくは最新の情報を参照したい場合は、 EPUB Open Container Format (OCF) 3.0 を参照ください。
この日本語訳は参考です。公式な文書ではありません。翻訳・解釈の正確性を保証しておりません。
1.2. 用語にあげられている名称は本文中でも基本的に原文のままとした。
2011年10月11日 勧告仕様
前回のドラフトからの変更点の差分は、このリンクで入手可能である。
この文書(いくらかの規範的な訂正を含むかもしれない)のために、正誤表を参照されたい。
Copyright © 2010, 2011 International Digital Publishing Forum™
無断複写・転載を禁止する。本作品は合衆国法典第17編の下に保護されている。変更を伴うこの著作物の複製と頒布は、International Digital Publishing Forum (IDPF) の書面による許可を得ない限り禁止されている。
EPUBは International Digital Publishing Forum の登録商標である。
目次
このセクションは参考情報である。
この仕様、EPUB Open Container Format (OCF) 3.0 は、単一ファイルのコンテナに1つ以上の EPUB® Publication を構成する関連リソースのセットをカプセル化するためのファイル形式と処理モデルを定義する。
この仕様は EPUB 3、XML および Web 標準に基づいて、デジタル出版物の交換や配信形式の第 3 版を構成する関連仕様のファミリーの1つである。それは EPUB 3 を構成する他の仕様を読み、調和して理解されることになっている:
EPUB 3 Overview [EPUB3Overview] は EPUB 3 文書の残りの部分に EPUB の有益な概要とロードマップを提供する。EPUB 3 Overview は最初に読んでおくべきである(should)。
EPUB Publications 3.0 [Publications30] は出版レベルのセマンティクスと EPUB Publication のための包括的な適合性要件を定義する。
EPUB Content Documents 3.0 [ContentDocs30] は EPUB Publication のコンテキストで使用するための XHTML、SVG と CSS のプロファイルを定義する。
EPUB Media Overlays 3.0 [MediaOverlays30] はフォーマットとテキストとオーディオの同期のための処理モデルを定義する。
OCF は、EPUB Publication に必要なコンテナ技術である。OCF は、以下のワークフローの役割を果たしてもよい(may):
デジタルの出版物を作り出す準備手順の間に、OCF は、異なる個人と(または)異なる団体の間で進行中の出版物を交換する時に、コンテナフォーマットを使用してもよい(may)。
出版社や変換企業から流通や販売チャンネルまで、デジタルの出版物を提供する場合、OCF は、転送フォーマットとして使用するのに推奨されるコンテナフォーマットである。
EPUB Reading System や User に最終的な出版物を交付する時、OCF は、出版物を構成する資源の全てを保持するコンテナとして必須のフォーマットである。
OCF 仕様書は、抽象的なファイルコレクションを構造化のための規則である“抽象コンテナ”を定義する。それはまた、ZIP アーカイブ内のこの抽象コンテナを表現するための規則である“物理コンテナ”を定義する。ZIP の物理コンテナのための規則は、[ODF] によって使用される ZIP 技術に基いて構築される。OCF は、埋め込んだフォントを難読化をする機能を要求する EPUB Publication のための標準的な手法を定義する。
この仕様は Open Container Format (OCF) 2.0.1 [OCF2] に取って代わる。この仕様書と前身の違いについては [EPUB3Changes] を参照されたい。
(この仕様とその兄弟仕様によって定義されるように)一組の相互関係のあるリソースから成っていて、EPUB Container でパッケージされている論理的な文書のエンティティ。
コンテンツまたは EPUB Publication のロジックと表示に関する命令を含んでいるリソース。このリソースがない場合には、出版物は Author の意図したとおりに表示されないことがある。Publication Resource の例としては Package Document、EPUB Content Document、EPUB Style Sheet、音声、動画、画像、埋め込みフォントとスクリプトが含まれている。
Package Document 自身を除いて Publication Resource が manifest [Publications30] に記載されている必要があり(must)、Publication Resource Locations [Publications30] で特に指定がない限り EPUB container ファイルにバンドルする必要がある。
Publication Resource でないリソースの例としては、Package Document の link [Publications30] 要素で識別されるものと EPUB Container の外で解決するアウトバウンドのハイパーリンクで識別されるものが含まれている。(例えば [HTML5] の a
要素の href
属性)
EPUB Content Document の定義(XHTML または SVG)の1つに従う Publication Resource。
EPUB Content Document は Core Media Type であるためフォールバック [Publications30] を提供することなく、EPUB Publication に含まれていてもよい(may)。
XHTML Content Documents [ContentDocs30] で定義されている [HTML5] のプロファイルに準拠する EPUB Content Document。
XHTML Content Document は、[HTML5] の XHTML syntax を使用する。
SVG Content Documents [ContentDocs30] で表現された制約に準拠した EPUB Content Document。
Publication Resource 型のセットは、それに対するフォールバックは必須ではない。詳細については Publication Resources [Publications30] を参照されたい。
EPUB Publication について Package Documents [Publications30] で定められいる文献の構造化メタデータをもたらしている Publication Resource。
知的内容の作品のデジタル(または物理的)な具体化。大幅な改修、要訳、翻訳または新しい manifestation の結果を別のデジタルや物理的な形状のコンテンツとして実現させるコンテツの変化。"インスタンス"または"アイテム"と呼ばれる manifestation の多くの単一だが、同一の複製であるかもしれない(may)。ISBN は manifestation の識別子の例であり、そしてその manifestation のすべてのインスタンスによって共有される。
manifestation のすべてのインスタンスは、ささいな修正や改訂が新しい manifestation や作業を引き起こすと判断されていないとして、ビット単位で同一である必要はない。
unique-identifier
属性によって識別される Unique Identifier は EPUB Publication のための主要な識別子である。Unique Identifier は一つまたは複数の EPUB standard に従って同じ作品の Manifestation によって共有さるかもしれず(may)、Manifestations の違いが EPUB Reading System と自分自身との違いを考慮し、それらの違いに限定して同じコンテンツを表すには、ISBN の変更が必要になるかもしれない(may)。
Unique Identifier は ISBN よりも細分化される。しかしコンテンツの大幅な見直し、要訳などは新しい Unique Identifier が必要である。
CSS のプロファイルに準拠する CSS スタイルシートは EPUB Style Sheets [ContentDocs30] で定義されている。
EPUB Publication の内容が視覚的に User に与えられる EPUB Reading System の領域。
OCF ZIP コンテナで定義されている EPUB Publication 用 ZIP ベースのパッケージングと配布のフォーマット。
本仕様書に従って EPUB コンテナを処理するソフトウェア・アプリケーション。
EPUB Publication(必ずしも、それが含まれるコンテンツとリソースの作者であるというわけではありません)の制作に対して責任がある人または組織。
EPUB Reading System を使用して EPUB Publication を消費する個人。
この仕様書と兄弟仕様と方法の準拠で User に提示するために EPUB Publication を処理するシステム。
キーワードは"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、そしてこの文書の"OPTIONAL"は [RFC2119] の記述に従って解釈される。
この仕様のすべてのセクションは"このセクションは、有益である"有益なステータスラベルで識別される場合を除き、規範的である。セクションと付録に有益な状態のアプリケーションは、すべての子コンテンツおよびそれに含まれる可能性のサブセクションに適用される。
この仕様のすべての例は有効である。
> OCF 抽象コンテナは、OCF 抽象コンテナで定義された適合性要件を満たさなければならない(must)。
> OCF ZIP コンテナ(また、EPUB Container と呼ばれる)は、OCF ZIP コンテナで定義された適合性要件を満たさなければならない(must)。
EPUB Reading System は、以下の基準全てを満たさなければならない(must):
> それは、OCF ZIP コンテナで表現されたすべての Reading System の適合性要件に適合する OCF ZIP コンテナを処理しなければならない(must)。
> それが Viewport を持つ場合、フォント難読化で定義されたフォントの解読をサポートしなければならない(must)。
このセクションは参考情報である。
OCF 抽象コンテナは、コンテナのコンテンツのためのファイルシステムモデルを定義している。ファイルシステムモデルは、コンテナのコンテンツのすべてに単一の共通のルートディレクトリを使用する。埋め込まれた出版物の(非リモートの)全てのリソースは、特定のファイルシステム構造はこのために強制はされないが、コンテナのルートディレクトリが率いるディレクトリツリー内に配置される。ファイルシステムモデルは、コンテナのルートディレクトリの直接の子で、以下の特別なファイルを補完するに利用する META-INF
という名前の必須ディレクトリを包含する:
container.xml
[必須]
埋め込まれた各出版物のエントリポイントであるファイルを識別する。
signatures.xml
[省略可]
様々な資産のためのデジタル署名が含まれている。
encryption.xml
[省略可]
出版物のリソースの暗号化に関する情報が含まれている。(このファイルは、フォント難読化をする場合には、必要である。)
metadata.xml
[省略可]
コンテナに関するメタデータを格納するために使用する。
rights.xml
[省略可]
デジタル著作権に関する情報を格納するために使用する。
manifest.xml
[許可]
Open Document Format [ODF] によって許可されるコンテナコンテンツのマニフェスト。
META-INF
の各ファイルのための完全な適合性要件は、META-INF にある。
OCF 抽象コンテナのための仮想ファイルシステムは、コンテナのコンテンツのすべてに単一の共通のルートディレクトリを持たなければならない(must)。
OCF 抽象コンテナは、コンテナのルート・ディレクトリの直接の子である META-INF
という名前のディレクトリを包含しなければならない(must)。このディレクトリのコンテンツのための要件は、META-INF に記載されている。
ルートディレクトリにあるファイル名の mimetype
は、OCF ZIP コンテナで説明されているとおり、OCF ZIP コンテナによって使用するために予約済みである。
OCF 抽象コンテナ内の他の全てのファイルは、META-INF
ディレクトリ内を除くコンテナのルートディレクトリから任意の場所の子孫でもよい(may)。
特定の出版物のそれぞれのコンテンツは、コンテナのルート配下の専用のディレクトリに格納されることを推奨する。
OCF 抽象コンテナ内のファイルは、相対 IRI 参照 ([RFC3987] と [RFC3986])経由して相互に参照しなければならない(must)。例えば、chapter1.html
という名前のファイルが、同じディレクトリにある image1.jpg
という名前の画像ファイルを参照する場合、chapter1.html
はそのコンテンツの一部として以下のように含めてもよい(may):
<img src="image1.jpg" alt="…" />
相対 IRI 参照は、ベース IRI [RFC3986] に与えられたファイル形式に関連のある言語仕様によって決定される。例えば、CSS 仕様は、CSS スタイルシートとプロパティ宣言のコンテクストでどのように相対 IRI 参照が動作するのかを定義する。いくつかの言語仕様が、RFC3987 に先行した RFC を参照することに注意されたい。その場合、以前の RFC は、特定の言語でコンテンツに適用される。
ほとんどの言語仕様とは異なり、META-INF
ディレクトリ内の全てのファイルのためのベース IRI は、デフォルトのベース IRI として抽象コンテナのためにルートディレクトリを使用する。例えば、META-INF/container.xml
が以下の内容の場合:
<?xml version="1.0"?> <container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container"> <rootfiles> <rootfile full-path="OEBPS/Great Expectations.opf" media-type="application/oebps-package+xml" /> </rootfiles> </container>
この場合、OEBPS/Great Expectations.opf
のパスは OCF 抽象コンテナのためのルートディレクトリから相対であり、META-INF
ディレクトリからの相対ではない。
File Name
の用語は、ディレクトリまたは OCF 抽象コンテナのディレクトリ内の通常のファイルといった任意の型のファイルの名前を表現する。
OCF 抽象コンテナの特定のディレクトリの場合、パス名
は、ディレクトリのファイル名を分割する /
(U+002F
) 文字と一緒に連結されたフルパス内にすべてのディレクトリのファイル名を保持する文字列である。OCF 抽象コンテナの特定のファイルの場合、パス名は、ディレクトリのファイル名を分割する /
文字と一緒に連結されたすべてのディレクトリのファイル名を保持する文字列に続いて、/
文字とファイルのファイル名となっている。
後に説明するファイル名の制約は、最も一般的に使用されているオペレーティング・システム上で変更なしに使用されているパス名とファイル名を考慮にいれて設計されている。本仕様書は、OCF ファイルとパス名を表すことのできない OCF Processor の相互互換性を補う方法を指定しない。
OCF 抽象コンテナのコンテクストでは、ファイルとパス名は、以下の基準を満たさなければならない(must):
> ファイル名は、255バイトを超えてはならない(must not)。
> 抽象コンテナ内の任意のディレクトリまたはファイルのパス名は、65535バイトを超えてはならない(must not)。
> ファイル名は、これらの文字は、一般的に使用されるオペレーティング・システムの間で一貫してサポートされない場合があり、以下の [Unicode] は使用してはならない(must not):
スラッシュ: /
(U+002F
)
クォーテーションマーク: "
(U+0022
)
アスタリスク: *
(U+002A
)
ピリオド: .
(U+002E
)
コロン: :
(U+003A
)
小なり記号: <
(U+003C
)
大なり記号: >
(U+003E
)
クエスチョンマーク: ?
(U+003F
)
バックスラッシュ: \
(U+005C
)
DEL (U+007F
)
C0 領域 (U+0000 … U+001F
)
C1 領域 (U+0080 … U+009F
)
私用領域 (U+E000 … U+F8FF
)
アラビア表示形Aの非文字 (U+FDDO … U+FDEF
)
特殊用途文字 (U+FFF0 … U+FFFF
)
タグと異体字セレクタ補助 (U+E0000 … U+E0FFF
)
補助私用領域A (U+F0000 … U+FFFFF
)
補助私用領域B (U+100000 … U+10FFFF
)
> ファイル名は、大文字と小文字が区別される。
> 同じディレクトリ内にあるすべてのファイル名は、[Unicode] のセクション 3.13 で定義されているような正規化のケースに従い一意でなければならない(must)。
> 同じディレクトリ内にあるすべてのファイル名は、NFC または NFD の正規化 [TR15] に従い一意であるべきである(should)。
いくつかの商用 ZIP ツールは、完全な Unicode の範囲をサポートしておらず、ファイル名のみ ASCII の範囲のみサポートするかもしれない(may)。これらの制限を持つ ZIP ツールを使うことを望むコンテンツ製作者は、ASCII の範囲にこれらのファイル名を制限することが最善であることに気づくかもしれない(may)。ファイルの名前は、解凍処理の中に保存することができない場合、そのファイルはコンテンツ内のURIにより参照されるときに行われた任意の名前に変換を相殺する必要がある。
全ての OCF 抽象コンテナは、META-INF
というディレクトリを包含しなければならない(must)。このディレクトリは、以下に指定されているファイルを含む。以下に定義されている以外のファイルは、META-INF
ディレクトリに包含してもよく(may)、OCF Processor は、そのようなファイルを検出したときに失敗してはならない(must not)。
全ての OCF コンテナは、META-INF
ディレクトリ内に container.xml
と呼ばれるファイルを包含しなければならない(must)。container.xml
ファイルは、コンテナ内に包含されている EPUB Publication のためのルート・ファイルのメディアタイプとパスを識別しなければならない(must)。
container.xml
ファイルは暗号化してはならない(must not)。
container.xml
ファイルのスキーマは container.xml
のためのスキーマで使用可能で、container.xml
ファイルは、(このような要素のすべての属性と内容を含む)他の名前空間からのすべての要素と属性を除去した後に、このスキーマに応じて妥当でなければならない(must)。
rootfiles
要素は、1つ以上の rootfile
要素を含まなければならず(must)、それぞれは、一意に単一の出版物を表す Package Document を参照しなければならない(must)。OCF に格納されている出版物は、同じ Manifestation の異なるレンダリングであるべきである(should)。
OCF プロセッサは、含まれている出版物のデフォルトのレンダリングを表現するために rootfiles
要素内の最初の rootfile
要素を考慮しなければならない(must)。Reading System は、標準で一つ以外の任意のレンダリングを使用することは必須ではない。
以下のサンプルは、ルートファイルの OEBPS/My Crazy Life.opf
(the Package Document) を持つ EPUB Publication のためのサンプル container.xml
を示している:
<?xml version="1.0"?> <container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container"> <rootfiles> <rootfile full-path="OEBPS/My Crazy Life.opf" media-type="application/oebps-package+xml" /> </rootfiles> </container>
以下のサンプルは、同じコンテナ内にバンドルされている The Sandman の SVG と XHTML による表現を示している:
<?xml version="1.0"?> <container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container"> <rootfiles> <rootfile full-path="SVG/Sandman.opf" media-type="application/oebps-package+xml" /> <rootfile full-path="XHTML/Sandman.opf" media-type="application/oebps-package+xml" /> </rootfiles> </container>
Package Document 内に含まれる manifest
要素は、EPUB の処理に使用される唯一無二のマニフェストを指定する。ZIP アーカイブ内またはオプションの manifest.xml
ファイルに含まれている補助的なマニフェスト情報を、EPUB の処理のために使用してはならない(must not)。ZIP アーカイブ内の任意の追加のファイルは、(すなわち、META-INF
ファイルや出版物の代替の派生した翻訳物のように、Package Document の manifest
要素内にリストされていない ZIP アーカイブ内のファイルは)EPUB Publication の処理に使用してはならない(must not)。
full-path
属性の値は、(RFC3986 で定義されている)path-rootless
のみの形式から得る必要があり、(RFC 3986 で定義されている)path component
を含まなければならない(must)。path component は、それらが使用されているコンテナのルートからの相対パスである。
OCF Processor は container.xml
ファイル内にある外部の要素と属性を無視しなければならない(must)。
コンテナファイルシステムのルートレベルにある META-INF
ディレクトリ内のオプションの encryption.xml
ファイルは、コンテナのコンテンツの全ての暗号化情報を保持する。このファイルは、ルート要素の encryption
の XML 文書である。encryption
要素は、[XML ENC Core] で定義されている EncryptedKey
と EncryptedData
型の子要素を含む。各 EncryptedData
要素は、コンテナ内の一つ以上のファイルを暗号化する方法を説明している。encryption.xml は、リソースが暗号化されていることを示し、それが暗号化されている方法に関する情報を提供する示さなければならない(must)。それ故に、コンテナ内のいずれかのリソースが暗号化されているとき、encryption.xml
は、リソースが暗号化されていることを示し、それが暗号化されている方法に関する情報を提供することを示さなければならない(must)。
EncryptedData
要素が、暗号化された各ファイルを説明するのと同時に、EncryptedKey
要素は、コンテナ内で使用される各暗号化キーを説明する。各 EncryptedData
要素は、XML Encryption で説明されているように、EncryptedKey
要素を参照する。
encryption.xml
のスキーマは、encryption.xml
のためのスキーマを使用でき、encryption.xml
ファイルは、このスキーマに応じて妥当でなければならない(must)。
OCF は、独立して個々のファイルを暗号化し、これらはセキュリティとパフォーマンスのトレードオフだが、コンテナのコンテンツは一つ一つ復号化される。この方法による暗号化は、パッケージ全体のディレクトリの構造とファイルの命名を公開する。
OCF は、様々なアルゴリズムを使用できるように、暗号化のフレームワークを提供する XML Encryption [XML ENC Core] を使用する。XML Encryption は、任意のデータを暗号化し、結果を XML で表現するための処理を規定している。OCF 抽象コンテナは、非 XML データが含まれてもよく(may)、XML Encryption は、OCF 抽象コンテナに含まれるすべてのデータを暗号化するために使用できる。OCF 暗号化は、コンテナ内のファイル全体のみをサポートし、ファイルの一部の暗号化はサポートしない。encryption.xml
ファイルは、(もし存在するなら)暗号化はしてはならない(must not)。
暗号化データは、OCF 抽象コンテナ内の非暗号化データを置き換える。photo.jpeg
という名前の画像が暗号化されているとき、photo.jpeg
リソースのコンテンツは、その暗号化されたコンテンツにより置き換えられるべきである(should)。ZIP コンテナに保持したとき、データのストリームは、暗号化する前に圧縮しなければならず(must)、デフレート圧縮を使用しなければならない(must)。ZIP ディレクトリ内では、暗号化されたフィルは、デフレートで圧縮するよりはむしろ格納するべきである(should)。
状況によっては、EPUB Publication により参照される埋め込みフォントのストレージを難読化して"親"出版物に繋げ、無制限使用のための抽出をより困難にする必要がある。これらのケースでは、encryption.xml
は、フォント難読化に従って必要なフォントのデコード情報を提供するために使用するべきである(should)。
以下のファイルは、デフォルトか特定の暗号化が求められているかどうかに関わらず暗号化してはならない(must):
mimetype |
META-INF/container.xml |
META-INF/encryption.xml |
META-INF/manifest.xml |
META-INF/metadata.xml |
META-INF/rights.xml |
META-INF/signatures.xml |
EPUB rootfile (the Package Document) |
署名済みリソースは、続けて XML 署名復号変換 [XML SIG Decrypt] を使用して暗号化してもよい(may)。この機能は、例えば署名後に暗号化したデータから署名する前に暗号化されたデータを識別する OCF エージェントなどのアプリケーションを可能にする。署名後に暗号化されたデータのみ、署名を検証するために使用する要約を計算する前に複合しなければならない(must)。
次の例では、[XML ENC Core] の Section 2.2.1 から適合したリソース image.jpeg
は、対象鍵アルゴリズム (AES) を使用する暗号化と、対象鍵は、ジョン・スミスのキーを持つ非対称鍵アルゴリズム (RSA) を使用してさらに暗号化される。
<encryption xmlns ="urn:oasis:names:tc:opendocument:xmlns:container" xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <enc:EncryptedKey Id="EK"> <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> <ds:KeyInfo> <ds:KeyName>John Smith</ds:KeyName> </ds:KeyInfo> <enc:CipherData> <enc:CipherValue>xyzabc</enc:CipherValue> </enc:CipherData> </enc:EncryptedKey> <enc:EncryptedData Id="ED1"> <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/> <ds:KeyInfo> <ds:RetrievalMethod URI="#EK" Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/> </ds:KeyInfo> <enc:CipherData> <enc:CipherReference URI="image.jpeg"/> </enc:CipherData> </enc:EncryptedData> </encryption>
manifest.xml
という予約済みの名前を持つオプションのファイルを、コンテナファイルシステムのルートレベルにある META-INF
ディレクトリに包含してもよい(may)。
manifest.xml
は、(ファイルが存在する場合)暗号化してはならない(must not)。
metadata.xml
という予約済みの名前を持つオプションのファイルを、コンテナファイルシステムのルートレベルにある META-INF
ディレクトリに包含してもよい(may)。このファイルは、(もし存在するなら)コンテナレベルのメタデータのために使用しなければならない(must)。OCF 仕様のこのバージョンでは、任意のコンテナレベルのメタデータを指定しない。
META-INF/metadata.xml
ファイルが存在するとき、そのコンテンツは、このファイルの特定のフォーマットを指定する OCF の将来のバージョンとの衝突を回避するため名前空間で装飾された要素 [XMLNS] にするべきである(should)。
metadata.xml
は、(ファイルが存在する場合)暗号化してはならない(must not)。
rights.xml
という予約済みの名前を持つオプションのファイルを、コンテナファイルシステムのルートレベルにある META-INF
ディレクトリに包含してもよい(may)。このファイルは、権利者、仲介者、そして利用者の間で出版物の交換のための信頼できるデジタル著作権管理 (DRM) 情報のために予約されている。OCF 仕様のこのバージョンでは、DRM 情報に必要な形式を指定しないが、将来のバージョンでは、DRM 情報の特定の形式を指定するかもしれない。
META-INF/rights.xml
ファイルが存在するとき、そのコンテンツは、このファイルの特定のフォーマットを指定する OCF の将来のバージョンとの衝突を回避するため名前空間で装飾された要素 [XMLNS] にするべきである(should)。
rights.xml
ファイルは、暗号化してはならない(must not)。
rights.xml
ファイルが存在しないとき、OCF コンテナは、コンテナの任意の部分を示す情報を提供しない権利が抑制される。
コンテナファイルシステムのルートレベルにある META-INF
ディレクトリ内のオプションの signatures.xml
は、コンテナとコンテンツの電子署名を保持する。このファイルは、ルート要素の signatures
の XML 文書である。signatures
要素は、[XML DSIG Core] で定義されている Signature
型の子要素を含んでいる。署名は、出版物と翻訳の全体または一部の出版物と代替えの翻訳に適用できる。XML Signature は、XML だけではなく、あらゆる種類のデータで署名を指定することができる。
signatures.xml
ファイルは、暗号化してはならない(must not)。
signatures.xml
ファイルが存在しないとき、OCF コンテナは、コンテナの任意の部分がコンテナレベルで電子署名されていることを示す情報を提供しない。しかしながら、それは、含まれている任意のオプションの代替え表現内に電子署名が存在している可能性がある。
signatures.xml
ファイルのスキーマは、signatures.xml
のスキーマが利用でき、signatures.xml
ファイルは、このスキーマに応じて妥当でなければならない(must)。
OCF エージェントが、コンテナ内のデータの署名を作るとき、それは、signatures.xml
ファイル内に signatures
要素の最後の子 Signature
要素として新しい署名を加えるべきである(should)。
signatures.xml
ファイルの各 Signature
は、XML Signature の Manifest
要素とその Reference
サブ要素を使用して、IRI の署名が適用されるデータによって識別される。単一で含まれるファイルは、個々にまたは統合して署名してもよい(may)。個々に署名された各ファイルは、独立して検証できるリソースのダイジェスト値が作られる。このアプローチでは、Signature 要素が大きくなってもよい(may)。ファイルが統合して署名されるとき、署名されたファイルのセットは、単一の XML Signature の Manifest
要素のリスト化され、一つ以上の Signature
要素によって参照することができる。
コンテナの任意または全てのファイルは、計算された署名情報を含んでいる signatures.xml
ファイルを除外して、全体を署名することができる。signatures.xml
ファイルを署名するべきか、またその署名方法は、署名者の目的に依存する(should)。
署名者が署名者の署名を無効にせずにコンテナに署名を追加したり削除したりできるようにしたい場合は、signatures.xml
ファイルに署名するべきではない(should not)。
署名者が署名の任意の追加または削除をしたときに署名者の署名を無効にしたい場合は、([XML DSIG Core] のセクション 6.6.4 で定義されている)Enveloped Signature 変換を作成済みの Signature
を除いた全体の既存の署名ファイルに署名するために使用することができる。この変換は、既存の全ての署名を署名できるだろうが、パッケージに後で署名が追加されると無効になる。
署名者が、既存の署名の削除時に署名者の署名を無効にしたいが、署名の追加は許したいとき、既存の署名を署名するのに XPath 変換を使用することができる。(これは単に提案である。特定の XPath 変換は、OCF 仕様書の一部ではない。)
XML-Signature は、署名に任意のセマンティクスを紐付けないが、エージェントが、例えば、署名を表現する Signature 要素に情報を加えることにより、セマンティクスな情報を包含してもよい(may)。XML Signature は、追加情報を、(例えば、SignatureProperties
要素を使うことによる)署名に追加する方法を説明する。
以下の XML 表現は、signatures.xml
フィルの例のコンテンツを示し、[XML DSIG Core] のセクション 2 で見つかるサンプルを基にしている。それはコンテナに、一つの署名を含んでおり、署名は、OEBFPS/book.html
と OEBFPS/images/cover.jpeg
の二つのリソースに提供される。
<signatures xmlns="urn:oasis:names:tc:opendocument:xmlns:container"> <Signature Id="sig" xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> <Reference URI="#Manifest1"> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> </SignedInfo> <SignatureValue>…</SignatureValue> <KeyInfo> <KeyValue> <DSAKeyValue> <P>…</P><Q>…</Q><G>…</G><Y>…</Y> </DSAKeyValue> </KeyValue> </KeyInfo> <Object> <Manifest Id="Manifest1"> <Reference URI="OEBFPS/book.xml"> <Transforms> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue></DigestValue> </Reference> <Reference URI="OEBFPS/images/cover.jpeg"> <Transforms> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue></DigestValue> </Reference> </Manifest> </Object> </Signature> </signatures>
OCF ZIP コンテナは、[ZIP APPNOTE] によって規定されているような ZIP 形式を使用するが、以下の制約と説明に従う:
> OCF ZIP コンテナは、ZIP ファイルが複数のストレージメディアを横断するために分割を許可している ZIP アプリケーションノートの機能を使用してはならない(must not)。OCF Processor は、複数のストレージメディアを横断するよう分割している ZIP ファイルであることが明らかな任意の OCF ファイルをエラーとして処理しなければならない(must)。
> OCF ZIP コンテナは、ZIP アーカイブに非圧縮ファイルかデフレート圧縮ファイルのみ包含しなければならない(must)。OCF Processor は、デフレート以外の圧縮技術を使用している任意の OCF コンテナをエラーとして処理しなければならない(must)。
> OCF ZIP コンテナは、[ZIP APPNOTE] のアプリケーションノートのサブセクション G に、セクション V の "Version 1" として定義されている ZIP64 拡張を使用してもよく(may)、コンテンツがそれらを要求するとき、それらの拡張のみ使用するべきである(should)。OCF Processor は、"Version 1" として定義されている ZIP64 拡張をサポートしなければならない(must)。
> OCF ZIP コンテナは、ZIP フォーマットにより定義された暗号化機能を使用してはならず(must not)、代わりに、暗号化は、暗号化 - META-INF/encryption.xml で説明されている機能を使用しなければならない(must)。OCF Processor は、ZIP 暗号化機能を使用している任意の他の OCF ZIP コンテナをエラーとして処理しなければならない(must)。
> OCF Processor は、OCF 抽象コンテナで定義されていない読み込みと保存の操作を通じて OCF ZIP コンテナからの情報を保つことを要求しない。具体的には、OCF Processor は、特定のオペレーティングシステム(例えば、External file attributes
と Extra field
など)に対応するファイルシステム情報を保持する CRC 値、コメントフィールド、フィールドを保存しない。
> OCF ZIP コンテナは、UTF-8 [Unicode] を使用してファイルシステム名をエンコードしなければならない(must)。
以下の制約は、OCF ZIP コンテナアーカイブ内の特定のフィールドに適用する:
> ローカルファイルヘッダーテーブルでは、OCF ZIP コンテナは、特定のファイルにより必要とされる最大バージョンレベルに合わせるために、version needed to extract
フィールドの値を 10
、20
、45
に設定しなければならない(must)。(例えば、デフレートが必要な場合は 20
、ZIP64 が必要な場合は 45
)。OCF Processor は、他の任意の値をエラーとして処理しなければならない(must)。
> ローカルファイルヘッダーテーブルでは、OCF ZIP コンテナは compression
メソッドフィールドの値を 0
か 8
に設定しなければならない(must)。OCF Processor は、他の任意の値をエラーとして処理しなければならない(must)。
> OCF Processor は、Archive decryption header
または Archive extra data record
を持つ OCF ZIP コンテナをエラーとして処理しなければならない(must)。
OCF ZIP コンテナは、コンテナ内に最初のファイルとして mimetype
ファイルを包含しなければならなず(must)、このファイルのコンテンツは、application/epub+zip
文字列の MIME タイプでなければならない(must)。
mimetype
ファイルのコンテンツは、どんな文字埋めや空白を含んではならず(must not)、Unicode signature (または Byte Order Mark) で開始してはならず(must not)、そしてMIME タイプ 文字列の大文字と小文字は、上記の通り正確でなければならない(must)。さらに mimetype
ファイルは、圧縮で暗号化もしてはならず(must)、そして ZIP ヘッダにエキストラフィールドがあってはならない(must not)。
application/epub+zip
メディアタイプについてのより詳細な情報は 付録 C, application/epub+zip
Media Type を参照されたい。
このセクションは参考情報である。
OCF ZIP コンテナは、基本的に ZIP ファイルなので、一般的に入手可能な ZIP ツールを、パッケージから任意の非暗号化したコンテンツストリームを抽出するのに使用できる。一部のシステムでは、ZIP ファイルのコンテンツは、他の任意のネイティブコンテナ(例えば、フォルダなど)に表示されるかもしれない(may)。これを実現する能力はとても便利だが、サードパーティ製フォントの包含したい Author のために問題を引き起こすことがある。
多くの商業フォントは埋め込みを許可しているが、フォントの埋め込みは、出版物のその重要な部分を形成していることを意味し、コンテンツと一緒にオリジナルフォントファイルは提供しない。統合された ZIP のサポートは、現代的なオペレーティングシステムに偏在しおり、ZIP アーカイブ内に単純に配置したフォントは、他のコンテクストで再利用されることは意図しないフォントであることを意味するには不十分である。この不確定要素は、他の非常に便利な EPUB Publication のフォント埋め込みの機能を弱めることができる。
フォントの再利用を防ぐために、多くのフォントベンダーは、もしそれらのフォントが、出版物に何らかの方法で固定化されている場合、EPUB Publication 内のこれらのフォントの使用を許可するかもしれない(may)。フォントファイルが、コンピュータデバイスの組み込みツールを使ってオペレーショングシステム上で使用するため直接インストールできないならば、他の EPUB Publication によって直接使用することはできない。
フォントファイルのためのデジタル著作権管理や施工システムを提供することはこの文書の範囲を超える。その代わりに、任意の含まれているフォントへの一般的なアクセスを得るための最終的な OCF 受容者側の追加の作業として必要になる難読化の方法を定義する。これは、多くのフォントベンダーの要求を満たすであろうという IDPF の期待である。本文書や IDPF によって作られた要求ではなく、これが暗号化を構成するわけでも、フォントファイルが著作権侵害から安全であることを保証するわけでもない。定義されたメカニズムは、単に提供されたフォントのライセンスの詳細に気付いていない人に障害を提供する。これは、フォントへの完全なアクセスを得ようと考えているユーザーは防げないだろう。OCF コンテナが提供されると、RAW フォントファイルを抽出するために定義したアルゴリズムを適応することが可能である。個々のフォントライセンスの要件を満たすかどうかに関わらず、使用許諾者や被許諾者の課題は残る。
アルゴリズムは、フォントファイルを難読化するために、フォントファイルの最初の 1040 バイト (~1KB) の変更から成る。万一、ファイルが 1040 バイト に満たない場合、ファイル全体が変更される。アルゴリズムのキーは、難読化キーの生成のセクションに指定されている手順を使用して生成される。元データを難読化するのに、RAW ファイルの最初のバイトとキーの最初のバイトの排他的論理和(XOR)の計算の結果は、埋め込まれたフォントファイルの最初のバイトとして格納される。この処理は、キー内の全てのバイトが使用されるまで、ソースとキーの次のバイトで繰り返される。ここで、キーの最初のバイトとソースの 21 バイト目から処理が始まり継続する。1040 バイトがこの方法で(またはソースの終わりに到達して)エンコードされたら、ソース内の残りのデータは、格納先に直接コピーされる。以下が擬似コードにおけるアルゴリズムである:
set source to font file set destination to obfuscated file set keyData to key for font set outer to 0 while outer < 52 and not (source at EOF) set inner to 0 while inner < 20 and not (source at EOF) read 1 byte from source //Assumes read advances file position set sourceByte to result of read set keyByte to byte inner of keyData set obfuscatedByte to (sourceByte XOR keyByte) write obfuscatedByte to destination increment inner end while increment outer end while if not (source at EOF) then read source to EOF write result of read to destination end if
元のフォントデータを得るには、処理は単純に逆になる。つまり、ソースファイルは、難読化データと RAW フォントデータが格納されている格納先のファイルからなる。
難読化アルゴリズムに用いられるキーは、EPUB Publications 3.0 仕様書から要求され、Unique Identifier [Publications30] に詳しく述べられている、コンテナ内にある出版物の一意識別子から得られる。キーを生成するために、コンテナに含まれる全ての出版物の一意識別子は、container.xml
と各識別子の間に挿入されるスペース (Unicode コードポイント U+0020
)に出現する出版物の順番で連結しなければならない(must)この文字列を生成する前に、XML 1.0 仕様書 [XML] のセクション 2.3 によって定義されている全ての空白文字は、個々の識別子から削除される。具体的な Unicode コードポイント U+0020
、U+0009
、U+000D
と U+000A
は、連結されたスペース区切りの文字列を加える前に各識別子から削除しなければならない(must)。この文字列の UTF-8 表現の SHA-1 ダイジェストは、Secure Hash Standard [SHA-1] で規定されているように生成するべきである(should)。このダイジェストは、その後、難読化のアルゴリズムに記載されているアルゴリズムのためのキーとして直接使用される。
全ての OCF 抽象コンテナの暗号化データは、ここに記載されている方法を使用して難読化したフォントを包含する出版物に添付する encryption.xml
ファイル(暗号化 - META-INF/encryption.xml を参照)に記入しなければならない(must)。encryption.xml
ファイル内のそのような難読化したフォントのために、EncryptedData
の子要素である EncryptionMethod
要素は、http://www.idpf.org/2008/embedding
値を持つ Algorithm
属性を持たなければならない(must)。この属性の存在は、本仕様書に記載されているアルゴリズムの使用を示している。このアプローチを使用して難読化された全てのリソースは、CipherData
要素に記載しなければならない(must)。
この encryption.xml
ファイルの例は、次のようになるかもしれない:
<encryption xmlns="urn:oasis:names:tc:opendocument:xmlns:container" xmlns:enc="http://www.w3.org/2001/04/xmlenc#"> <enc:EncryptedData> <enc:EncryptionMethod Algorithm="http://www.idpf.org/2008/embedding"/> <enc:CipherData> <enc:CipherReference URI="OEBPS/Fonts/BKANT.TTF"/> </enc:CipherData> </enc:EncryptedData> </encryption>
他の出版物へ埋め込みフォントのささいな複製を防ぐために、明示的なキーを、encryption.xml
ファイルに提供してはならない(must not)。Reading system は、パッケージの Unique Identifier からキーを得なければならない(must)。
この付録内のスキーマは、規範である。
container.xml
のスキーマcontainer.xml
ファイルのスキーマは、http://www.idpf.org/epub/30/schema/ocf-container-30.rnc が利用可能である。
encryption.xml
のスキーマencryption.xml
ファイルのスキーマは、http://www.idpf.org/epub/30/schema/ocf-encryption-30.rnc が利用可能である。それは、[XML Sec RNG Schemas] のスキーマに基づいている。
signatures.xml
のスキーマsignatures.xml
ファイルのスキーマは、http://www.idpf.org/epub/30/schema/ocf-signatures-30.rnc が利用可能である。それは、[XML Sec RNG Schemas] のスキーマに基づいている。
次の例は、ZIP コンテナ内の署名と暗号化された EPUB Publication を含むための、OCF フォーマットを使用した実例である。
用例 B.1. ZIP コンテナ内ファイルのソートしたリスト
mimetype META-INF/container.xml META-INF/signatures.xml META-INF/encryption.xml OEBPS/As You Like It.opf OEBPS/book.html OEBPS/nav.html OEBPS/toc.ncx OEBPS/images/cover.png
用例 B.3. META-INF/container.xml
ファイルの内容
<?xml version="1.0"?> <container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container"> <rootfiles> <rootfile full-path="OEBPS/As You Like It.opf" media-type="application/oebps-package+xml" /> </rootfiles> </container>
用例 B.4. META-INF/signatures.xml
ファイルの内容
<signatures xmlns="urn:oasis:names:tc:opendocument:xmlns:container"> <Signature Id="AsYouLikeItSignature" xmlns="http://www.w3.org/2000/09/xmldsig#"> <!-- SignedInfo is the information that is actually signed. In this case --> <!-- the SHA1 algorithm is used to sign the canonical form of the XML --> <!-- documents enumerated in the Object element below --> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> <Reference URI="#AsYouLikeIt"> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>…</DigestValue> </Reference> </SignedInfo> <!-- The signed value of the digest above using the DSA algorithm --> <SignatureValue>…</SignatureValue> <!-- The key to use to validate the signature --> <KeyInfo> <KeyValue> <DSAKeyValue> <P>…</P> <Q>…</Q> <G>…</G> <Y>…</Y> </DSAKeyValue> </KeyValue> </KeyInfo> <!-- The list documents to sign. Note that the canonical form of XML --> <!-- documents is signed while the binary form of the other documents --> <!-- is used --> <Object> <Manifest Id="AsYouLikeIt"> <Reference URI="OEBPS/As You Like It.opf"> <Transforms> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue></DigestValue> </Reference> <Reference URI="OEBPS/book.html"> <Transforms> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue></DigestValue> </Reference> <Reference URI="OEBPS/images/cover.png"> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue></DigestValue> </Reference> </Manifest> </Object> </Signature> </signatures>
用例 B.5. META-INF/encryption.xml
ファイルの内容
<?xml version="1.0"?> <encryption xmlns="urn:oasis:names:tc:opendocument:xmlns:container" xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <!-- The RSA encrypted AES-128 symmetric key used to encrypt the data --> <enc:EncryptedKey Id="EK"> <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> <ds:KeyInfo> <ds:KeyName>John Smith</ds:KeyName> </ds:KeyInfo> <enc:CipherData> <enc:CipherValue>xyzabc…</enc:CipherValue> </enc:CipherData> </enc:EncryptedKey> <!-- Each EncryptedData block identifies a single document that has been --> <!-- encrypted using the AES-128 algorithm. The data remains stored in it’s --> <!-- encrypted form in the original file within the container. --> <enc:EncryptedData Id="ED1"> <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/> <ds:KeyInfo> <ds:RetrievalMethod URI="#EK" Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/> </ds:KeyInfo> <enc:CipherData> <enc:CipherReference URI="OEBPS/book.html"/> </enc:CipherData> </enc:EncryptedData> <enc:EncryptedData Id="ED2"> <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/> <ds:KeyInfo> <ds:RetrievalMethod URI="#EK" Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/> </ds:KeyInfo> <enc:CipherData> <enc:CipherReference URI="OEBPS/images/cover.png"/> </enc:CipherData> </enc:EncryptedData> </encryption>
用例 B.6. OEBPS/As You Like It.opf
ファイルの内容
<?xml version="1.0"?> <package version="3.0" xml:lang="en" xmlns="http://www.idpf.org/2007/opf" unique-identifier="pub-id"> <metadata xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:identifier id="pub-id">urn:uuid:B9B412F2-CAAD-4A44-B91F-A375068478A0</dc:identifier> <meta refines="#pub-id" property="identifier-type" scheme="xsd:string">uuid</meta> <dc:language>en</dc:language> <dc:title>As You Like It</dc:title> <dc:creator id="creator">William Shakespeare</dc:creator> <meta refines="#creator" property="role" scheme="marc:relators">aut</meta> <meta property="dcterms:modified">2000-03-24T00:00:00Z</meta> <dc:publisher>Project Gutenberg</dc:publisher> <dc:date>2000-03-24</dc:date> <meta property="dcterms:dateCopyrighted">9999-01-01</meta> <dc:identifier id="isbn13">urn:isbn:9780741014559</dc:identifier> <meta refines="#isbn13" property="identifier-type" scheme="onix:codelist5">15</meta> <dc:identifier id="isbn10">0-7410-1455-6</dc:identifier> <meta refines="#isbn10" property="identifier-type" scheme="onix:codelist5">2</meta> <link rel="xml-signature" href="../META-INF/signatures.xml#AsYouLikeItSignature"/> </metadata> <manifest> <item id="r4915" href="book.html" media-type="application/xhtml+xml"/> <item id="r7184" href="images/cover.png" media-type="image/png"/> <item id="nav" href="nav.html" media-type="application/xhtml+xml" properties="nav"/> <item id="ncx" href="toc.ncx" media-type="application/x-dtbncx+xml"/> </manifest> <spine toc="ncx"> <itemref idref="r4915"/> </spine> </package>
application/epub+zip
メディアタイプこの付録は、EPUB Open Container Format (OCF) のメディアタイプ application/epub+zip
を登録している。
OCF ファイルは、ZIP アーカイブ形式に基づくコンテナの技術である。それは、EPUB Publication とその任意の代替え演出をカプセルに包むために使用する。OCF とその関連規格は、International Digital Publishing Forum (IDPF) によって維持・定義される。
application
epub+zip
なし。
なし。
OCF ファイルは、ZIP (http://www.iana.org/assignments/media-types/application/zip) 形式のバイナリファイルである。
OCF ファイルを読む全てのプロセッサは、検索されたデータのサイズと妥当性を厳密にチェックするべきである(should)。
さらに、OCF ファイルに埋め込むことのできる様々なコンテンツタイプのために、application/epub+zip
が、ここに説明されたものを超えてセキュリティについての暗黙の意味をコンテンツに表現してもよい(may)。けれども、プロセッサが、追加コンテンツまたは他のプロセッサによって送られるコンテツの処理を認識・処理するばあいには、セキュリティの問題は潜在的に生じる。またその場合、それらは、この登録文書の範囲から外れるであろう。
application/zip に適用されるセキュリティの考慮は、OCF ファイルにも適用される。
なし。
このメディアタイプの登録は、http://www.idpf.org/epub/30/spec/epub30-ocf.html にある EPUB Open Container Format (OCF) 3.0 仕様書で説明されている EPUB Open Container Format (OCF) のためのものである。
EPUB OCF 3.0 仕様書は、http://www.idpf.org/doc_library/epub/ocf_2.0.1_draft.doc にあり、application/epub+zip
メディアタイプとして使用する Open Container Format 2.0.1 仕様書に優先する。
このメディアタイプは、EPUB 形式の電子書籍の配布のために広く使われている。以下のアプリケーションのリストは、完全ではない。
Adobe Digital Editions
Aldiko
Azardi
Apple iBooks
Barnes & Noble Nook
Calibre
Google Books
Ibis Reader
MobiPocket reader
Sony Reader
Stanza
0: PK 0x03 0x04
, 30: mimetype
, 38: application/epub+zip
OCF ファイルは、ほとんどの場合、.epub
の拡張として識別される。
ZIP
IDPF は、http://idpf.org/epub/linking/ でリンクしているスキームの登録を維持する。このスキームの一部は、application/epub+zip
と application/oebps-package+xml
文書を解決するカスタムフラグメント識別子を定義している。
William McCoy, bmccoy@idpf.org
COMMON
International Digital Publishing Forum (http://www.idpf.org)
この付録は参考である
EPUB は、出版社、ベンダー、ソフトウェア開発者、および関連する標準規格の専門家を集め、協力的な努力で国際電子出版フォーラム(International Digital Publishing Forum, IDPF) によって開発されました。
EPUB3 仕様は下に述べるリーダーシップにより2010年5月のメンバーシップによって承認された憲章の下で動作し国際電子出版フォーラム(International Digital Publishing Forum, IDPF)の EPUB Maintenance Working Group によって調整した:
ワーキンググループのアクティブメンバー:
IDPF Members
Invited Experts/Observers
より詳細な承認と EPUB の各バージョンへの貢献者については謝辞と貢献者 [EPUB3Overview] を参照されたい。
[ContentDocs30] EPUB Content Documents 3.0 .
[MediaOverlays30] EPUB Media Overlays 3.0 .
[OCF2] Open Container Format 2.0.1 .
[OCF3] Open Container Format 3.0 .
[Publications30] EPUB Publications 3.0 .
[RFC2119] Key words for use in RFCs to Indicate Requirement Levels (RFC 2119) . March 1997.
[RFC3986] Uniform Resource Identifier (URI): Generic Syntax (RFC 3986) . January 2005.
[RFC3987] Internationalized Resource Identifiers (IRIs) (RFC 3987) . January 2005.
[SHA-1] Federal Information Processing Standards Publication 180-3: Secure Hash Standard (SHS) . October 2008.
[TR15] Unicode Normalization Forms . 17 September 2010.
[Unicode] The Unicode Consortium. The Unicode Standard, Version 5.0.0, defined by: The Unicode Standard, Version 5.0 (Boston, MA, Addison-Wesley, 2007. ISBN 0-321-48091-0).
[XML] Extensible Markup Language (XML) 1.0 (Fifth Edition) . 26 November 2008.
[XML DSIG Core] XML-Signature Syntax and Processing Version 1.1 . 3 March 2011.
[XML ENC Core] XML Encryption Syntax and Processing Version 1.1 . 3 March 2011.
[XML SIG Decrypt] Decryption Transform for XML Signature . 10 December 2002.
[XML Sec RNG Schemas] XML Security RELAX NG Schemas .
[XMLNS] Namespaces in XML (Third Edition) . 8 December 2009.
[ZIP APPNOTE] ZIP File Format Specification . September 28, 2007. PKWARE, Inc..
[EPUB3Changes] EPUB 3 Differences from EPUB 2.0.1 .
[EPUB3Overview] EPUB 3 Overview .
[ODF] ODF Open Document Format .