Translation:AppendixA/ja

From IDMLWiki

Contents 1 付録A　UCFコンテナフォーマット（UCF Container Format） 1.1 1.1　概要 1.1.1 1.1.1　目的と範囲 1.1.2 1.1.2　用語の定義 1.1.2.1 ASCII 1.1.2.2 IDML 1.1.2.3 IRI 1.1.2.4 UCF 1.1.2.5 UCFコンテナ（UCF Container） 1.1.2.6 UCFユーザーエージェント（UCF User Agent） 1.1.2.7 ODF 1.1.2.8 OEBPS 1.1.2.9 MIME 1.1.2.10 RFC 1.1.2.11 Relax NG 1.1.2.12 Rootfile 1.1.2.13 XML 1.1.2.14 Zip 1.1.3 1.1.3　UCFと他の仕様書との関係 1.1.4 1.2　適合 1.1.5 1.2.1　コンテナの適合 1.1.6 1.2.2　ユーザーエージェントの適合 1.1.7 1.2.3　将来の方向 1.2 1.3　UCFの概要 1.2.1 1.3.1　UCF：一般的なコンテナテクノロジー 1.2.2 1.3.2　「抽象コンテナ」vs.「物理コンテナ」 1.3 1.4　UCFコンテナコンテンツ 1.3.1 1.4.1　ファイルとディレクトリ構造 1.3.2 1.4.2　他のコンポーネントを参照するための相対IRIs 1.3.3 1.4.3　ファイル名 1.3.4 1.4.4　コンテナのメディアタイプを確認 1.3.5 1.4.5　META-INF 1.3.6 1.4.6　コンテナー - META-INF/container.xml（オプション） 1.3.6.1 Rootfiles（オプション） 1.3.6.2 Relationships（オプション） 1.3.6.3 Manifest -- META-INF/manifest.xml（オプション） 1.3.6.4 Metadata -- META-INF/metadata.xml（オプション） 1.3.6.5 デジタル署名 -- META-INF/signatures.xml（オプション） 1.3.6.6 暗号化 -- META-INF/encryption.xml（オプション） 1.3.6.7 著作権管理 -- META-INF/rights.xml（オプション） 1.4 1.5　Zipコンテナ 1.5 1.6　RELAX NG UCFスキーマ 1.6 1.7　UCFとOCFの対比 1.7 1.8　デジタル署名 1.8 1.9　暗号化

付録A　UCFコンテナフォーマット（UCF Container Format）

1.1　概要

1.1.1　目的と範囲

この付録AではUCF（Universal Container Format）について説明します。UCFは汎用コンテナテクノロジーです。それはOCFのパッケージング原理をベースにしたOEBSPコンテナフォーマットです。International Digital Publishing Forum（インターナショナル・デジタル・パブリッシング・フォーラム）によって策定されました。OCFは、OEBPS出版のカプセル化用途において、汎用のコンテナテクノロジーとなります。OCFが汎用のコンテナテクノロジーの先見的存在であり、バンドルアプリケーションで使われている限り、OEBPS上での使用は切り離せなくなっています。この付録Aの目的は、たくさんのアプリケーションが一般的なコンテナフォーマットを使えるようにすることです。

UCFは関連する複数のファイルを、（一般的なコンテナ形式として）ひとつのファイルに集めます。さまざななドキュメントやデータフォーマット、アプリケーションのクラスなどを集めるためにUCFを使用できます。ひとつのファイルであれば、持ち運びや管理、ランダムなアクセスを簡単にします。

UCFはZipアーカイブ（物理コンテナ）の中の個々のファイル（抽象コンテナ）を表すルールを定義します。Zipコンテナのルールは、Open Document Format (ODF) 1.0.との互換性を持っています。

Adobeの全てのZipベースのフォーマットにおいて、UCFはRECOMMENDEDなシングルファイルコンテナ技術です。Zip使用による軽量化、デジタル書名と暗号化オプションなどの特徴を持ちます。UCFベースのファイルがこうしたオプションを持っている場合、そのUCF仕様書に従ってください。たとえば、UCFベースのファイルのすべてがデジタル書名を持っているとは限りませんが、もしそうしたオプションを持っていたとしたら、ちゃんと仕様書に従うべきです。

この付録AはUCF仕様書とOCF仕様書の両方から多くのことを援用しています。IDPFの許可によって、同一言語は可能な限り使用します。AdobeとIDPFは、OCFとオープンドキュメントフォーマットの将来のバージョンとなるOCF（おそらくOpen Container Formatと呼ばれた）に基づく「オープンスタンダードコンテナ形式」を開発するためにOASISでの共同作業を計画しています。

1.1.2　用語の定義

ASCII

ASCII（American Standard Code for Information Interchange）は英文アルファベットを7ビットで符号化したものです（ANSI X3.4-1986）。本書でASCIIと言う時、コード32（10進表記）のスペース文字と、印字可能な「!」コード33（10進表記）から「~」コード126（10進表記）の範囲を指します。

IDML

InDesignドキュメントのXML表現。

IRI

Internationalized Resource Identifier（RFC 3987）

UCF

この付録Aで説明するUniversal Container Format

UCFコンテナ（UCF Container）

この付録Aで説明するUCFのコンテナファイル

UCFユーザーエージェント（UCF User Agent）

ユーザーが利用できるUCFコンテナ中のデータやドキュメントを引き受けるハードウェアと（または）ソフトウェアの組み合わせ。

ODF

