WARC_ISO_28500_version1_latestdraft.pdfの機械翻訳を手直ししたものです。
書かれている内容の正確性の保証はありません。

WARCファイルフォーマット

序文

ISO (the International Organization for Standardization) is a worldwide federation of national standards　bodies (ISO member bodies).
The work of preparing International Standards is normally carried out　through ISO technical committees.
Each member body interested in a subject for which a technical　committee has been established has the right to be represented on that committee.
International　organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO　collaborates closely with the International Electrotechnical Commission (IEC) on all matters of　electrotechnical standardization.

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.

The main task of technical committees is to prepare International Standards.
Draft International Standards　adopted by the technical committees are circulated to the member bodies for voting.
Publication as an　International Standard requires approval by at least 75 % of the member bodies casting a vote.

Attention is drawn to the possibility that some of the elements of this document may be the subject of　patent rights.
ISO shall not be held responsible for identifying any or all such patent rights.

ISO/DIS 28500 was prepared by Technical Committee ISO/TC 46, Information and documentation,　Subcommittee SC 4, Technical interoperability.

はじめに

Web sites and web pages emerge and disappear from the world wide web every day.
For the past ten　years, memory organizations have tried to find the most appropriate ways to collect and keep track of this　vast quantity of important material using web-scale tools such as web crawlers.
A web crawler is a　program that browses the web in an automated manner according to a set of policies; starting with a list of　URLs, it saves each page identified by a URL, finds all the hyperlinks in the page (e. g. links to other pages,　images, videos, scripting or style instructions, etc.), and adds them to the list of URLs to visit recursively.
Storing and managing the billions of saved web page objects itself presents a challenge.

At the same time, those same organizations have a rising need to archive large numbers of digital files not　necessarily captured from the web (e.g., entire series of electronic journals, or data generated by　environmental sensing equipment).
A general requirement that appears to be emerging is for a container　format that permits one file simply and safely to carry a very large number of constituent data objects for　the purpose of storage, management, and exchange.
Those data objects (or resources) must be of　unrestricted type (including many binary types for audio, CAD, compressed files, etc.), but fortunately the　container needs only minimal knowledge of the nature of the objects.
The WARC (Web ARChive) file format offers a convention for concatenating multiple resource records　(data objects), each consisting of a set of simple text headers and an arbitrary data block into one long file.

The WARC format is an extension of the ARC File Format ARC that has traditionally been used to store　"web crawls" as sequences of content blocks harvested from the World Wide Web.
Each capture in an　ARC file is preceded by a one-line header that very briefly describes the harvested content and its length.
This is directly followed by the retrieval protocol response messages and content.
The original ARC format　file is used by the Internet Archive (IA) since 1996 for managing billions of objects, and by several national　libraries.

The motivation to extend the ARC format arose from the discussion and experiences of the International　Internet Preservation Consortium (IIPC), whose members include the national libraries of Australia,　Canada, Denmark, Finland, France, Iceland, Italy, Norway, Sweden, The British Library (UK), The Library　of Congress (USA), and the Internet Archive (IA).
The California Digital Library and the Los Alamos　National Laboratory also provided input on extending and generalizing the format.

The WARC format is expected to be a standard way to structure, manage and store billions of resources　collected from the web and elsewhere.
It will be used to build applications for harvesting (such as the open　source Heritrix web crawler), managing, accessing, and exchanging content.
The way WARC files will be　created and resources will be stored and rendered will depend on software and applications　implementations.

Besides the primary content recorded in ARCs, the extended WARC format accommodates related　secondary content, such as assigned metadata, abbreviated duplicate detection events, later-date　transformations, and segmentation of large resources.
The extension may also be useful for more general　applications than web archiving.
To aid the development of tools that are backwards compatible, WARC　content is clearly distinguishable from pre-revision ARC content.

The WARC file format is made sufficiently different from the legacy ARC format files so that software tools　can unambiguously detect and correctly process both WARC and ARC records; given the large amount of　existing archival data in the previous ARC format, it is important that access and use of this legacy not be　interrupted when transitioning to the WARC format.

1 この文書の範囲

この国際規格はWARCファイルフォーマットを定めます：

ペイロードコンテンツとHTTPやDNS、FTPといった一般的なインターネットアプリケーションレイヤープロトコルのコントロール情報の記録
他の記録済みデータ（例：サブジェクト分類、言語判定、エンコーディング）に関連付けられた任意のメタデータの記録
データの圧縮及びデータレコードの完全性維持をサポート
レスポンス情報のみならず、収集プロトコル由来の全てのコントロール情報（例：リクエストヘッダー）の記録
他の記録済みデータに関連付けられたデータ変換結果の記録
他の記録済みデータに関連付けられた重複探知イベントの記録（同一または実質同様のリソースをまとめる）
現在の機能性を損なうことなく拡張
過度に長いレコードを切り捨て、または任意の場所で分割のサポート

2 標準参照

以下に参照した文書はこの文書の適用のために不可欠です。
日付の付いた参照はその版のみが適用されます。
日付の付いていない参照はその最新版の文書（追補を含む）が適用されます。

ARC: Burner, Mike; Kahle, Brewster. - ARC File Format, 15 September 1996; http://www.archive.org/web/researcher/ArcFileFormat.php
W3CDTF: Date and Time Formats: note submitted to the W3C 15 September 1997 (W3C profile of ISO8601). http://www.w3.org/TR/NOTE-datetime
DCMI: DCMI Metadata Terms. http://dublincore.org/documents/dcmi-terms/
RFC1035: Mockapetris, P., “Domain names - implementation and specification,” STD 13, RFC 1035, November 1987. http://www.faqs.org/rfcs/rfc1035.html
RFC1884: Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” RFC 1884, December 1995. http://www.faqs.org/rfcs/rfc1884.html
RFC1950: Deutsch, L. and J-L. Gailly, “ZLIB Compressed Data Format Specification version 3.3,” RFC 1950, May 1996 (TXT, PS, PDF). http://www.faqs.org/rfcs/rfc1950.html
RFC1951: Deutsch, P., “DEFLATE Compressed Data Format Specification version 1.3,” RFC 1951, May 1996 (TXT, PS, PDF). http://www.faqs.org/rfcs/rfc1951.html
RFC1952: Deutsch, P... “GZIP file format specification version 4.3,” RFC 1952, May 1996 (TXT, PS, PDF). http://www.faqs.org/rfcs/rfc1952.html
RFC2045: Freed, N. ; Borenstein, N. “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” RFC 2045, November 1996. http://www.faqs.org/rfcs/rfc2045
RFC2047: Moore, K.. “MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text,” RFC 2047, November 1996 (TXT, HTML, XML). http://www.faqs.org/rfcs/rfc2047
RFC2048: Freed, N.; Klensin, J.,; Postel, J. “Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures,” BCP 13, RFC 2048, November 1996 (TXT, HTML, XML). http://www.faqs.org/rfcs/rfc2048
RFC2119: Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). http://www.faqs.org/rfcs/rfc2119.html
RFC2540: Eastlake, D., “Detached Domain Name System (DNS) Information,” RFC 2540, March 1999. http://www.faqs.org/rfcs/rfc2540.html
RFC2616: Fielding, R.; Gettys, J.; Mogul, J.; Frystyk, H.; Masinter, L.; Leach, P.; Berners-Lee, T. “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2616, June 1999 (TXT, PS, PDF, HTML, XML). http://www.faqs.org/rfcs/rfc2616.html
RFC2822: Resnick, P., “Internet Message Format,” RFC 2822, April 2001. http://www.faqs.org/rfcs/rfc2822
RFC3548: Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” RFC 3548, July 2003. http://www.faqs.org/rfcs/rfc3548.html
RFC3629: Yergeau, F., “UTF-8, a transformation format of ISO 10646”, STD 63, RFC 3629, November 2003. http://www.faqs.org/rfcs/rfc3629.html
RFC3986: Berners-Lee, T.; Fielding, R.; Masinter, L. “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML). http://www.faqs.org/rfcs/rfc3986.html
RFC4027: Josefsson, S., “Domain Name System Media Types,” RFC 4027, April 2005. http://www.faqs.org/rfcs/rfc4027.html
RFC4501: Josefsson, S., “Domain Name System Uniform Resource Identifiers,” RFC 4501, May 2006. http://www.rfc-archive.org/getrfc.php?rfc=4501

3 用語、定義及び略語

3.1 用語及び定義

3.1.1 WARCレコード (WARC record)

WARCファイルの基本的な構成要素で、WARCレコードの配列からなります。

3.1.2 WARCレコードコンテンツブロック (WARC record content block)

WARCレコードの一部（0以上のオクテット）で、ヘッダーとレコードの本体が続きます。

3.1.3 WARCレコードペイロード (WARC record payload)

データオブジェクトがWARCレコードのコンテンツブロックの有意のサブセットとして参照、または含まれます。

3.1.4 WARCレコードヘッダー (WARC record header)

WARCレコードの始まりで、レコードがWARCフォーマットであることを示す一行（バージョン番号が与えられる）からなります。
次の行から名前フィールドが空白行まで続きます。

3.1.5 WARC名前付きフィールド (WARC named fields)

名前、コロン、値からなる要素の集合です。
長い値はインデントされた行に続きます。

3.1.6 WARC論理レコード (WARC logical record)

セグメンテーションの文脈では、論理レコードは複数のセグメントで構成されるかもしれません。
それぞれはWARCレコードで表されます。

3.2 略語

ABNF: 拡張バッカス・ナウア記法 (Augmented Backus-Naur Form)
ARC: ARChive
CRLF: Carriage Return Line Feed
HTTP: HyperText Transport Protocol
IANA: Internet Assigned Numbers Authority
IESG: Internet Engineering Steering Group
RFC: Request For Comments
UR(I/L/N): Uniform Resource (Identifier/Locator/Name)
WARC: Web ARChive

4 ファイル及びレコードモデル

WARCフォーマットファイルは1つ以上のWARCレコードを単純に結合したものです。
最初のレコードは通常、続くレコードの説明です。
一般に、レコードの内容は収集結果──ウェブページ、インラインイメージ、URLリダイレクト情報、DNSホスト名解決結果、独立したファイル等──またはアーカイブされたコンテンツに関する追加情報を提供する統合材料（例：メタデータ、変換したコンテンツ）のいずれかです。

WARCレコードはレコードコンテンツブロックと2つの改行が続いたレコードヘッダーからならなければなりません。
WARCレコードヘッダーは与えられるバージョン番号でWARC形式のレコードを宣言する先頭行と、その後空白行で終了する可変長行の名前付きフィールドから構成されなければなりません。
一つの主な例外として、UTF-8 RFC3629を許可して、WARCレコードヘッダー形式は大部分の伝統的な HTTP/1.1 RFC2616とRFC2822ヘッダーに従います。

WARCファイルのトップレベルビューとして、HTTP/1.1 RFC2616 section 2.1の定義を再利用し、拡張バッカス・ナウア記法(BNF)構文で表すことができます。
（具体的には、RFC2616ルールと同じ名前を持つWARCルールがある場合、混乱を防ぐために定義を同じにしています。ただし、CHARルールを除きます。WARCはUTF-8マルチバイト文字を含みます。）

warc-file   = 1*warc-record
warc-record = header CRLF
              block CRLF CRLF
header      = version warc-fields
version     = "WARC/1.0" CRLF
warc-fields = *named-field CRLF
block       = *OCTET

レコードバージョンは全てのレコードの最初に表示されなければなりません。従って、WARCファイル自身も同様になります。

WARCレコードは名前付きフィールドに大きく依存します。
それぞれの名前付きフィールドは名前、コロン(:)、フィールド値からなります。
フィールド名は大文字と小文字を区別しません。
フィールド値は単一のスペースが好まれるものの、複数の空白（LWS）であることもできます。
ヘッダーフィールドは少なくとも1つのスペース、またはタブ文字を各行の前に付けることで複数行に拡張することができます。

名前付きフィールドは任意の順序で現れることがあり、フィールド値にはUTF-8文字が含まれることがあります。
定義されたフィールド、拡張されたフィールドのどちらも、一般的な名前付きフィールドに従ってください。
拡張されたフィールドは、コア形式の拡張に使用することができます。

named-field   = field-name ":" [ field-value ]
field-name    = token
field-value   = *( field-content | LWS )    ; フィールド定義で
                                            ; さらに限定される
field-content = <field-valueを構成するOCTETと、TEXTまたはtoken、
                separators、quoted-stringの組み合わせで構成される。>
OCTET         = <任意の8-bitのデータ>
token         = 1*<CTLやseparatorsを除く
                任意のUS-ASCII文字>
separators    = "(" | ")" | "<" | ">" | "@"
                   | "," | ";" | ":" | "\" | <">
                   | "/" | "[" | "]" | "?" | "="
                   | "{" | "}" | SP | HT
TEXT          = <CTLを除くがLWSを含む任意のOCTET>
CHAR          = <UTF-8 文字; RFC3629>       ; (0-191, 194-244)
DIGIT         = <任意のUS-ASCII数字 "0".."9">
CTL           = <任意のUS-ASCII制御文字
                (octets 0 - 31) と DEL (127)>
CR            = <ASCII CR, キャリッジリターン>  ; (13)
LF            = <ASCII LF, ラインフィード>     ; (10)
SP            = <ASCII SP, 空白文字>        ; (32)
HT            = <ASCII HT, 水平タブ>         ; (9)
CRLF          = CR LF
LWS           = [CRLF] 1*( SP | HT )        ; 単一のSPと同じ意味
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext        = <<">を除く、任意のTEXT>
quoted-pair   = "\" CHAR                    ; 引用文字
uri           = "<" <RFC3986の'URI'> ">"

UTF-8文字が許可されていますが、WARCフィールドを読み書きする場合にRFC2047の'encoded-word'メカニズムを使用することもできます。

残りのWARCレコード構文は、レコード識別子、レコードタイプ、作成時刻、コンテンツ長、コンテンツタイプといったdefined-fieldパラメータに関わるものです。

defined-field = WARC-Type
              | WARC-Record-ID
              | WARC-Date
              | Content-Length
              | Content-Type
              | WARC-Concurrent-To
              | WARC-Block-Digest
              | WARC-Payload-Digest
              | WARC-IP-Address
              | WARC-Refers-To
              | WARC-Target-URI
              | WARC-Truncated
              | WARC-Warcinfo-ID
              | WARC-Filename                ; warcinfo のみ
              | WARC-Profile                 ; revisit のみ
              | WARC-Identified-Payload-Type
              | WARC-Segment-Origin-ID       ; continuation のみ
              | WARC-Segment-Number
              | WARC-Segment-Total-Length    ; continuation のみ

全てのWARCレコードはWARC-Typeフィールドで報告される型を持たなければなりません。
WARCレコード型は8つあります： 'warcinfo', 'response', 'resource', 'request', 'metadata', 'revisit', 'conversion', 'continuation'です。
各レコード型に関連するフィールドがこの後のWARCレコード型で記載されています。
各フィールドの意味と有効な値の形式は名前付きフィールドに記載されています。

オクテットコンテンツを持たなければならないレコードブロックは、レコードタイプと他のヘッダー値を基に解釈します。
全てのレコードはブロック長を定めるContent-Lengthフィールドを含まなければなりません。

いくつかのレコード型（そしておそらく将来のレコード型）も、先行レコードやブロックの有意のサブセットとしてペイロードを定義します。
いくつかのヘッダーは直接的にブロックに関連付けられるよりもレコードのペイロードに関連付けられます。

例えば、'response'レコードはHTTPヘッダーとデータオブジェクトからなるコンテンツブロックとペイロードはデータオブジェクトになります。
全ての'response'、'resource'、'request'、'conversion'、そして'continuation'レコードはペイロードを持っているかもしれません。
全ての'warcinfo'、'metadata'、そして'revisit'レコードはペイロードを持っていてはいけません。

warc-fileルールに一致するコンテンツは、section 8.2で登録されるMIME Content-Type "application/warc"を持たなければなりません。

warc-fieldsルールに一致するコンテンツは、単純な記述フォーマットとして有用であり、section 8.3で登録されるMIME Content-Type "application/warc-fields"を持っています。

5 名前付きフィールド

5.1 概略

WARCレコード内の名前付きフィールドは現在のレコードについての情報を提供し、レコード単位の情報追加を可能にします。
WARCは他の標準の適切なヘッダーを再利用し、また、WARC特有の用途のために"WARC-"で始まる新しいヘッダーを定める。