Open Document Format（http://www.oasis-open.org/committees/download.php/12572/OpenDocument-v1.0-os.pdf）

OEBPS

Open eBook Publication Structure （http://www.idpf.org/oebps/oebps1.2/index.htm）

MIME

Multipurpose Internet Mail Extensions（RFC 2045）。「MIMEメディアタイプ」はオブジェクトのcontent typeを指定する標準的な方法を提供します。

RFC

本来は字義どおり「Request for Comments」（コメント募集）であったものが、IETF（Internet Engineering Task Force）によって標準化された。

Relax NG

XMLのスキーマ言語（http://www.relaxng.org/）（Relax NG）

Rootfile

パブリケーションのトップレベルファイル；すべてのコンポーネントの根である「root」または全体をカプセル化するひとつのファイル。 OEBPS rootfileはOEBPSパッケージファイルです。 また、PDFを含むPDFファイルはrootfileであるかもしれません。

XML

Extensible Markup Language (http://www.w3.org/TR/xml/)

Zip

事実上の業界標準のデータ圧縮形式（http://www.pkware.com/support/zip-application-note）（ZIP_(ファイルフォーマット)）

1.1.3　UCFと他の仕様書との関係

UCFは他の仕様書のサブセットを組み合わせます。（組み合わせて使用することで）電子化文書の文法や構成、組織化、プレゼンテーション、自明の交換を用意にします：

OEBPSコンテナフォーマット仕様書（http://www.idpf.org/ocf/ocf1.0/）

Zipフォーマット（http://www.pkware.com/support/zip-application-note）

Extensible Markup Language（XML）1.0 (Fourth Edition) 仕様書（http://www.w3.org/TR/xml/）

Namespaces in XML 1.0 (Second Edition) specification（http://www.w3.org/TR/xml-names/）

XML-Signature Syntax and Processing（http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/）

XML Encryption Syntax and Processing（http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/）

Extensible Metadata Platform (XMP)（http://www.adobe.com/products/xmp/）

Unicodeコンソーシアム。Unicode Standard, Version 5.0（Boston, MA, Addison-Wesley, 2007. ISBN 0-321-48091-0）は度々のバージョンアップが公開されています。規格とユニコードキャラクターデータベースのバージョンに関する最新版と追加情報についてはstandard/ http://www.unicode.org/unicode/ standard/を参照してください。

MIMEメディアタイプ（RFC 4288 とhttp://www.iana.org/assignments/media-types/index.html）

Open Document Format for Office Applications (Open Document) v1.0（http://www.oasis-open.org/committees/download.php/12572/OpenDocument-v1.0-os.pdf）

1.2　適合

この文書中の「しなければならない」(MUST)、「してはならない」(MUST NOT)、「必須である」(REQUIRED)、「するものとする」(SHALL)、「しないものとする」(SHALL NOT)、「すべきである」(SHOULD)、「すべきではない」(SHOULD NOT)、「推奨される」(RECOMMENDED)、「してもよい」(MAY)、および「任意である」(OPTIONAL) のキーワードは、RFC 2119 に記述されているとおりに解釈しなければなりません。

• 日本語訳中では、これらのキーワードは太字で示します。

このセクションでは、UCFの適合要件について説明します。

1.2.1　コンテナの適合

用語「Conforming UCF Abstract Container」（UCF抽象コンテナ適合）はUCFの抽象的なコンテナ（セクション2.2を参照）を表し、この仕様書中で定義されている、全ての関連する適合基準を満たします。用語「Conforming UCF Zip Container」（UCF Zipコンテナ適合）はZipアーカイブを表し、Zipコンテナ適合基準（セクション4を参照）とUCF抽象コンテナ適合のインスタンスの実行に適合します。

この仕様書に定義された他の適合基準に加えて、UCF抽象コンテナ適合は下記条件を満たさなければなりません。

• この仕様書で定義されたすべてのXMLファイルは整形式でなければなりません。（XML 1.0の定義による）。
• この仕様書で定義されたすべてのXMLは、XML 1.0（20060816 http://www.w3.org/TR/2006/REC-xml- 20060816）およびXML仕様書（http://www.w3.org/TR/REC-xml-names/）中の名前空間と互換性がなければなりません。
• これらの条件は、この仕様書で定義されないコンテナ中のファイルには当てはまりません（ただし、以下のファイルは除く、container.xml, manifest.xml, metadata.xml, signatures.xml, encryption.xml, and rights.xml）。

1.2.2　ユーザーエージェントの適合

用語「Conforming UCF User Agent」（UCFユーザーエージェント適合）はUCFユーザーエージェントを表し、この仕様書で定義したすべての必須定義をサポートします。

この仕様書のすべての定義をサポートしないUCFユーザーエージェントは、UCFユーザーエージェント適合であることを要求してはなりません。また、サポートする定義についての利用可能なドキュメンテーションを、すすんで提供すべきです。

1.2.3　将来の方向

この仕様書の趣旨は、1.0をリリースすることにより、その次のバージョンがこの仕様書の方向を、特に下記について引き続き定めていくことです。

• この仕様の将来のバージョンが、OASIS/ODFとIDPF/OCFとの連携を改良することへの期待。
• 適切な公式規格の中にないどんな必要な機能性も、適切な標準化団体の最終的なサブミッションと一致する方法で、既存の規格に対する拡張として定義されていくこと。

1.3　UCFの概要

1.3.1　UCF：一般的なコンテナテクノロジー

UCFは一般的なコンテナテクノロジーとして設計されています。特に、UCFはODFの将来のバージョンがUCFを使用できるために、ODF1.0で使用されるコンテナ技術の上位互換になるように設計されています。

1.3.2　「抽象コンテナ」vs.「物理コンテナ」

「抽象コンテナ」はコンテナのコンテンツのためにファイルシステムモデルを定義します。ファイルシステムモデルはコンテナのコンテンツのすべてに対してひとつだけルートディレクトリを持たなければなりません。UCFが必要である特別のファイルは、ルートディレクトリの直下のMETA-INFディレクトリに含まれなければなりません。

「物理コンテナ」は抽象コンテナの物理的表示を保持します。 UCFは以下の2つの物理的なコンテナ技術に、どう抽象コンテンツをマップしなければならないかを定義します:

• ファイルシステムコンテナ -- 特定のプラットフォーム（例えばコンピューターあるいはデータCD上のハードディスク）の記憶媒体の中のファイルシステムの抽象コンテナは、抽象コンテナ中の各ディレクトリとファイルがそれぞれファイルシステム中に表される一対一マッピングでなければなりません。セクション3.3は、現代的なファイルシステムにおいて、保存（格納）を容易にするためのファイルシステム名における１制限を定義します。
• Zipコンテナ -- Zipアーカイブへの抽象コンテナのマッピングについてはセクション4で説明します。

ファイルシステムコンテナかZipコンテナのどちらを使用するかに関わりなく、OCFコンテナのコンテンツはユーザエージェントが両方のタイプの物理コンテナを、問題がないように同じように処理しなければなりません。 どちらの場合も、UCFユーザーエージェントはrootfileを開きます（rootfileからコンテナを処理する方法を決定できます）。

1.4　UCFコンテナコンテンツ

1.4.1　ファイルとディレクトリ構造

UCF「抽象コンテナ」の仮想のファイルシステムには、コンテナのコンテンツのすべてのためにひとつのルートディレクトリがなければなりません。

ルートディレクトリの以下のファイル名は予約されています:

• mimetype
• META-INF

「mimetype」ファイルについてはセクション4で議論します。META-INF/ディレクトリは、UCFによって使用される予約ファイルを含んでいます。予約のファイルについては、次のセクションで説明します。抽象コンテナー内のすべてのファイルは、ルートレベルあるいはMETA-INFディレクトリー内の「mimetype」を除いたルートディレクトリーからの任意の位置（下層）にあってもかまいません。 これらのファイルがMETA-INFの中のサブディレクトリ内にある限り、UCFのベースの形式はMETA-INFディレクトリにファイルを含んでいるかもしれません。これらのサブディレクトリ名には「.」文字を含んではなりません。これは、将来のUCF仕様バージョンでファイルの矛盾を回避します。UCFによって使用されるMETA-INFディレクトリ中のいかなるファイルも「.」文字を含むかもしれません。

複数の表現が使用されている場合、個々のドキュメントあるいはアプリケーションのコンテンツが、ファイル名衝突を最小にするために専用サブディレクトリの中に保存されるか、またはひとつのコンテナに複数のパブリケーションが格納されるよう、将来のUCFバージョンでサポートされることが推奨されます。

1.4.2　他のコンポーネントを参照するための相対IRIs

抽象コンテナ内のファイルは、相対IRI参照（ RFC 3987 , RFC 3986 ）によって参照されます。それが物理コンテナ（ファイルシステムコンテナあるいはZipコンテナ）で使用されていてもかまいません。例えば、「chapter1.html」内で、同じディレクトリ内に位置する画像「image1.jpg」を参照するには下記のようになるでしょう：

相対IRI参照に関して、ベースIRI（ RFC 3986 ）は与えられたフォーマットの適切な言語仕様によって決定します。例えば、CSS仕様ではCSSスタイルシートおよび特性の宣言の文脈で、相対IRI参照がどのように働くか定義します。

多くの言語仕様書と異なり、META-INF/ディレクトリ内のすべてのファイルのベースIRIは、デフォルトベースIRIとして抽象コンテナー用にルートフォルダーを使用します。例えば、META-INF/container.xmlが次の内容を持っている場合:

パス「OEBPS/Great Expectations.opf」は抽象コンテナとしてのルートディレクトリと対応しています。META-INF/ディレクトリには対応していません。

相対IRI参照が絶対パス（IRIはスキーマも権限も持ちませんが、「/」で始まるパス）を含んでいる場合、その参照はルートディレクトリに関連して決定されています。例えば、セクション2.3.1の例では、IRI「/OEBPS/cover.html」は、IRIが存在するかどうかにかかわらずファイルOEBPS/cover.htmlを参照するでしょう。

1.4.3　ファイル名

用語「File Name（ファイル名）」は、抽象コンテナ中のどんなファイル形式（ディレクトリの中のディレクトリか通常ファイルのどちらか）の名前をも表す「用語」です。抽象コンテナ内の与えられたディレクトリについては、すべてのディレクトリ名を束ねたフルパスは「/」文字でディレクトリ名を数珠つなぎにした文字列がパス名です。抽象コンテナ内の与えられたファイルについては、「/」文字に後続するディレクトリ名、そしてファイル名を分離する「/」文字を含めたディレクトリ名をすべて保持する文字列です。下記に示すファイル名制限は、一般的なオペレーティングシステム上で、ディレクトリ名およびファイル名を修正なく使用できることを目指しています。UCF仕様書はUCFを表わせないUCFユーザエージェントがどのようにこの非互換性を補うか明示しません。

次のステートメントは「Conforming UCF Content」に適用されます：

• ファイル名は（以下に示す制限内で）UTF-8エンコーディングでなければなりません
• UTF-8で表した時、ファイル名は255バイトを超えてはなりません
• UTF-8で表した時、抽象コンテナまたはディレクトリ名が65535バイトを超えてはなりません
• ファイル名は下記に示す文字を使用してはなりません（これらの文字は一般的なOSで常にサポートされるとは限りません）
  • 「"」（U+0022）QUOTATION MARK（クォーテーションマーク）
  • 「*」（U+002A）ASTERISK（アスタリスク）
  • 「.」（U+002E）FULL STOP（最後の文字としてのピリオド）
  • 「/」（U+002F）SOLIDUS（スラッシュ）
  • 「:」（U+003A）COLON（コロン）
  • 「<」（U+003C）LESS-THAN SIGN（小なり）
  • 「>」（U+003E）GREATER-THAN SIGN（大なり）
  • 「?」（U+003F）QUESTION MARK（クエスチョンマーク）
  • 「\」（U+005C）REVERSE SOLIDUS（バックスラッシュ）
  • U+0000〜U+001F、U+007F（コントロール文字）
• ファイル名は大文字と小文字を区別します
• 同じディレクトリ内の2つのファイル名が、大文字小文字の正規化（http://www.unicode.org/reports/tr21/tr21-5.html）によってにマップされてはなりません。同じディレクトリ内で、大文字小文字だけが異なるファイル名は禁じられています。
• 同じディレクトリ内の2つのファイル名が、Unicode意味において等しくあってはなりません

Note：いくつかの商業Zipツールが十分なユニコード範囲をサポートせず、ファイル名のためだけのASCII範囲をサポートしているに過ぎないかもしれません。 こうした制限を持っているZipツールを使用したいクリエーターは、ファイル名をASCII範囲に制限するのが最善だと知るかもしれません（MAY）。UnZipプロセス（伸長）時にファイルの名前を保存できない場合、URIによって内容からファイルが示されれば名前翻訳を行う必要があるでしょう。

1.4.4　コンテナのメディアタイプを確認

アプリケーションはファイルのメディアタイプを逐次判断する必要があります。これは通常、ファイルの拡張子を見て判断されます。この方法はファイルの内部を調べることなく迅速な判断ができます。UCFコンテナファイルは特定の拡張子を使用するべきです（SHOULD）。

しかし残念ながら、ファイル拡張子によるファイルの識別は悪名高くあまり信頼できません。ファイル名または拡張子の如何にかかわらずファイルを特定するより強健な方法を持っているのが望ましいです。 このために発展した1つのメカニズムは、特定のファイルオフセットに特定の情報の配置を求めることです。処理エージェントは、ファイルがUCFコンテナの特定のタイプであるかどうかを判断するために固定位置をチェックできます。

Zipアーカイブでこれをするために発展した方法は、Zipアーカイブにおける最初のファイルとして「mimetype」と呼ばれる無圧縮非暗号化されたファイルの包含です。 このファイルの中身はファイルのメディアタイプです。 UCFコンテナはZipアーカイブの最初のファイルとしての「mimetype」ファイルにASCII文字列でメディアタイプを配置しなければなりません（MUST）。 このメカニズムに関する詳細はセクション4を見てください。

1.4.5　META-INF

すべての有効なUCFコンテナーは、コンテナーファイルシステムのルートレベルに「META-INF」と呼ばれるディレクトリーを含んでいるかもしれません（MAY）。このディレクトリーは、コンテンツ、メタデータ、署名、暗号化、権利、パブリケーションに関する情報などが記述されたファイルを含んでいます。

「META-INF/」階層で存在しているかもしれない（MAY）ファイルのセマンテッィク（意味）は指定されています。UCFユーザーエージェント適合は、「META-INF/」階層に見つかった他のすべてのファイルを無視しなければなりません（MUST）。

1.4.6　コンテナー - META-INF/container.xml（オプション）

（これは標準です）

UCFコンテナーは、コンテナーファイルシステムのルートレベルの「META-INF」ディレクトリー内に「container.xml」ファイルを含んでいるかもしれません（MAY）。「container.xml」ファイルが存在する場合、このファイルはMIMEタイプを識別するかもしれないし（MAY）、パス情報やコンテナのルートファイル、コンテナ内の交互の翻訳などを含んでいるかもしれません（MAY）。 UCFベースのフォーマットは、「container.xml」内のルートファイルを識別するか、コンテナの処理を開始する特有の方法を指定しなければなりません（MUST）。セクション3.5.1.2に示すように、「container.xml」ファイルはコンテナ中で暗黙の関係を指定するかもしれません（MAY）。

「container.xml」ファイルを暗号化してはいけません（MUST NOT）。

「container.xml」ファイル（XML）はすべてのエレメントと属性に「urn:oasis:names:tc:opendocument:xmlns:container」名前空間を使用しています。このバージョンに準拠するすべてのコンテナは「version="1.0"」という属性を含まなければなりません（MUST）。

RELAX NG UCFスキーマでは<container>エレメントを「container.xml」のルートエレメントに記述しなければなりません（MUST）。

Rootfiles（オプション）

<rootfiles>エレメントは、少なくとも1つの<rootfile>エレメントを含まなければなりません（MUST）。

各<rootfile>エレメントは、パブリケーションに含まれたただひとつのrootfileを指定します。rootfileはしばしば他のファイル一覧（enumeration）で表されることがあります。

UCFユーザーエージェント適合では、認識されていないエレメント（とコンテンツ）や属性は、container.xmlファイルの中で無視されなければなりません（MUST）。他の名前空間から認識されていないエレメントと属性も含まれます。

container.xmlファイルの適合では、他の名前空間からエレメント（またはその子ノード）と属性のすべての取り除いた後に、ルート要素として<container>を持つRELAX NG UCFスキーマによって妥当でなければなりません（MUST）。

Relationships（オプション）

「Container.xml」は、コンテナー中のファイルの暗黙の関係を識別する情報を含んでいるかもしれません（MAY）。通常、1ファイルは、明示的に別のファイルの参照です。例えば、SVGでのページ記述はイメージに参照を付けるかもしれません。間接的にファイルに参照を付けることは便利な場合があります。例えば、1個のファイルには、2番目のファイルに関連しているメタデータを保存するかもしれません。間接的な連携を使用する時、単にメタデータリソースを作成して、オリジナルのリソースかパッケージの中のどんなリソースも変えないことによってメタデータを加えるのは可能になります。

便宜を越えて、間接的な連携はコンテナファイルに、メタデータまたは注釈のような種類のデータの追加が許されていれば、デジタル署名することができます。例えば、注釈を持たないドキュメントは署名できます。その後、署名を無効にせずに注釈を加えることができます。

UCFは、2個のコンテナァイルの関係を確立するのに総括的なメカニズムを提供します。関係は、ターゲット名のために1セットのソース名から関係タイプとマッピングを指定します。どんなファイルに関しても、関連するファイルを決定するのにこの関係を使用できます。しかしながら、UCFは関連するファイルの存在を必要としません。

<container>ルートエレメントは<relationships>子エレメントを含んでいるかもしれません（MAY）。このエレメントは、特定の関係について記述する1つ以上の<relationships>子エレメントを含んでいるかもしれません（MAY）。各<relationships>エレメントは属性を含んでいます、関係タイプ、ターゲット名をマップするパターンを指定します。タイプは適切な名前です。UCFは1つの関係タイプを定義します、「metadata.」UCFベースフォーマットは、名前空間を指定することによって他のタイプを加えることができます。ターゲットパターンの関係が解決される場合、代用される次の変数を含んでいるかもしれない文字列です：

変数	定義	例
path	リソースのためのフルパス	/a/b/c.d
dir	ディレクトリ（filenameを除く）	/a/b
filename	ディレクトリパスを除いたpath	c.d
basename	拡張子を除いたfilename	c
ext	filenameの拡張子	d

これらの変数は、名前をブレースで囲み「$」とともに開始ブレースで指定します。変数名の後の1文字目が文字でない場合、ブレースは省略されるかもしれません。ターゲットは、パターン中の通常のテキストをコピーして、変数をそれらの値に取り替えることにより解決されます。

コンテナ例のどんなファイルも、「.xmp」拡張子を持つソースファイルと同じ名前の関連メタデータファイルを持つことができます。

Manifest -- META-INF/manifest.xml（オプション）

任意である「manifest.xml」予約ファイルは「META-INF」ディレクトリー内の有効なUCFコンテナのルートレベルに現われるかもしれません（OPTIONAL）。このファイルが存在しているなら、ファイルの内容はODF1.0のマニフェストスキーマで定義されるとおりでなければなりません（MUST）。http://www.oasis-open.org/committees/download.php/12570/OpenDocument-manifest-schema-v1.0-os.rng

「manifest.xml」は暗号化してはなりません（MUST）。

Metadata -- META-INF/metadata.xml（オプション）

「metadata.xml」予約ファイルは「META-INF」ディレクトリー内の有効なUCFコンテナーの、コンテナーファイルシステムのルートレベルに現われるかもしれません。このファイルが存在しているなら、コンテナレベルメタデータにこのファイルを使用しなければなりません（MUST）。OCFのバージョン1.0では、どのようなコンテナレベルメタデータも指定されません。

「META-INF/metadata.xml」ファイルが存在しているなら、コンテンツはnamespacequalifiedエレメントを持ち（OCFの将来のバージョンとの衝突を避けるための）妥当なXMLでなければなりません（MUST）。このファイルの中でエレメントと属性に個別文法と名前空間を指定してもよいでしょう（MAY）。

UCFに基づくAdobe定義のフォーマットは、メタデータを指定するのにXMPを使用しなければなりません（MUST）。http://www.adobe.com/products/xmp/

デジタル署名 -- META-INF/signatures.xml（オプション）

任意である「signatures.xml」ファイルは「META-INF」ディレクトリのコンテナーファイルシステムのルートレベルにあり、コンテナおよびその内容のデジタル署名を持っています。このファイルのコンテンツはUCF1.0の仕様ではありません。しかしながら、UCFの今後の改正でこのファイルのためにフォーマットを定義するでしょう。ありそうな定義に関して付録Dを見てください。

暗号化 -- META-INF/encryption.xml（オプション）

任意である「encryption.xml」ファイルは「META-INF」ディレクトリのコンテナーファイルシステムのルートレベルにあり、コンテナおよびその内容のすべての暗号化情報を持っています。このファイルのコンテンツはUCF1.0の仕様ではありません。しかしながら、UCFの今後の改正でこのファイルのためにフォーマットを定義するでしょう。ありそうな定義に関して付録Eを見てください。

著作権管理 -- META-INF/rights.xml（オプション）

任意である「rights.xml」予約ファイルは「META-INF」ディレクトリ内の有効なUCFコンテナのルートレベルに現われるかもしれません（OPTIONAL）。（信頼あるパブリケーションの交換、著作権保持、仲介人およびユーザーのための）デジタル著作権管理（DRM：digital rights management）情報のために、この場所が確保されています。UCFバージョン1.0では、DRM情報は必須フォーマットではありません（REQUIRED）が、UCF仕様の将来のバージョンは、DRM情報のための特別なフォーマットを指定するかもしれません。

「META-INF/rights.xml」ファイルが存在する場合、使用するXML 名前空間を使った整形式のXMLドキュメントでなければなりません（MUST）。そして、コンテンツは特定の形式を指定してよく（MAY）、UCFの将来のバージョンとの衝突を避ける名前空間で適切なエレメントを持つ妥当なXMLであるべきです（SHOULD）。

「rights.xml」は暗号化されていてはなりません（MUST NOT）。

「rights.xml」ファイルが存在しない場合、UCFコンテナはコンテナのどの部分も著作権管理を示す情報を提供しません。

1.5　Zipコンテナ

UCFのZipコンテナーはhttp://www.pkware.com/support/zip-application-noteの「application note」で指定されるようなZipフォーマットを（下記の範囲で）サポートします。

UCF Zipコンテナ適合では、「application note」中でZipファイルが多数の記憶メディアをまたいで保存する機能を使用してはなりません（MUST NOT）。UCFユーザエージェント適合では、Zipファイルが間違っているとして、記録メディアをまたいで分離していることを明示するすべてのUCFファイルを扱わなければなりません（MUST）。

UCF Zipコンテナコンテナ適合では、Zipアーカイブ内の無圧縮ファイルあるいはFlate圧縮したファイルを単に含んでいなければなりません（MUST）。UCFユーザエージェント適合では、エラー状態でFlateアルゴリズム以外の圧縮技術を使用するすべてのUCFコンテナを扱わなければなりません（MUST）。

UCF Zipコンテナコンテナ適合では、Zip64を使用してもよい（MAY）し、コンテンツが要求するならば、Zip64を使用するべきです（SHOULD）。 UCFユーザエージェント適合では、Zip64はサポートされなければなりません（MUST）。

UCF Zipコンテナコンテナ適合では、Zipフォーマットによって暗号化してはなりません（MUST NOT）：代わりに、暗号化はセクション3.5.5に記述した仕様を使って行われなければなりません（MUST）。UCFユーザエージェント適合では、エラー状態でZip暗号化を使用する他のUCF Zipコンテナを扱わなければなりません（MUST）。

UCFユーザエージェント適合がUCF Zipコンテナからロードと保存処理までの情報を保存するのは、必要要件ではありません。それは、UCF抽象コンテナ中の対応する表現にマップしません。特にUCFユーザエージェント適合はCRC値、コメントフィールド、ファイルシステムに対応する特定のOS（例えば、「External file attributes」や「Extra field」）を保持していません。

UCF Zipコンテナコンテナ適合では、ファイルシステム名にUTF-8エンコーディングにしなければなりません（MUST）。

Zipアーカイブの特別フィールドに関していくつかの詳細を示します：

ローカルファイルヘッダーテーブルでは、UCF Zipコンテナ適合は必要な最大バージョンレベルに合わせるために「version needed to extract」フィールドの値を10、20、45に設定しなければなりません（MUST）。例えば、デフォルトで必要な値は20です。Zip64で必要な値は45です。UCFユーザーエージェント適合では、エラー状態でいかなる値も扱わなければなりません（MUST）。

ローカルファイルヘッダーテーブルでは、UCF Zipコンテナ適合は「compression」メソッドフィールドの値を0か8に設定しなければなりません（MUST）。UCFユーザーエージェント適合では、エラー状態でいかなる値も扱わなければなりません（MUST）。

UCFユーザーエージェント適合では、エラー状態でUCF Zipコンテナ適合の「Archive decryption header」または「Archive extra data record」を信頼しなければなりません（MUST）。

Zipコンテナの最初のファイルは、ZipのMIMEタイプを保持する「mimetype」の ASCII名でなければなりません （MUST）。つまり、「application/epub+zip」のようにゼロパティング、空白文字、大文字小文字の変化がない状態です。このファイルは無圧縮で暗号化もされない'状態でなければなりません（MUST）。また、Zipヘッダのエキストラフィールドが存在してはなりません（MUST NOT）。こうした状態であれば、Zipコンテナは RFC 2048 にあるとおり、便利で有効な「マジックナンバー」をサポートします。

ファイルの始めに、「PK」バイトがあるでしょう。

ポジション30には「mimetype」バイトがあるでしょう。

実際のMIMEの種類（すなわち「application/epub+zip」ASCII文字列）はポジション38から始まるでしょう。

1.6　RELAX NG UCFスキーマ

次の例は、Zipコンテナー内の代替のPDF表現が署名され暗号化されたOEBPSパブリケーションを含むためにこのUCFフォーマットの使用を実証します。

Zipコンテナ内のオーダーリスト：

 mimetype
 META-INF/container.xml
 META-INF/signatures.xml
 META-INF/encryption.xml
 OEBPS/As You Like It.opf
 OEBPS/book.html
 OEBPS/images/cover.png
 PDF/As You Like It.pdf

mimetypeファイル：

 application/epub+zip

META-INF/container.xmlファイル：

META-INF/signatures.xmlファイル：

META-INF/encryption.xmlファイル：

OEBPS/As You Like It.opfファイル：

OEBPS/book.htmlファイル：

このファイルは、暗号化されたバイナリでしょう。復号した内容は次のもののように見えるかもしれません：

OEBPS/images/cover.pngファイル： このファイルの内容はcover.pngファイルの暗号化されたバイナリです。

OEBPS/As You Like It.pdfファイル： このファイルの内容はPDFファイルの暗号化されたバイナリです。

1.7　UCFとOCFの対比

イントロダクションで記述したように、UCFはOEBPS依存性のないOCFです。これらにはいくつかの著しい違いがあります：

OCFの仕様ではコンテナのメディアタイプがapplication/epub+zipでなければならないのに対し、UCFの仕様ではUCFベースのフォーマットが適切なメディアタイプを明示するでしょう。OCFは、Zipベースのフォーマットを識別するよう「+zip」の使用を暗に推奨します。

OCFは、XML 1.1と互換性をもつことをコンテナ中のXMLドキュメントすべてに要求します。UCFは、XML 1.0と互換性をもつことをXMLドキュメントすべてに要求します。 XML1.1に必要でない場合、むしろXML1.0の使用が、一般的な習慣によって推奨されます。

OCFは、名前中の特定の文字を禁止します。さらにUCFは非印字ASCIIコードに対応する文字を禁じます。 OCF仕様書はASCIIの禁止文字名をリストしますが、UCF仕様書ではユニコードポイントをリストします。

OCFは、コンテナー中の2つのファイル名の大文字小文字を正規化した後も一意であることを必要とします。 UCFは、名前がキャラクタ正規化の後にユニコード正規化フォームC（正準な構成での標準的な分解）を使用しても一意であることを必要とします。

OCFはrootfile仕様の次に「container.xml」をリクエストします。 UCFはコンテナ".xml"を必要としません。 原理的に、UCFベースの形式がコンテナを処理し始める方法を指定できるということです。

UCFは、メタデータがコンテナファイルに関連しているかどうかをアプリケーションに依存しない方法で提供して、ファイル関係を追加します。

OCFは「metadata.xml」ファイルの暗号化を禁止しますが、UCFはこれを許容します。 パブリケーションが暗号化（通常デジタル著作権の管理を支援する）で保護される場合さえ、IDPFはリーディングシステムがユーザに有用なメタデータの供給を望みます。 IDML（または他のUCFフォーマット）は、より一般的な要件を持って、コンテナクリエイタのためのオプションとしてこれを残す必要があります。

OCFは、各パブリケーション（ドキュメントかアプリケーションに一般化されたUCF）がコンテナ内のディレクトリに駐在するように推奨しますが、必要要件ではありません。これはコンテナにパブリケーションが多くの表現を含むことを容易にします。

UCF仕様書は暗号化とデジタル署名機能の定義を今後の改正に延期しました。 これは、提案された定義を評価するための多くの時間を与えるためです。

1.8　デジタル署名

UCFのデジタル署名サポートは、今後の仕様改正まで延期されました。 しかしながら、現在の仕様はOCFの仕様と一致するでしょう。以下のとおり：

コンテナファイルシステムのルートレベルにある「META-INF」ディレクトリ内の任意である（OPTIONAL）「signatures.xml」ファイルは、コンテナおよびそのコンテンツのデジタル署名を保持します。このファイルはルートに <signatures>エレメントを持つXMLドキュメントです。「XML-Signature Syntax and Processing」に定義されている通り、<signatures>エレメントはその子要素に<Signature>タイプのエレメントを含んでいます。署名は、パブリケーションや代替表現の全体、または個々の部品に対して適用できます。XML署名は、XMLだけではなく、どんな種類のデータ署名も指定できます。

signatusres.xmlファイルは暗号化してはなりません（MUST NOT）。

signatures.xmlファイルが存在しない場合、UCFコンテナはコンテナレベルのいかなるレベルでもデジタルに署名を示す情報を全く提供しません。 しかしながら、任意のオプションのゆるやかな表現としてデジタル署名が存在することはありえます。

付録Aで説明したとおり、RELAX NG UCFスキーマはsignatures.xmlのルートエレメントあるべき（MUST）<signature>エレメントを見つけるでしょう。

UCFエージェントがコンテナのデータ署名を作成するとき、signatures.xmlファイルの<signatures>エレメントの子要素として<Signature>エレメントに新しい署名を加えるべきです（SHOULD）。

XML署名である<Manifest>エレメントと<Reference>サブエレメントを使用して、signatures.xmlファイル中の各<Signature>エレメントはIRIによって署名が適用されるデータを特定します。個々に含まれるファイルは、別々にあるいは一緒に署名されるかもしれません（MAY）。 各ファイルに別々に署名すると、リソースに対して独自に有効なダイジェスト値が作成されます。このアプローチはシグネチャーエレメントをより大きくするかもしれません（MAY）。 ファイルが一緒に署名されるなら、単一のXML署名<Manifest>エレメントまたはひとつ以上の<Signature>エレメントの参照のファイルをセットします。

コンテナー中のすべてのファイルは、計算された署名情報を含むので、signatures.xmlファイルを除いて、全体の中で署名することができます。 どのようにsignatures.xmlファイルに署名すべきか（SHOULD）は、署名者の目的に左右されます。

コンテナから署名者の署名を無効にすることなく加えられる（または取り除かれる）ことを署名者が認めたければ、signatures.xmlファイルに署名するべきではありません（SHOULD NOT）。

署名者がいかなる追加（あるいは削除）をも署名者の署名を無効にすると望む場合、作成されている<Signature>以外の既存の署名ファイル全体に署名をするために、エンベロープ署名変換（XML署名のセクション6.6.4の中で定義）を使用することができます。 この変換では、すべての既存の署名に署名するでしょう。また、その後の署名がパッケージに追加されるなら、それは無効になるでしょう。

署名者が署名者の署名を無効にして既存の署名の除去（または追加）を望む場合、XPath変換を許可する署名についても取り外しできます。（これは提案にすぎません。 特定のXPath変換はUCF仕様の一部ではありません）

XML署名は署名に意味づけしません。しかしエージェントは意味情報を含めるかもしれません（MAY）、例えば、署名について説明するSignatureエレメントに情報を追加することによって。XML署名は署名にどう追加情報を加えられるかを説明します（例えばSignatureProperties要素を使用することによって）。

（この例は有益です。）

次のXML表現は「signatures.xml」ファイルの内容例を示し、「XML署名シンタックスおよび処理」のセクション2で見た例です。 これはひとつの署名を含んでいて、署名はコンテナ中の2つのリソース（OEBFPS/book.htmlとOEBFPS/images/cover.jpeg）に適用されます。

1.9　暗号化

UCFでの暗号化のサポートは仕様の将来の改正まで延期されました。 下記に示す例外を除いて、この仕様はOCF仕様と一致するでしょう。 例外は、特別のアルゴリズムが暗号化の前にデータのFlate圧縮を要求しないと明示可能であることです。

コンテナーファイルシステムのルートレベルの「META-INF」ディレクトリ内の任意の（OPTIONAL）「encryption.xml」ファイルは、コンテナーのコンテンツの暗号化情報をすべて保持します。 このファイルはそのルートエレメントが<encryption>であるXMLドキュメントです。 XML Encryption Syntax and Processingによって定義されている通り、<encryption>エレメントは <EncryptedKey>と<EncryptedData>の子要素を含んでいます。 各EncryptedKeyエレメントは1個以上のコンテナファイルがどのように暗号化されているかを説明します。 従って、コンテナの中の何かリソースが暗号化されているなら、「encryption.xml」は暗号化しているリソースを示し、それがどう暗号化されているのかを提供しなければなりません（MUST）。

<EncryptedKey>エレメントはコンテナで使用されるそれぞれの暗号化キーについて説明しますが、<EncryptedData>エレメントはそれぞれの暗号化されたファイルについて説明します。 XML暗号化に記述されるように、各<EncryptedData>エレメントは<EncryptedKey>エレメントを参照します。 付録Aで説明したとおり、RELAX NG UCFスキーマでは、<encryption>エレメントはencryption.xmlのルートエレメントでなければなりません（MUST）。

encryption.xmlファイルが存在しない場合、UCFコンテナーはコンテナーのどんな部分が暗号化されるかを示す情報を提供しません。

コンテナコンテンツを漸増的に解読可能にし、性能の向上とセキュリティのトレードオフの中で、UCFは独自に個々のファイルを暗号化します。 この方法での暗号化は、全体のパッケージを指定するディレクトリ構造およびファイルを暴露しています。

UCFは、様々なアルゴリズムを使用可能にして、暗号化フレームワークを供給するためにXML暗号化を使用します。 XML暗号化は、任意のデータを暗号化し、XMLの中で結果を表わす過程を指定します。

UCFコンテナは非XMLデータを含むかもしれません（MAY）が、UCFコンテナのすべてのデータを暗号化するのにXML暗号化を使用できます。 UCF暗号化は全体のファイルの暗号化だけをサポートします。 encryption.xmlファイルは暗号化してはなりません（MUST NOT）。

UCFコンテナの非暗号化データを暗号化データに置き換えます。 例えば、"photo.jpeg"というイメージを暗号化しているなら、photo.jpegリソースのコンテンツを暗号化されたコンテンツに取り替えるべきです（SHOULD）。 Zipコンテナーに格納された時、暗号化される前にファイルを圧縮しなければなりません（Flate圧縮を使用しなければなりません（MUST））。 Zipローカルファイルヘッダーと主要なディレクトリ内では、暗号化ファイルはFlate圧縮ではなく、ファイルは格納されるようにリストされるべきです（SHOULD）。

（デフォルトまたは特定の暗号化が必要かどうかにかかわらず）以下のファイルを決して暗号化してはいけません（MUST）。；

• mimetype
• META-INF/container.xml
• META-INF/manifest.xml
• META-INF/metadata.xml
• META-INF/signatures.xml
• META-INF/encryption.xml
• META-INF/rights.xml

署名されたリソースは、XML署名の復号変換を使って暗号化されるかもしれません（MAY）。 この機能は、UCFエージェントなどのアプリケーションが署名する前に暗号化されたデータを識別できるようになります。 署名を有効にする前にダイジェストの計算をするために、署名後に暗号化されたデータだけが復号されなければなりません（MUST）。

（この例は有益です。）

次の例では、セクション2.2.1「XML暗号化シンタックスおよび処理」を改変して、image.jpegリソースは対称鍵アルゴリズム（AES）とジョン・スミスの非対称鍵アルゴリズム（RSA）の鍵を使って暗号化されます。