同じタイプのWARC名前付きフィールドは注釈されない限り（例：WARC-Concurrent-To）、同じWARCレコード内で繰り返されるべきではありません。
（例えば、WARCレコードは複数個のWARC-Dateや複数個のWARC-Target-URIを持っていてはなりません。）

新しいフィールドは、基となるWARCフォーマットを拡張して定義される可能性があるため、WARC処理ソフトウェアは認識できない名前を持つフィールドを無視しなければなりません。

5.2 WARC-Record-ID （必須）

現在のレコードに割り当てられた、使用目的の期間内グローバルに一意な識別子。
この仕様では識別子スキームは規定しないが、各レコードIDは明確に文書化されたことを示し、登録されたスキームに従う有効なURIでなければなりません。
（例えば、"http:"や"urn:"のようなURIスキーム接頭辞を介して）
この値には空白文字が含まれないことが保証されるよう注意しなければなりません。

WARC-Record-ID = "WARC-Record-ID" ":" uri

全てのレコードはWARC-Record-IDフィールドを持たなければなりません。

5.3 Content-Length （必須）

RFC2616と同様のブロック内のオクテット数。
もしブロックが存在しないのであれば、値は'0'（ゼロ）が使用されなければなりません。

Content-Length = "Content-Length" ":" 1*DIGIT

全てのレコードはContent-Lengthフィールドを持たなければなりません。

5.4 WARC-Date （必須）

ISO8601 W3CDTFのW3Cプロファイルに記載されたYYYY-MM-DDThh:mm:ssZ形式に従った14桁のUTCタイムスタンプ。
タイムスタンプはレコード作成のためのデータ取得が始まった瞬間を意味しなければなりません。
単一の記録イベントの部分となる複数のレコード（[section 5.7]参照）の書き込み時刻と正確に同期していなかったとしても、同じWARC-Dateを使用しなければなりません。

WARC-Date   = "WARC-Date" ":" w3c-iso8601
w3c-iso8601 = <YYYY-MM-DDThh:mm:ssZ>

全てのレコードはWARC-Dateフィールドを持たなければなりません。

5.5 WARC-Type （必須）

WARCレコードのタイプ： 'warcinfo', 'response', 'resource', 'request', 'metadata', 'revisit', 'conversion', 'continuation'のうちのどれかひとつ。
コアフォーマットを拡張してWARCレコードの他のタイプを定義してもよいです。
タイプはこの先のWARCレコードタイプに記載されています。

WARCファイルには特定のレコードタイプが含まれている必要はありませんが、全てのWARCファイルは"warcinfo"レコードで始まることが推奨されています。

WARC-Type   = "WARC-Type" ":" record-type
record-type = "warcinfo" | "response" | "resource"
            | "request" | "metadata" | "revisit"
            | "conversion" | "continuation" | future-type
future-type = token

全てのレコードはWARC-Typeフィールドを持たなければなりません。

WARC処理ソフトは認識できないタイプのレコードを無視しなければなりません。

5.6 Content-Type

レコードのブロックに含まれる情報のMIMEタイプRFC2045です。
例えば、HTTPリクエストとレスポンスレコードの場合、RFC2616のsection 19.1により'application/http'（もしくはそれぞれ'application/http; msgtype=request'と'application/http; msgtype=response'）になるでしょう。
具体的には、Content-TypeはフルアーカイブのHTTPメッセージのMIMEタイプを記述するものであって、HTTPレスポンスのHTTP Content-Typeヘッダーの値ではありません。

Content-Type = "Content-Type" ":" media-type
media-type   = type "/" subtype *( ";" parameter )
type         = token
subtype      = token
parameter    = attribute "=" value
attribute    = token
value        = token | quoted-string

'continuation'レコードを除く、空ではないブロックを持つ（Content-Lengthがゼロではない）全てのレコードはContent-Typeフィールドを持たなければなりません。
メディアタイプがContent-Typeフィールドを与えられなかった場合にのみ、リーダーはコンテンツかリソース識別子に使用されているURIの名前拡張子（の両方）を調べてメディアタイプの推測を試みても構いません。
メディアタイプがなお不明である場合、リーダーは"application/octet-stream"タイプとして扱うべきです。

5.7 WARC-Concurrent-To

現在のレコードと同じキャプチャーイベントの一部として作成された全てのレコードのWARC-Record-IDです。
キャプチャーイベントは単一のターゲットURIを背景とする検索によって自動的に収集された情報を含みます。
例えば、'request'レコードに関連付けられて'response'や'revisit'レコードに表されることがあります。

WARC-Concurrent-To = "WARC-Concurrent-To" ":" uri

このフィールドは単一のキャプチャーイベントから発生した場合、'request', 'response', 'resource', 'metadata', 'revisit'タイプのレコードと他の一つを関連付けて使用することができます。
（そのように使用する場合、任意のWARC-Concurrent-Toの関連はヘッダーが単一のレコードのみに現れたとしても双方向とみなさなければなりません。）
WARC-Concurrent-Toフィールドは'warcinfo', 'conversion', 'continuation'レコード内に使用してはなりません。

概略の例外として、同じWARCレコード内でいくつかのWARC-Concurrent-Toフィールドを繰り返すことが許可されます。

5.8 WARC-Block-Digest

アルゴリズム名とレコードのブロック全体から算出したダイジェスト値を示すオプションのパラメータです。

WARC-Block-Digest = "WARC-Block-Digest" ":" labelled-digest
labelled-digest   = algorithm ":" digest-value
algorithm         = token
digest-value      = token

次の例はSHA-1標識化されたBase32(RFC3548)値です：

WARC-Block-Digest: sha1:AB2CD3EF4GH5IJ6KL7MN8OPQ

この文書は特定のアルゴリズムを推奨しません。

すべてのレコードもWARC-Block-Digestフィールドを持ってもよいです。

5.9 WARC-Payload-Digest

アルゴリズム名とレコードに参照されるか含まれるペイロードから算出されたダイジェスト値を示すオプションのパラメータです。
これは必ずしもレコードブロックと同値になるわけではありません。

WARC-Payload-Digest = "WARC-Payload-Digest" ":" labelled-digest

次の例はSHA-1標識化されたBase32(RFC3548)値です：

WARC-Payload-Digest: sha1:3EF4GH5IJ6KL7MN8OPQAB2CD

この文書は特定のアルゴリズムを推奨しません。
application/httpブロックのペイロードは'entity-body'（RFC2616）です。
WARC-Block-Digestとは対照的に、WARC-Payload-Digestフィールドは現在のレコードブロック内に実際に存在しないデータのために使用することができます。
例えば、ブロックが'revisit'プロファイル（'revisit'参照）に従って中断された場合やレコードがセグメント化されたとき。

WARC-Payload-Digestフィールドは明確に定義されたペイロードを持つWARCレコードに使用することができ、名確に定義されたペイロードのないレコードに使用してはなりません。

5.10 WARC-IP-Address

任意のコンテンツ収集のために接続したインターネットアドレス数値です。
IPv4アドレスは"ドットで区切った4つ"形式で、IPv6アドレスはRFC1884形式でかかれなければなりません。
HTTP収集の場合、レコードのターゲットURIのホスト名に該当する収集時刻におけるIPアドレスになるでしょう。

WARC-IP-Address = "WARC-IP-Address" ":" (ipv4 | ipv6)
ipv4            = <"dotted quad">
ipv6            = <per section 2.2 of RFC1884>

WARC-IP-Addressは'response', 'resource', 'request', 'metadata', 'revisit'レコードに使用することができ、‘warcinfo’, 'conversion', 'continuation'レコードなどには使用してはなりません。

5.11 WARC-Refers-To

レコードが保持する追加コンテンツを表す単一のレコードのWARC-Record-IDです。

WARC-Refers-To = "WARC-Refers-To" ":" uri

WARC-Refers-Toフィールドは他のレコードに'metadata'レコードを関連付けるために使用することができます。
また、WARC-Refers-Toフィールドは'revisit'や'conversion'レコードを先行するレコードに関連付けるために使用することができます。これは現在のレコードの内容を決定する助けとなります。
WARC-Refers-Toフィールドは'warcinfo', 'response', ‘resource’, 'request', 'continuation'レコード内に使用してはなりません。

5.12 WARC-Target-URI

このレコードの情報コンテンツを生じさせたオリジナルURIです。
Web収集においては、クローラーの収集要求の対象となったURIです。
'revisit'レコードの場合、収集リクエストの対象となったURIです。
'metadata'や'conversion'のような間接的なレコードの場合、新しいレコードが属する元のレコードに現れるWARC-Target-URIのコピーです。
この値のURIはRFC3986に従って適切にエスケープされ、内部に空白を含まないでかかれなければなりません。

WARC-Target-URI = "WARC-Target-URI" ":" uri

全ての'response', 'resource', 'request', 'revisit', ‘conversion’, 'continuation'レコードはWARC-Target-URIフィールドを持たなければなりません。
'metadata'レコードはWARC-Target-URIフィールドを持つことができます。
'warcinfo'レコードはWARC-Target-URIフィールドを持つことはできません。

5.13 WARC-Truncated

実用的な理由から、WARC形式の生成器はアーカイブする単一のリソースに割り当てる時間やストレージに制限を設けることができます。
その結果、オリジナルのリソースから切りだされた部分のみ、WARCレコードに保存するために利用することができます。
すべてのレコードで、その内容ブロックの切り捨てが発生したこととその理由をWARC-Truncatedフィールドにより示すことができます。

WARC-Truncated = "WARC-Truncated" ":" reason-token
reason-token   = "length"            ; 設定された最大長を超えています
               | "time"              ; 設定された最大時間を超えた
               | "disconnect"        ; ネットワークが切断されました
               | "unspecified"       ; 他の/不明な理由
               | future-reason
future-reason  = token

例えば、数ギガバイトのリソースのように見えるもののキャプチャーが短縮された場合、部分的なリソースをこのフィールドと共にWARCレコードに保存することができます。

WARC-Truncatedフィールドは全てのWARCレコードに使用することができます。
WARCフィールドのContent-Lengthはレコードブロックの実際に確保されたサイズを示さなければなりません。

5.14 WARC-Warcinfo-ID

これが存在する場合、このレコードと関連付けられた'warcinfo'レコードのWARC-Record-IDを示します。
一般的に、WARC-Warcinfo-IDパラメータは、個別のレコードをWARCファイルに分離して配布した後など、適用できる'warcinfo'レコードが利用できない場合に使用されます。
（Webクローラーといった）WARC生成アプリケーションはこのパラメータを記録することを選択することができます。

WARC-Warcinfo-ID = "WARC-Warcinfo-ID" ":" uri

WARC-Warcinfo-IDフィールドの値は、（WARC内で）前もって現れている'warcinfo'レコードとの関連付けを上書きします。従って、レコードが異なるWARCから合成された時、正しい関連付けを保護する方法を提供します。

WARC-Warcinfo-IDフィールドは'warcinfo'を除く全てのレコードタイプで使用することができます。

5.15 WARC-Filename

現在の'warcinfo'レコードのファイル名が入る。

WARC-Filename = "WARC-Filename" ":" ( TEXT | quoted-string )

WARC-Filenameフィールドは'warcinfo'タイプレコードで使用することができ、他のレコードタイプで使用してはなりません。

5.16 WARC-Profile

'revisit'レコードで解析や取り扱いの種類を示すURI。
（XML名前空間のようにURIは人間が読み取り可能、または機械が読み取り可能な文書を返すことが望まれるが必須ではない。）
読み取りソフトは取り扱いの種類のサポートとして与えられたURIを認識できない場合、関連するレコードブロックを解釈しないものとします。

WARC-Profile = "WARC-Profile" ":" uri

'revisit'セクションで'revisit'レコードのWARC-Profileのために2つの初期プロファイルを定義します。
WARC-Profileフィールドは'revisit'タイプレコードで必須で、他のレコードタイプでは未定義です。

5.17 WARC-Identified-Payload-Type

独立した検査によって決定されるレコードのペイロードのContent-Type。
この文字列はペイロードを直接分析することなく、レコードブロックからのHTTPのContent-Type値をWARCヘッダーにしてはなりません。（多くの場合信頼できない場合があるため）

WARC-Identified-Payload-Type = "WARC-Identified-Payload-Type" ":"
                               media-type

WARC-Identified-Payload-Typeフィールドは明確に定義されたペイロードを持つレコードで使用することができ、明確に定義されたペイロードなしにレコードに使用してはなりません。

5.18 WARC-Segment-Number

セグメント化されたレコードシークエンスにおける現在のレコードの相対順序を報告します。

WARC-Segment-Number = "WARC-Segment-Number" ":" 1*DIGIT

全てのレコードの最初のセグメント、すなわち完了したひとつ以上の'continuation'WARCレコードでこのパラメータは必須です。
その値は"1"です。
'continuation'レコードではこのパラメータが必須です。
その値はそれぞれ次のセグメントごとに1増加し、論理レコード全体における現在のセグメントのシークエンス番号になります。

以下のセクション、レコードセグメンテーションに使い方の完全な詳細があります。

5.19 WARC-Segment-Origin-ID

論理的に完全なコンテントブロックを得るために再構成する、セグメント化された一連のレコードの開始レコードの識別子です。

WARC-Segment-Origin-ID = "WARC-Segment-Origin-ID" ":" uri

このフィールドは全ての'continuation'レコードで必須で、他のレコードでは使用してはなりません。
以下のセクション、レコードセグメンテーションに使い方の完全な詳細があります。

5.20 WARC-Segment-Total-Length

セグメント化された一連の最後のレコードで、全てのセグメントのコンテンツブロックを結合した時の長さの合計を報告します。

WARC-Segment-Total-Length = "WARC-Segment-Total-Length" ":"
                            1*DIGIT

このフィールドは一連の最後の'continuation'レコードで必須で、他の場所で使用してはなりません。
以下のセクション、レコードセグメンテーションに使い方の完全な詳細があります。

6 WARCレコードタイプ

6.1 概略

定義されたレコードタイプの目的と使用を以下に説明します。

WARCフォーマットを拡張する新しいレコードタイプが将来の標準で定められる可能性があるため、WARC処理ソフトウェアは不明なタイプのレコードをスキップしなければなりません。

6.2 'warcinfo'

'warcinfo'レコードはファイルの終わり、入力の終わり、または次の'warcinfo'レコードまでの間、それに続くレコードを記述します。
典型的にはこれはWARCファイルの先頭に一度だけ現れます。
Webアーカイブ目的では、多くの場合、続くレコードを生成したWebクロールに関する情報が含まれています。

"application/warc-fields"コンテンツタイプの使用が推奨されていますが、この記述レコードブロックのフォーマットは異なる場合があります。
許容されるフィールドが含まれますが、これに限定されず、すべてのDCMIに加えて以下のフィールドが定義されます。
全てのフィールドはオプションです。

'operator'
: このWARCリソースを作成した操作者に連絡するための情報です。
名前、または名前とメールアドレスが推奨されます。

'software'
: このWARCリソースを作成したソフトウェアとソフトウェアバージョンです。
例えば、"heritrix/1.12.0"です。

'robots'
: このWARCリソースを作成した収集機の従うロボットポリシーです。
文字列'classic'は1994年のWebロボット除外標準ルールに準拠することを示します。

'hostname'
: このWARCリソースを作成したマシンのホスト名です。例： "crawling17.archive.org"

'ip'
: このWARCリソースを作成したマシンのIPアドレスです。例： "123.2.3.4"

'http-header-user-agent'
: 収集機によって各リクエストと共に通常送信される'User-Agent'ヘッダーです。
もし、'request'レコードがそのまま保存されているのならこの情報が冗長であることに注意してください。
（もし特定のリクエストのために'request'や'metadata'レコードが異なる'User-Agent'を知らせる場合、より具体的な情報がより信頼性が高いと考えるべきです。）

'http-header-from'
: 収集機によって各リクエストと共に通常送信される'From'ヘッダーです。
（'User-Agent'の場合と同じ考慮事項が適用されます。）

複数のレコードがWARCファイルの中から抜粋されても有効なWARCファイルになるために、任意ですが、正当なWARCの最初のレコードは'warcinfo'の説明であってください。
また、より大きな有効なWARCファイルへのWARCファイルの結合を可能にするために、'warcinfo'レコードがWARCファイルの中央に現れることを許容してください。
付録C.1の'warcinfo'レコードの例を参照してください。

6.3 'response'

6.3.1 概略

'response'レコードは、完全なスキーマ固有レスポンスが含まれる必要があり、可能であればネットワーク・プロトコル情報を含みます。
以下に記すように、'response'レコードの正確な内容は、レコードタイプからだけでなくレコードのターゲットURIのURIスキームからも決定されます。

付録C.3の'response'レコードの例を参照してください。

6.3.2 'http'と'https'スキームについて

'http'や'https'スキームのターゲットURIにおいては、'response'レコードブロックはネットワークから受信した（ヘッダーを含む）完全なHTTPレスポンスを含む必要があります。
つまり、HTTP/1.1 (RFC2616)のsection 6または互換性のあるそれ以前、以降のバージョンで定義された'Response'メッセージが含まれています。

WARCレコードのContent-TypeフィールドはHTTP/1.1で定義された値、"application/http;msgtype=response"を含む必要があります。
ソフトウェアバグ、ネットワークの問題、HTTPの使用に完全に準拠していないレスポンスデータを収集した場合、WARC書き込みソフトウェアはベストエフォート決定を使用して興味深いデータ境界の、問題の内容を記録することができます。
つまり、'http'ターゲットURI、そして'application/http'コンテンツタイプが使用される'response'レコードはデータに正当なHTTPレスポンスが含まれることを絶対的に保証するわけではありません。

WARC-IP-Addressフィールドは、レスポンスデータを受信した時点でのネットワークIPアドレスを記録のために使用されるべきです。

'response'が中断されていることが知られている場合、WARC-Truncatedフィールドを使用することに注意しなければなりません。

WARC-Concurrent-Toフィールド（複数可）は一致する'request'レコードや同時に作成した'metadata'レコードに'response'と関連付けるために使用することができます。

'http'や'https'スキームのターゲットURIを使用した'response'レコードのペイロードは、いかなる転送エンコーディングを取り除いた'entity-body'（RFC2616）です。
もし中断された'response'レコードブロックが完全なentity-bodyに満たない場合、ペイロードはその位置で中断されたと考えられます。

この文書では、証明書の交換、相談、検証といった'https'セキュアソケットトランザクションに関する情報を記録するための規則を指定しません。

6.3.3 他のURIスキームについて

この文書では他のURIスキームのための'response'レコードの内容を定めません。

6.4 'resource'

6.4.1 概略

'resource'レコードは完全なプロトコルレスポンス情報を除くリソースを含みます。
例：ローカルアクセス可能なリポジトリから直接取得したファイルやネットワークから取得した結果からプロトコル情報を除いたものなど。
以下に説明するように、'resource'レコードの正確な内容は、レコードタイプによってだけでなく、レコードのターゲットURIのURIスキームからも決定されます。

全ての'resource'レコードでペイロードはレコードブロックとして定められています。

合成されたターゲットURIを持つ'resource'レコードは、WARCファイル内の収集プロセスの他の産物をアーカイブするために使用することができます。

付録C.4の'resource'レコードの例を参照してください。

6.4.2 'http'と'https'スキームについて

'http'や'https'スキームのターゲットURIについては、'resource'レコードブロックは返された'entity-body'（RFC2616で定義され、いかなる転送エンコーディングをも取り除いた）を含まなければなりません。
場合によっては省略されます。

6.4.3 'ftp'スキームについて

'ftp'スキームのターゲットURIについては、'resource'レコードブロックはFTP操作によって返された完全なファイルを含まなければなりません。
場合によっては省略されます。

6.4.4 'dns'スキームについて

'dns'スキーム（RFC4501）のターゲットURIについては、'resource'レコードはターゲットURIに示された単一のDNSルックアップの結果を示した'text/dns'（RFC4027に登録され、RFC2540とRFC1035で定められた）コンテンツタイプの情報を含まなければならない。

6.4.5 他のURIスキームについて

この文書では他のURIスキームのための'resource'レコードのコンテンツを定めません。

6.5 'request'

6.5.1 概略

'request'レコードはネットワーク・プロトコル情報を可能であれば含む完全なスキーマ固有のリクエスト詳細を保持します。
以下に述べるように、'request'レコードの正確な内容はレコードタイプによってのみならず、レコードのターゲットURIのURIスキームによっても決定されます。

付録C.2の'request'レコードの例を参照してください。

6.5.2 'http'と'https'スキームについて

'http'や'https'スキームのターゲットURIにおいて、'request'レコードブロックはヘッダーを含むネットワークに送信した完全なHTTPリクエストを含まなければなりません。
つまり、HTTP/1.1(RFC2616)のsection 5やそれ以前・以降の互換性のあるバージョンで定められた'Request'メッセージを含みます。

WARCレコードのContent-TypeフィールドはHTTP/1.1で定められた値"application/http;msgtype=request"を含まなければなりません。

WARC-IP-Addressフィールドはリクエスト情報が送られたネットワークIPアドレスを記録するために使用されなければなりません。

WARC-ConcurrentToフィールド（複数可）は'request'と一致する'response'レコードや同時に作成された'metadata'レコードを関連付けるために使用することができます。

'http'や'https'スキームのターゲットURIを持つ'request'レコードのペイロードは、いかなる転送エンコーディングをも取り除いた'entity-body'(RFC2616で定義)とします。
もし'request'レコードブロックが完全なentity-bodyに満たない場合、ペイロードは同じ位置で切断されたと考えられます。

この文書では'https'セキュアソケットトランザクションについての（証明書交換、相談、検証といった）情報を記録するための規則を定めません。

6.5.3 他のURIスキームについて

この文書では他のURIスキームのための'request'レコードのコンテンツを定めません。

6.6 'metadata'

'metadata'レコードは、さらなる説明や、収集されたリソースに付随させる、他のレコードタイプによってカバーされていない方法のために作成されたコンテンツを含みます。
'metadata'レコードは、ほとんどの場合、他のレコードが保持する収集したオリジナル、または変換されたコンテンツに別の種類の別のレコードを参照します。
（しかし、'metadata'レコードは他の'metadata'レコードを含む全てのレコードタイプを参照することが許容される。）
metadataレコードはある特定の他のレコード何回でも参照することができます。

metadataレコードブロックのフォーマットが異なることがあります。
先に定義した"application/warc-fields"フォーマットを使用してもよいです。
全てのDCMIに以下に定めるフィールドを加えたフィールドを許容します。
全てのフィールドはオプションです。

'via'
: アーカイブされるURIが発見された参照URI。

'hopsFromSeed'
: 'seed'URIから始まる現在のURIまでの各ホップタイプを記述する記号文字列。

'fetchTimeMs'
: ネットワークトラフィックの開始から始まる、アーカイブURIを収集するために要した時間（ミリ秒）。

'metadata'レコードはWARC-Concurrent-Toを使用して同じキャプチャーイベントに由来する他のレコードに関連付けることができます。
'metadata'レコードはWARC-Refers-Toヘッダーを使用して説明し、他のレコードに関連付けることができます。

付録C.5の'metadata'レコードの例を参照してください。

6.7 'revisit'

6.7.1 概略

'revisit'レコードは既にアーカイブしたコンテンツの再訪を説明し、前のレコードに関連して解釈する必要がある省略されたコンテンツボディだけが含まれるかもしれません。
最も典型的なものでは、'revisit'レコードは訪問したコンテンツが以前アーカイブした情報の完全な、または実質的な重複のいずれかである事を示すために'response'や'resource'レコードの代わりに使用されます。

ストレージサイズの縮小の利点や、情報の相互参照の改良が望まれる時のために、他のタイプよりも'revisit'レコードを使用することは任意です。

'revisit'レコードはレコードのフィールドとレコードブロックの解釈を決定し、WARC-Profileフィールドを含まなければなりません。
以下のセクションで2つの初期値とその解釈を定めます。
プロフィールURIを認識できないリーダーは、外側のレコード、または関連付けられたコンテンツボディを解釈しようとしないものとします。

このレコードタイプの目的は、再訪問が発生したことに加えてアーカイブされたバージョンに関連して訪問したコンテンツの現在の状態についての詳細を記録しながら、繰り返し同一、または若干変更されたコンテンツを取得するときにストレージの冗長性を低減することです。

付録C.6の'revisit'レコードの例を参照してください。

6.7.2 プロファイル：同一のペイロードダイジェスト

この'revisit'プロファイルは次のURIがペイロードコンテンツのSHA-1のような強力なダイジェスト関数を提供し、以前に記録されたバージョンと同じことを示します。

このプロファイルを示すにはURIを使用します：

http://netpreserve.org/warc/1.0/revisit/identical-payload-digest

比較のためのペイロードダイジェストを報告するためには、'revisit'レコードはこのプロファイルを使用し、WARC-Payload-Digestフィールドとペイロードに対して算出されたダイジェスト値を含めなければならない。

このプロファイルを使用する'revisit'レコードはレコードブロックを持っていなくても構わず、その場合はContent-Lengthは0を記述する必要があります。
レコードブロックが存在する場合、同じURIの'response'レコードタイプと同じように解釈され、しかし、重複したコンテンツを保存しないように切り捨てなければなりません。
'length'を理由とするWARC-Truncatedヘッダーは、任意の同一のダイジェストの切り捨てのために使用されなければなりません。

このプロファイルを使用したレコードは、ペイロードはそのダイジェスト値が変更されていないオリジナルのペイロードコンテンツとして定義されています。

'revisit'レコードを誤って解釈するリスクを最小化するため、WARC-Refers-Toヘッダーを使用して、一致するコンテンツを取得可能な特定の先のレコードを識別することが推奨されます。

6.7.3 プロファイル：サーバー未変更

この'revisit'プロファイルは次のURIがサーバーによってHTTP "304 Not Modified"レスポンスのようなコンテンツが変更されていないことを示します。

このプロファイルを示すにはURIを使用します：

http://netpreserve.org/warc/1.0/revisit/server-not-modified

このプロファイルを使用した'revisit'レコードはコンテンツボディを持っていなくても構わず、その場合はContent-Lengthに0を記述する必要があります。
もしコンテンツボディが存在する場合、同じURIの'response'レコードタイプと同じように解釈しなければなりません。必要に応じて省略されます。

このプロファイルを使用したレコードについては、ペイロードは'Last-Modified'および/または'ETag'値が取得されたオリジナルのペイロードコンテンツと同じように定義されています。

'revisit'レコードを誤って解釈するリスクを最小化するため、WARC-Refers-Toヘッダーを使用して、変更されていないコンテンツを取得可能な特定の先のレコードを識別することが推奨されます。

6.7.4 他のプロファイル

他の文書で、前回の訪問からの差の見かけの大きさを記録したり、以前格納したコンテンツの"diff"（2つのファイルの差分を出力するファイル比較ユーティリティ）として訪問したコンテンツをエンコードしたりといった、他の目的を達成するために追加のプロファイルを定義するかもしれません。

6.8 'conversion'

'conversion'レコードはアーカイブ処理の結果として作成された別のレコードのコンテンツの別バージョンを含まなければなりません。
通常、これは元の記録したフォーマットが失われた時にのためにレンダリングツールに広く利用可能なコンテンツの生存率を維持するための保持するコンテンツの変換のために使用されます。
必要に応じて、オリジナルのコンテンツは情報の損失を最小限に抑えながら（理論的、見た目など）、現在のツールで使用可能な情報を保持するためにより現実的な形式に（変換済）移行されるかもしれません。
'conversion'レコードは変換されたコンテンツ自身を含む特定のソースレコードの参照を任意の数作成することができます。
各変換はオリジナルのレコードの生存に依存しない自立した完全なレコードを返さなければなりません。

metadataレコードは変換レコードを詳細に記述するために使用することができます。
実用上どこにあっても、'conversion'レコードは変換された先行する材料を示すために"WARC-Refers-To"フィールドを含めなければなりません。

'conversion'レコードについては、ペイロードはレコードブロックとして定義されています。

付録C.7の'conversion'レコードの例を参照してください。

6.9 'continuation'

'continuation'レコードからレコードブロックは論理的に完全なフルサイズのオリジナルレコードを作成する前に対応する先行レコードブロック（複数可）に（例：他のWARCファイルから）追加していく必要があります。
つまり、WARCファイルの望まれる制限を超えるサイズを原因とするものを除く'continuation'レコードが使用されているレコードはセグメントに分割されます。
continuationレコードは"WARC-Segment-Origin-ID"と"WARC-Segment-Number"フィールドを、シリーズ最後の'continuation'レコードは"WARC-Segment-Total-Length"フィールドを含まなければなりません。
WARCレコードセグメンテーションの完全な詳細は以下のレコードセグメンテーションのセクションに定義してあります。

付録C.8の'continuation'レコードの例を参照してください。

7 レコードセグメンテーション

単一WARCファイルの望まれる最大サイズに適合しないレコードは、セグメントと呼ばれる数個のレコードに分割することができます。

セグメント化されたシリーズの最初のセグメントはオリジナルのレコードタイプ（'continuation'ではない）と"1"の値を持つ'WARC-Segment-Number'フィールドを持たなければなりません。

全ての後続のセグメントは、'continuation'のレコードタイプと、インクリメントされた'WARC-Segment-Number'フィールドを持っていなければなりません。
それらには集合の最初のセグメントのWARC-Record-IDの値を持つ'WARC-Segment-Origin-ID'フィールドを含まなければなりません。
集合の全てのセグメントは同一のターゲットURI値を持たなければなりません。
セグメントは、独立したWARC-Block-Digestフィールドを持つことができます。

最後のセグメントは、全てのセグメントコンテンツブロックを再構築した場合の全体の長さをバイト数で示す"WARC-Segment-Total-Length"フィールドを含まなければなりません。
最後のセグメントは適切であれば"WARC-Truncated"フィールドを含むことができます。

セグメント化されたレコードの最初のセグメント内のWARC-Payload-Digestは、論理レコードのペイロードのダイジェストです。

最初以外のセグメントは、最初のレコードのデータブロックを継続するのに役立つために、他のオプションフィールドを含んではなりません。

全てのセグメントを再構築し、意図された完全な論理レコードにするには、収集された同一の'WARC-Segment-Origin-ID'値を持つ全てのレコードのコンテンツブロックを、'WARC-Segment-Number'順にオリジナルのレコードコンテンツブロックに結合します。
構成されたレコード結果は、'WARC-Segment-Total-Length'値を'Content-Length'として採用します。
そして、最後のセグメントのいずれかの'WARC-Truncated'理由を採用します。

もし望まれるWARCファイルターゲットサイズの範囲内でレコードを格納する他の方法がある場合、セグメンテーションを使用してはなりません。
具体的には、新しいWARCファイルの開始によって分割することなく保存することが出来るのであれば、セグメンテーションは使用してはなりません。
また、セグメンテーションが使用された場合、最初のセグメントのサイズは最大でなければなりません。
具体的には、オリジナルのセグメントが'warcinfo'レコード（もしあれば）だけが先行する新しいWARCファイルに置かれなければなりません。

セグメンテーションは'continuation'を除く全てのオリジナルレコードタイプに適用することができますが、'warcinfo'、'request'、'metadata'、'revisit'レコードに使用することは推奨されません。

8 MIMEメディアタイプ application/warc と application/warc-fields の登録

8.1 概略

このセクションではRFC2048で定められる、WARCフォーマットと関連付けられたMIMEタイプを定めます。

8.2 application/warc

MIME media type name: application
MIME subtype names: warc
Required parameters: None
Optional parameters: None
Encoding considerations:

Content of this type is in 'binary' format.

Security considerations:

The WARC record syntax poses no direct risk to computers and networks.
Implementers need to be aware of source authority and trustworthiness of information structured in WARC.
Readers and writers subject themselves to all the risks that accompany normal operation of data processing services (e.g., message length errors, buffer overflow attacks).

Interoperability considerations: None

Published specification: TBD

Applications which use this media type: Large- and small-scale archiving

Additional information: None

Person and email address to contact for further information:

Gordon Mohr gojomo@archive.org, John Kunze jak@ucop.edu

Intended usage: COMMON

Author/Change controller: IESG

8.3 application/warc-fields

MIME media type name: application

MIME subtype names: warc-fields

Required parameters: None

Optional parameters: None

Encoding considerations:

Content of this type is in 'binary' format.

Security considerations:

The WARC field syntax poses no direct risk to computers and networks.
Implementers need to be aware of source authority and trustworthiness of information structured in WARC.
Readers and writers subject themselves to all the risks that accompany normal operation of data processing services (e.g., message length errors, buffer overflow attacks).

Interoperability considerations: None

Published specification: TBD

Applications which use this media type: Large- and small-scale archiving

Additional information: None

Person and email address to contact for further information:

Gordon Mohr gojomo@archive.org, John Kunze jak@ucop.edu

Intended usage: COMMON

Author/Change controller: IESG

9　IANA 考慮事項

IESGの承認の後、IANAはこの文書で定めるアプリケーションが使用するWARCタイプ"application/warc"を登録することが期待されます。

付録 A （情報提供）圧縮勧告

A.1 概略

The WARC format defines no internal compression.
Whether and how WARC files should be compressed is an external decision.

However, experience with the precursor ARC format at the Internet Archive has demonstrated that applying simple standard compression can result in significant storage savings, while preserving random access to individual records.

For this purpose, the GZIP format with customary "deflate" compression is recommended, as defined in RFC1950, RFC1951, and RFC1952.
Freely available source code implementing this format is available, and the technique is free of patent encumbrances.
The GZIP format is also widely used and supported across many free and commercial software packages and operating systems.

This section documents recommended, but optional, practices for compressing WARC files with GZIP.

A.2 Record-at-time compression

Per section 2.2 of the GZIP specification, a valid GZIP file consists of any number of gzip "members", each independently compressed.

Where possible, this property should be exploited to compress each record of a WARC file independently.
This results in a valid GZIP file whose per-record subranges also stand alone as valid GZIP files.

External indexes of WARC file content may then be used to record each record's starting position in the GZIP file, allowing for random access of individual records without requiring decompression of all preceding records.

Note that the application of this convention causes no change to the uncompressed contents of an individual WARC record.

A.3 GZIP WARC file name suffix

A gzip compressed WARC file should have the customary ".gz" appended to it, making the complete suffix, ".warc.gz".

Annex B (informative) WARC file size and name recommendations

1GB (10^9 bytes) is recommended as a practical target size for WARC files, when record sizes allow.
Oversized records may be truncated, segmented, or placed in oversized WARC files, at a project's discretion.

It is helpful to use practices within an institution that make it unlikely or impossible to duplicate aggregate WARC file names.
The convention used inside the Internet Archive with ARC files is to name files according to the following pattern:

Prefix-Timestamp-Serial-Crawlhost.warc.gz

Prefix is an abbreviation usually reflective of the project or crawl that created this file.
Timestamp is a 14-digit GMT timestamp indicating the time the file was initially begun.
Serial is an increasing serial-number within the process creating the files, often (but not necessarily) unique with regard to the Prefix.
Crawlhost is the domain name or IP address of the machine creating the file.

IIPC member institutions have expressed an interest in adopting a common naming strategy, with per-institution unique identifiers to assist in marking WARC files with their institution of origin.
It is proposed that all such WARC file names adhering to this future convention begin "iipc".

This specification does not require any particular WARC file naming practice, but conventions similar to the above are recommended within WARC-creating institutions.
The file name prefix "iipc" should not be used unless participating in a future IIPC naming registry.

付録 C (情報提供) WARCレコード例

C.1 'warcinfo'レコードの例

WARC/1.0
WARC-Type: warcinfo
WARC-Date: 2006-09-19T17:20:14Z
WARC-Record-ID: <urn:uuid:d7ae5c10-e6b3-4d27-967d-34780c58ba39>
Content-Type: application/warc-fields
Content-Length: 381

software: Heritrix 1.12.0 http://crawler.archive.org
hostname: crawling017.archive.org
ip: 207.241.227.234
isPartOf: testcrawl-20050708
description: testcrawl with WARC output
operator: IA_Admin
http-header-user-agent:
 Mozilla/5.0 (compatible; heritrix/1.4.0 +http://crawler.archive.org)
format: WARC file version 1.0
conformsTo:
 http://www.archive.org/documents/WarcFileFormat-1.0.html

C.2 'request'レコードの例

WARC/1.0
WARC-Type: request
WARC-Target-URI: http://www.archive.org/images/logoc.jpg
WARC-Warcinfo-ID: <urn:uuid:d7ae5c10-e6b3-4d27-967d-34780c58ba39>
WARC-Date: 2006-09-19T17:20:24Z
Content-Length: 236
WARC-Record-ID: <urn:uuid:4885803b-eebd-4b27-a090-144450c11594>
Content-Type: application/http;msgtype=request
WARC-Concurrent-To: <urn:uuid:92283950-ef2f-4d72-b224-f54c6ec90bb0>

GET /images/logoc.jpg HTTP/1.0
User-Agent: Mozilla/5.0 (compatible; heritrix/1.10.0)
From: stack@example.org
Connection: close
Referer: http://www.archive.org/
Host: www.archive.org
Cookie: PHPSESSID=009d7bb11022f80605aa87e18224d824

C.3 'response'レコードの例

WARC/1.0
WARC-Type: response
WARC-Target-URI: http://www.archive.org/images/logoc.jpg
WARC-Warcinfo-ID: <urn:uuid:d7ae5c10-e6b3-4d27-967d-34780c58ba39>
WARC-Date: 2006-09-19T17:20:24Z
WARC-Block-Digest: sha1:UZY6ND6CCHXETFVJD2MSS7ZENMWF7KQ2
WARC-Payload-Digest: sha1:CCHXETFVJD2MUZY6ND6SS7ZENMWF7KQ2
WARC-IP-Address: 207.241.233.58
WARC-Record-ID: <urn:uuid:92283950-ef2f-4d72-b224-f54c6ec90bb0>
Content-Type: application/http;msgtype=response
WARC-Identified-Payload-Type: image/jpeg
Content-Length: 1902

HTTP/1.1 200 OK
Date: Tue, 19 Sep 2006 17:18:40 GMT
Server: Apache/2.0.54 (Ubuntu)
Last-Modified: Mon, 16 Jun 2003 22:28:51 GMT
ETag: "3e45-67e-2ed02ec0"
Accept-Ranges: bytes
Content-Length: 1662
Connection: close
Content-Type: image/jpeg

[image/jpeg binary data here]

C.4 'resource'レコードの例

WARC/1.0
WARC-Type: resource
WARC-Target-URI: file://var/www/htdoc/images/logoc.jpg
WARC-Date: 2006-09-30T16:40:32Z
WARC-Record-ID: <urn:uuid:23200706-de3e-3c61-a131-g65d7fd80cc1>
Content-Type: image/jpeg
WARC-Payload-Digest: sha1:DBXHDRBXLF4OMUZ5DN4JJ2KFUAOB6VK8
WARC-Block-Digest: sha1:DBXHDRBXLF4OMUZ5DN4JJ2KFUAOB6VK8
Content-Length: 1662

[image/jpeg binary data here]

C.5 'metadata'レコードの例

WARC/1.0
WARC-Type: metadata
WARC-Target-URI: http://www.archive.org/images/logoc.jpg
WARC-Date: 2006-09-19T17:20:24Z
WARC-Record-ID: <urn:uuid:16da6da0-bcdc-49c3-927e-57494593b943>
WARC-Concurrent-To : <urn:uuid:92283950-ef2f-4d72-b224-f54c6ec90bb0>
Content-Type: application/warc-fields
WARC-Block-Digest: sha1:VXT4AF5BBZVHDYKNC2CSM8TEAWDB6CH8
Content-Length: 59

via: http://www.archive.org/
hopsFromSeed: E
fetchTimeMs: 565

C.6 'revisit'レコードの例

WARC/1.0
WARC-Type: revisit
WARC-Target-URI: http://www.archive.org/images/logoc.jpg
WARC-Date: 2007-03-06T00:43:35Z
WARC-Profile: http://netpreserve.org/warc/1.0/server-not-modified
WARC-Record-ID: <urn:uuid:16da6da0-bcdc-49c3-927e-57494593bbbb>
WARC-Refers-To: <urn:uuid:92283950-ef2f-4d72-b224-f54c6ec90bb0>
Content-Type: message/http
Content-Length: 226

HTTP/1.x 304 Not Modified
Date: Tue, 06 Mar 2007 00:43:35 GMT
Server: Apache/2.0.54 (Ubuntu) PHP/5.0.5-2ubuntu1.4
Connection: Keep-Alive
Keep-Alive: timeout=15, max=100
Etag: "3e45-67e-2ed02ec0"

C.7 'conversion'レコードの例

WARC/1.0
WARC-Type: conversion
WARC-Target-URI: http://www.archive.org/images/logoc.jpg
WARC-Date: 2016-09-19T19:00:40Z
WARC-Record-ID: <urn:uuid:16da6da0-bcdc-49c3-927e-57494593dddd>
WARC-Refers-To: <urn:uuid:92283950-ef2f-4d72-b224-f54c6ec90bb0>
WARC-Block-Digest: sha1:XQMRY75YY42ZWC6JAT6KNXKD37F7MOEK
Content-Type: image/neoimg
Content-Length: 934

[image/neoimg binary data here]

C.8 セグメンテーションの例（'continuation'レコード）

Let us take the example of the 'response' record given earlier, and segment it to fit the within a WARC file no larger than 2K.
The first WARC file would contain the first segment, a record of type 'response' with a WARC-Segment-Number of 1. Note that the block-digest has changed -- as the block is no longer the same as the standalone 'response' record -- but the payload-digest has not changed, as the reassembled record will have the same internal payload.

WARC/1.0
WARC-Type: response
WARC-Target-URI: http://www.archive.org/images/logoc.jpg
WARC-Date: 2006-09-19T17:20:24Z
WARC-Block-Digest: sha1:2ASS7ZUZY6ND6CCHXETFVJDENAWF7KQ2
WARC-Payload-Digest: sha1:CCHXETFVJD2MUZY6ND6SS7ZENMWF7KQ2
WARC-IP-Address: 207.241.233.58
WARC-Record-ID: <urn:uuid:39509228-ae2f-11b2-763a-aa4c6ec90bb0>
WARC-Segment-Number: 1
Content-Type: application/http;msgtype=response
Content-Length: 1600

HTTP/1.1 200 OK
Date: Tue, 19 Sep 2006 17:18:40 GMT
Server: Apache/2.0.54 (Ubuntu)
Last-Modified: Mon, 16 Jun 2003 22:28:51 GMT
ETag: "3e45-67e-2ed02ec0"
Accept-Ranges: bytes
Content-Length: 1662
Connection: close
Content-Type: image/jpeg

[first 1360 bytes of image/jpeg binary data here]

The next file would contain the 'continuation' record, with fields to identify the start of the segmentation series (WARC-Segment-Origin-ID), to indicate this record's place in the series (WARC-Segment-Number), and to report that this the last record and what the total size is (WARC-Segment-Total-Length).

WARC/1.0
WARC-Type: continuation
WARC-Target-URI: http://www.archive.org/images/logoc.jpg
WARC-Date: 2006-09-19T17:20:24Z
WARC-Block-Digest: sha1:T7HXETFVA92MSS7ZENMFZY6ND6WF7KB7
WARC-Record-ID: <urn:uuid:70653950-a77f-b212-e434-7a7c6ec909ef>
WARC-Segment-Origin-ID: <urn:uuid:39509228-ae2f-11b2-763a-aa4c6ec90bb0>
WARC-Segment-Number: 2
WARC-Segment-Total-Length: 1902
WARC-Identified-Payload-Type: image/jpeg
Content-Length: 302

[last 302 bytes of image/jpeg binary data here]

Annex D (informative) Use cases for writing WARC records

Below are listed different use cases developing some situations where WARC files and WARC records may be generated.
These use cases correspond to the needs of the web archiving community.

N.B.: In a web harvesting context, the files constituting the websites are stored as WARC records in WARC files.

Depending on the web harvesting process configuration, the different pieces of a website may not be contained in a single WARC file or in a set of WARC files but may be spread out and stored along pieces of other harvested websites.
Thus, to render the archive of a website to users, access software may have to extract files contained in WARC records from different WARC files.
External indexes may be used for a quicker access.

Other users may imagine other use cases to answer their own needs.
Moreover, solutions adopted for each use case are not the only solutions that may be used.
These are presented as examples.

The first column describes the use case and its different steps.

The second column indicates what type of record is generated.
Only the most complex named field are specified in order to clarify the use of these fields: WARC-Type (mandatory field), WARC-Date (mandatory field), WARC-Concurrent-To (optional field), WARC-Refers-To (optional field).
The other mandatory or useful named fields are not presented in the document.

Note: we suppose these WARC records are written in an already opened WARC file, containing a ‘warcinfo’ record.

Use case one

An archiving crawler fetches http://netpreserve.org/reports/iipc2007conference.pdf from the World Wide Web and writes it in a WARC file.

Date: 2007-10-24 at 10:14:22 GMT

A request is sent by the crawler to the server hosting http://netpreserve.org/reports/iipc2007conference.pdf

WARC record created:

WARC-Type: ‘request’

WARC-Date: 2007-10-24T10:14:22Z

WARC-Concurrent-To: WARC-Record ID of the following ‘response’ record
A response is received by the crawler from the server

WARC record created:

WARC-Type: ‘response’

WARC-Date: 2007-10-24T10:14:22Z
Metadata further describing the harvesting process / the harvested record are added (e.g. information coming from the log files)

WARC record created:

WARC-Type: ‘metadata’

WARC-Date: 2007-10-24T10:14:22Z

WARC-Concurrent-To: WARC-Record ID of the previous ‘response’ record
If the file harvested on the web is too big to be contained in a single WARC file (e.g. 1,5 GB), the WARC record is segmented and a second record is created

Second WARC record created:

WARC-Type: ‘continuation’

WARC-Date: 2007-10-24T10:14:22Z

Use case two

the XML version of the French Gazette of 2007-11-01 has been transferred to the National Library of France (via FTP or email). This file is archived in a WARC file.

Date: 2007-11-02 at 15:20:44 GMT

The resource is archived

WARC record created:

WARC-Type: ‘resource’

WARC-Date: 2007-11-02T15:20:44Z
Metadata further describing the archiving process / the archived record are added (e.g. information about the transfer)

WARC record created:

WARC-Type: ‘metadata’

WARC-Date: 2007-11-02T15:20:44Z

WARC-Concurrent-To: WARC-Record ID of the previous ‘resource’ record

Use case three

An archiving crawler fetches http://netpreserve.org/reports/iipc2007conference.pdf from the World Wide Web that has not changed since the latest harvest

Date: 2007-11-24 at 18:28:24 GMT

A request is sent by the crawler to the server hosting http://netpreserve.org/reports/iipc2007conference.pdf

WARC record created:

WARC-Type: ‘request’

WARC-Date: 2007-11-24T18:28:24Z

WARC-Concurrent-To: WARC-Record ID of the following ‘revisit’ record
The crawler detects that the file is the same as previously archived and that it has not changed. The entire file is not recorded to avoid duplicates and reduce storage redundancy

WARC record created:

WARC-Type: ‘revisit’

WARC-Date: 2007-11-24T18:28:24Z

WARC-Refers-To: WARC-Record ID of the already written record

Use case four

After the end of the harvest, Jhove is used to validate the format of http://netpreserve.org/reports/iipc2007conference.pdf. It produces validation results that have to be stored in a WARC file and linked to the corresponding record.

Date: 2007-11-01 at 20:54:02 GMT

Results of the validation process are added in another WARC file > WARC record created: > >> WARC-Type: ‘metadata’ >> >> Date: 2007-11-01T20:54:02Z >> >> WARC-Refers-To: WARC-Record described WARC record

Use case five

http://netpreserve.org/reports/iipc2007conference.pdf file format has become obsolete as it cannot be read anymore by the existing rendering tools. It is necessary to migrate this file from the obsolete format to a new format.

Date: 2020-01-23 at 16:14:32 GMT

A file in the new format is generated

WARC record created:

WARC-Type: ‘conversion’

WARC-Date: 2020-01-23T16:14:32Z

WARC-Refers-To: WARC-Record ID of the WARC record whose payload has been migrated
Metadata describing the migration process are added (e.g. tool used)

WARC record created:

WARC-Type: ‘metadata’

WARC-Date: 2020-01-23T16:14:32Z

WARC-Refers-To: WARC-Record ID of the previous conversion record

WARCファイルフォーマット翻訳（仮）