[要約] RFC 8153は、RFCシリーズのデジタル保存に関する考慮事項をまとめたものです。その目的は、長期的な保存とアクセスのためにRFC文書のデジタル形式を適切に管理するためのガイドラインを提供することです。
Internet Architecture Board (IAB) H. Flanagan
Request for Comments: 8153 RFC Editor
Category: Informational April 2017
ISSN: 2070-1721
Digital Preservation Considerations for the RFC Series
RFCシリーズのデジタル保存に関する考慮事項
Abstract
概要
The RFC Editor is both the publisher and the archivist for the RFC Series. This document applies specifically to the archivist role of the RFC Editor. It provides guidance on when and how to preserve RFCs and describes the tools required to view or re-create RFCs as necessary. This document also highlights gaps in the current process and suggests compromises to balance cost with best practice.
RFCエディターは、RFCシリーズの発行者であり、アーキビストでもあります。この文書は、RFC編集者のアーキビストの役割に特に適用されます。 RFCを保存する時期と方法に関するガイダンスを提供し、必要に応じてRFCを表示または再作成するために必要なツールについて説明します。このドキュメントでは、現在のプロセスのギャップについても取り上げ、コストとベストプラクティスのバランスを取るための妥協案を示しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8153.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8153で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................4
1.2. Life Cycle of Digital Preservation .........................4
2. Updating Policy and Procedure ...................................5
2.1. Acquisition of Documents ...................................6
2.2. Ingestion of Documents .....................................6
2.3. Metadata and Document Registration .........................7
2.4. Normalization and Standardization of Canonical File
Structure and Format .......................................9
2.4.1. 'Best Effort' Data Retention .......................10
2.4.2. Single Format for Archival Purposes ................11
2.4.3. Holistic Archiving of the Computing Environment ....12
2.5. Transformation/Migration to Current Publication Formats ...12
2.6. System Parameters .........................................13
2.7. Financial Impact ..........................................13
3. Recommendations ................................................14
4. Summary ........................................................15
5. IANA Considerations ............................................15
6. Security Considerations ........................................15
7. Informative References .........................................16
IAB Members at the Time of Approval ...............................18
Author's Address ..................................................18
The RFC Editor is both the publisher and the archivist for the RFC Series, a series of technical specifications and policy documents that includes foundational Internet standards [RFC6635] [RFC-SERIES]. The goal of the RFC Editor is to is to produce clear, consistent, and readable documents for the Internet community. Over time, the RFC Editor will use as many modern features, such as hyperlinks and content markup, within the document as necessary to convey the information the authors intended for their audience. As the archivist, however, the main goal is to preserve both the information described and the documents themselves for the indefinite future. To meet both of these goals, the RFC Editor must find the necessary balance between the publication needs of today and the archival needs of tomorrow, while acknowledging a finite set of resources to complete both aspects of the RFC Editor function.
RFC Editorは、基本的なインターネット標準[RFC6635] [RFC-SERIES]を含む一連の技術仕様とポリシードキュメントであるRFCシリーズの発行者であり、アーキビストでもあります。 RFCエディタの目的は、インターネットコミュニティ向けに、明確で一貫性があり、読みやすいドキュメントを作成することです。 RFCエディタは、作成者が対象読者向けに意図した情報を伝えるために、ドキュメント内でハイパーリンクやコンテンツマークアップなどの最新の機能を必要なだけ使用します。ただし、アーキビストとしての主な目標は、記述された情報とドキュメント自体の両方を無期限に保存することです。これらの両方の目標を達成するために、RFCエディターは、RFCエディター機能の両方の側面を完了するための有限のリソースセットを認めながら、今日の出版ニーズと明日のアーカイブニーズの間の必要なバランスを見つける必要があります。
While many files are created during the editing process, this document focuses on the archival needs of the Internet-Drafts (I-Ds) that were approved for publication and the RFCs that resulted from these I-Ds; I-Ds before they are approved for publication by the appropriate stream-approving body are out of scope.
編集プロセス中に多くのファイルが作成されますが、このドキュメントでは、公開が承認されたインターネットドラフト（I-D）のアーカイブニーズと、これらのI-Dから生じたRFCに焦点を当てています。適切なストリーム承認機関によって公開が承認される前のI-Dは範囲外です。
To summarize, the key areas of tension between the roles of publisher and archivist are:
要約すると、出版社とアーキビストの役割の間の緊張の主要な領域は次のとおりです。
o the desire of the publisher to meet the needs expressed by authors who want to use the latest technology (e.g., vector graphics, live links, and a rich set of metadata) within their documents; and
o 文書内で最新のテクノロジー（ベクターグラフィック、ライブリンク、豊富なメタデータのセットなど）を使用したい著者が表明したニーズを満たすための出版社の要望;そして
o the desire of the archivist to support only the simplest format for documents possible -- currently held by the Series to be plain-text, ASCII-only documents -- so that the tools needed to view the documents are equally simple and resistant to changes in technology, resulting in a set of documents that will be easier to archive for at least the next several decades, if not centuries.
o ドキュメントを表示するために必要なツールが同様にシンプルで変更に対する耐性を持つように、可能な限り最もシンプルな形式のドキュメントのみをサポートするアーキビストの要望（現在、シリーズでプレーンテキスト、ASCIIのみのドキュメントとして保持されています）テクノロジーにより、数世紀ではないにしても、少なくとも今後数十年間はアーカイブしやすい一連のドキュメントが生成されます。
Through most of the history of the RFC Series, the file format for RFCs has been plain text with an ASCII-only character set. This choice offered the simplest format likely to remain available to the largest number of consumers and the format most likely to be resistant to changes in technology over time. Increasingly, however, consumers and authors are requesting additional features that would allow for easy reading on a wider array of devices while retaining all the metadata authors intended in their documents. In 2013, RFC 6949 ("RFC Series Format Requirements and Future Development") captured the high-level requirements for the Series; the fundamental issue was that plain-text, ASCII-only documents no longer meet the needs of the communities interested in using and producing RFCs [RFC6949].
RFCシリーズの歴史のほとんどを通じて、RFCのファイル形式は、ASCIIのみの文字セットを含むプレーンテキストでした。この選択により、最も多くの消費者が引き続き利用できる可能性が最も高い最も単純なフォーマットと、時間の経過に伴うテクノロジーの変化に抵抗する可能性が最も高いフォーマットが提供されました。ただし、ますます、消費者と作成者は、ドキュメントで意図されているすべてのメタデータ作成者を保持しながら、幅広いデバイスで簡単に読み取ることができる追加機能を要求しています。 2013年、RFC 6949（「RFCシリーズフォーマットの要件と将来の開発」）は、シリーズの高レベルの要件を取り込みました。基本的な問題は、プレーンテキストのASCIIのみのドキュメントが、RFC [RFC6949]の使用と作成に関心のあるコミュニティのニーズを満たしていないことでした。
The assertion that plain-text, ASCII-only documents no longer meet the needs of the community suggests that the simple archival process maintained by the RFC Editor is also no longer sufficient. More complex tools and file formats require a more complex process to ensure that RFCs can be read and rendered far into the future. This document describes the considerations that must inform any changes in policy and procedure, and it describes a model for the RFC Series to follow when additional formats beyond plain-text, ASCII-only RFCs are published. The functional model that provides the framework for the archival process described in this document was derived from the ISO Open Archival Information System (OAIS) reference model, defined in "Space data and information transfer systems -- Open archival information system (OAIS) -- Reference model" [ISO14721].
プレーンテキストのASCIIのみのドキュメントがコミュニティのニーズを満たしていないという主張は、RFCエディタによって維持される単純なアーカイブプロセスももはや十分ではないことを示唆しています。より複雑なツールとファイル形式では、RFCを遠くまで読み取ってレンダリングできるようにするために、より複雑なプロセスが必要です。このドキュメントでは、ポリシーと手順の変更を通知する必要がある考慮事項について説明し、プレーンテキストのASCIIのみのRFC以外の追加の形式が公開されたときにRFCシリーズが従うモデルについて説明します。このドキュメントで説明するアーカイブプロセスのフレームワークを提供する機能モデルは、「スペースデータおよび情報転送システム-オープンアーカイブ情報システム（OAIS）-」で定義されたISOオープンアーカイブ情報システム（OAIS）参照モデルから派生したものです。参照モデル」[ISO14721]。
Acquisition: The point at which a document is accepted by the RFC Editor for future inclusion into the archive.
取得：文書がRFCエディターによって受け入れられ、アーカイブに将来含まれるようになる時点。
Ingestion: The point at which a digital object is assigned all necessary metadata to describe the object and its contents and is added to the archive.
取り込み：デジタルオブジェクトに、オブジェクトとそのコンテンツを説明するために必要なすべてのメタデータが割り当てられ、アーカイブに追加されるポイント。
Bitstream preservation: The process of storing and maintaining digital objects over time, ensuring that there is no loss or corruption of the bits making up those objects.
ビットストリームの保存：デジタルオブジェクトを長期にわたって保存および維持するプロセス。これらのオブジェクトを構成するビットの損失や破損がないことを保証します。
Content preservation: The retention of the ability to read, listen, or watch a digital file in perpetuity. Content preservation is not about the bits being stored; it is about being able to access and present those bits to the user.
コンテンツの保持：デジタルファイルを永続的に読み取り、聞き、または見る機能の保持。コンテンツの保存は、格納されるビットに関するものではありません。これらのビットにアクセスしてユーザーに提示できるようにすることです。
The basic process for preserving digital information has been described by a variety of organizations. From the Life cycle Information For E-Literature (LIFE) project [LIFE] in the United Kingdom to the ongoing digital preservation work in the U.S. Library of Congress [USLOC], the basic digital preservation process is straightforward. Documents are acquired and processed, metadata is recorded, physical media is refreshed, and content is regularly checked to see if it is still accessible by interested parties. Complexities arise when one considers the need to preserve both the bits of the digital objects themselves and the tools with which to express those bits in an environment that experiences rapid changes in technology.
デジタル情報を保存するための基本的なプロセスは、さまざまな組織によって説明されています。イギリスのE-Literature（LIFE）プロジェクトのライフサイクル情報[LIFE]から、米国議会図書館[USLOC]で進行中のデジタル保存作業まで、基本的なデジタル保存プロセスは簡単です。ドキュメントが取得および処理され、メタデータが記録され、物理メディアが更新され、コンテンツが定期的にチェックされて、関係者がまだアクセスできるかどうかが確認されます。デジタルオブジェクト自体のビットと、テクノロジーの急速な変化を経験する環境でこれらのビットを表現するためのツールの両方を保持する必要性を考えると、複雑さが生じます。
For most of the existence of the RFC Series, the digital preservation process has been fairly simple, focusing on bitstream preservation and relying on paper copies of digital files.
RFCシリーズが存在するほとんどの場合、デジタル保存プロセスはかなり単純で、ビットストリームの保存に焦点を当て、デジタルファイルの紙のコピーに依存しています。
The current archival process for the RFC Series is as follows:
RFCシリーズの現在のアーカイブプロセスは次のとおりです。
1. Acquisition: The RFC Editor database is updated to indicate an I-D has been approved for publication. At this point, the document is taken through the editorial process on the way to publication [RFC-PUB].
1. 取得：RFC Editorデータベースが更新され、I-Dの公開が承認されたことが示されます。この時点で、ドキュメントは公開[RFC-PUB]への途中で編集プロセスを経て取得されます。
2. Ingestion: The RFC is added to the archive at the time of publication.
2. 取り込み：RFCは公開時にアーカイブに追加されます。
3. Metadata creation: The details regarding an RFC, including RFC number, author, title, abstract, etc., are created at time of publication. Additional metadata in the form of status and errata can be added or changed at any time, following the process of the originating document stream.
3. メタデータの作成：RFC番号、作成者、タイトル、要約などを含むRFCに関する詳細は、公開時に作成されます。元のドキュメントストリームのプロセスに従って、ステータスとエラータの形式の追加のメタデータをいつでも追加または変更できます。
4. Bitstream preservation: This part of the process is handled as part of the IT system administration; all servers, disks, and backup technology are refreshed on a regular cycle.
4. ビットストリームの保持：プロセスのこの部分は、ITシステム管理の一部として処理されます。すべてのサーバー、ディスク、およびバックアップテクノロジは、定期的に更新されます。
5. Content preservation: All RFCs since January 2010 have been printed out on standard office paper at time of publication, and the electronic files have been preserved on disk and in backups with no particular focus on preserving the entire computing environment used to create the electronic documents. Most RFCs prior to January 2010 are also available on paper, but there are gaps in the record and issues of ownership around the paper copies before that date.
5. コンテンツの保存：2010年1月以降のすべてのRFCは、発行時に標準の事務用紙に印刷されており、電子ファイルは、電子ドキュメントの作成に使用されたコンピューティング環境全体の保存に特に重点を置くことなく、ディスクとバックアップに保存されています。 2010年1月より前のほとんどのRFCは紙でも入手できますが、その日付以前の紙のコピーに関する記録と所有権の問題にはギャップがあります。
When the format for RFCs transitions from plain-text, ASCII-only files to an XML format with multiple outputs, the overall archival process will become more complex. Additional metadata and some (or possibly all) of the computing environment may need to be added to the archive.
RFCの形式がプレーンテキストのASCIIのみのファイルから複数の出力を持つXML形式に移行すると、アーカイブプロセス全体がより複雑になります。追加のメタデータとコンピューティング環境の一部（場合によってはすべて）をアーカイブに追加する必要があります。
RFCs are created and published as digital objects. Unlike paper-based publications, a digital collection requires a focus on retaining the details of the technology as well as retaining the object itself. Specifically, a digital archive needs to:
RFCはデジタルオブジェクトとして作成および公開されます。紙ベースの出版物とは異なり、デジタルコレクションでは、オブジェクト自体を保持するだけでなく、テクノロジーの詳細を保持することに焦点を当てる必要があります。具体的には、デジタルアーカイブは次のことを行う必要があります。
o consider the inherent instability of digital media,
o デジタルメディアの本質的な不安定性を考慮し、
o plan for a relatively short path to technological obsolescence,
o 技術的陳腐化への比較的短い道のりを計画し、
o schedule regular media updates,
o 定期的なメディア更新をスケジュールし、
o apply predefined criteria for technology evaluation, and
o 技術評価のための事前定義された基準を適用し、
o ensure the continued authenticity and integrity of documents through any changes in technology.
o テクノロジーの変更を通じて、ドキュメントの信頼性と整合性を維持します。
As the custodian and canonical source of RFCs and associated errata, the RFC Editor must consider how to ensure the availability and integrity of this document series far into the future and determine whether the focus must be on bitstream preservation, content preservation, or both.
RFCおよび関連する正誤表のカストディアンおよび正規のソースとして、RFCエディターは、このドキュメントシリーズの可用性と整合性を将来にわたって保証する方法を検討し、ビットストリームの保存、コンテンツの保存、またはその両方に焦点を当てる必要があるかどうかを判断する必要があります。
The RFC Editor has several advantages in acting as the digital archivist for the Series. Since the RFC Editor is the publisher as well as the archivist, the RFC Editor controls the format of the material and the process for adding that material to an archive and can add any additional metadata considered necessary. External material, while a major consideration for more general archives, is no longer accepted by the RFC Editor. (See "Internet Archaeology: Documents from Early History" [RFC-HISTORY] for the list of non-RFC digital objects held by the RFC Editor.)
RFC Editorには、シリーズのデジタルアーキビストとしての役割を果たすいくつかの利点があります。 RFC Editorはパブリッシャーでありアーキビストでもあるため、RFC Editorは資料のフォーマットとその資料をアーカイブに追加するプロセスを制御し、必要と考えられる追加のメタデータを追加できます。外部資料は、より一般的なアーカイブに対する主要な考慮事項ですが、RFCエディタでは受け入れられなくなりました。 （RFCエディタが保持する非RFCデジタルオブジェクトのリストについては、「インターネット考古学：初期の歴史からの文書」[RFC-HISTORY]を参照してください。）
This document describes several different preservation models that may fit the needs of the Series and raises several points for community consideration. Specifically, this document covers information on:
このドキュメントでは、シリーズのニーズに適合する可能性のあるいくつかの異なる保存モデルについて説明し、コミュニティで検討するためにいくつかのポイントを挙げています。具体的には、このドキュメントでは次の情報について説明します。
o Acquisition of documents
o 文書の取得
o Ingestion of documents
o ドキュメントの取り込み
o Metadata and document registration
o メタデータとドキュメント登録
o Normalization and standardization of canonical file structure and format
o 正規のファイル構造とフォーマットの正規化と標準化
o Transformation/migration to current publication formats
o 現在の出版形式への変換/移行
o Content and computing environment preservation
o コンテンツとコンピューティング環境の保護
o System parameters
o システムパラメーター
o Financial impact
o 経済的影響
The acquisition process for documents intended for the archive starts with the submission of an approved I-D for publication. During the editorial process, information such as the document metadata is finalized prior to publication. However, the initial I-D as submitted and the RFC produced from it do not formally enter the archive until the time of publication, which is considered the point of ingestion from an archival perspective.
アーカイブを目的としたドキュメントの取得プロセスは、承認されたI-Dを提出して提出することから始まります。編集プロセスでは、ドキュメントのメタデータなどの情報が公開前に確定されます。ただし、提出された最初のI-Dとそこから生成されたRFCは、公開の時点まで正式にアーカイブに入れられません。これは、アーカイブの観点から取り込みのポイントと見なされます。
Once an RFC is published, the canonical format is considered immutable. At this point, the RFC Production Center, one of the internal roles within the RFC Editor, assigns the document metadata that an archivist needs to identify the unique object.
RFCが公開されると、正規形式は不変と見なされます。この時点で、RFCエディターの内部ロールの1つであるRFC Production Centerは、アーキビストが一意のオブジェクトを識別するために必要なドキュメントメタデータを割り当てます。
In the case of RFCs, the metadata assigned to a document at the time of publication includes:
RFCの場合、公開時にドキュメントに割り当てられたメタデータには次のものが含まれます。
o the RFC number
o RFC番号
o ISSN
o ISSN
o publication date
o 公開日
o Digital Object Identifier (DOI)
o デジタルオブジェクト識別子（DOI）
Additional metadata, such as author name, is assigned earlier in the document creation process, but it is subject to change up to the point of publication. More information on metadata is available in Section 2.3 ("Metadata and Document Registration").
著者名などの追加のメタデータは、ドキュメント作成プロセスの早い段階で割り当てられますが、公開の時点まで変更される可能性があります。メタデータの詳細については、セクション2.3（「メタデータとドキュメントの登録」）を参照してください。
In terms of deciding what to accept in the archive -- a major question for most archives and yet a simple one for the RFC Series -- the RFC Editor accepts documents that are approved for publication by the approving body of one of the document streams: the IETF, IAB, IRTF, or Independent Submission streams [RFC7841]. Each document stream has defined processes on when and how I-Ds are approved and submitted to the RFC Editor for publication. The RFC Editor does not select documents for publication and archiving; the RFC Editor edits and publishes documents approved for publication by the document streams.
アーカイブで何を受け入れるかを決定することに関して（ほとんどのアーカイブでは大きな問題であり、RFCシリーズでは簡単な問題です）、RFCエディターは、ドキュメントストリームのいずれかの承認機関によって公開が承認されているドキュメントを受け入れます。 IETF、IAB、IRTF、または独立した提出ストリーム[RFC7841]。各ドキュメントストリームには、I-Dがいつどのように承認され、RFC Editorに送信されて発行されるかについてのプロセスが定義されています。 RFCエディタは、公開およびアーカイブするドキュメントを選択しません。 RFCエディタは、ドキュメントストリームによる公開が承認されたドキュメントを編集および公開します。
The RFC Editor holds no copyright on I-Ds or RFCs. As per the IETF Trust Legal Provisions [TLP], the copyright for RFCs is held by the authors and the IETF Trust. At any point in time, the current entities providing RFC Editor services must be able to release the archive of RFCs to the IETF Trust.
RFC EditorはI-DまたはRFCの著作権を保持していません。 IETF Trust Legal Provisions [TLP]に従って、RFCの著作権は著者とIETF Trustが保持しています。いつでも、RFCエディターサービスを提供している現在のエンティティは、RFCのアーカイブをIETFトラストにリリースできる必要があります。
Note: The RFC Editor is currently only responsible for RFCs; any associated datasets or other research data is not considered within the RFC Editor's mandate at this time; therefore, no consideration to the archival requirements of such datasets is covered in this document.
注：RFCエディターは現在、RFCのみを担当しています。現時点では、関連するデータセットやその他の研究データは、RFCエディターの権限の範囲内とは見なされません。したがって、このドキュメントでは、そのようなデータセットのアーカイブ要件に対する考慮については触れていません。
Metadata is data about data. In the field of digital archiving, this is the data that clearly identifies every aspect of a document, from its identifier (i.e., the RFC number and the I-D draft string) to the size and file format of the document and more. Metadata is stored in a central registry that records information on exactly what is being preserved and where it is located, information on authenticity and provenance, and details on the hardware and/or software needed to view or create the documents.
メタデータはデータに関するデータです。デジタルアーカイブの分野では、これは、識別子（つまり、RFC番号とI-Dドラフト文字列）からドキュメントのサイズとファイル形式など、ドキュメントのあらゆる側面を明確に識別するデータです。メタデータは中央のレジストリに保存され、保存されているものとその場所に関する正確な情報、信頼性と出所に関する情報、およびドキュメントの表示または作成に必要なハードウェアやソフトウェアの詳細が記録されます。
The RFC Editor maintains this registry in the form of a database that includes all metadata available for documents being edited and for published RFCs. This database feeds the search engine on the RFC Editor website and the info pages available for every RFC (e.g., http://www.rfc-editor.org/info/rfc####).
RFC Editorは、編集中のドキュメントおよび公開されたRFCで利用可能なすべてのメタデータを含むデータベースの形式でこのレジストリを維持します。このデータベースは、RFCエディターのWebサイトの検索エンジンと、すべてのRFCで利用できる情報ページ（http://www.rfc-editor.org/info/rfc####など）にフィードします。
Following is the current list of metadata presented in the RFC info pages:
以下は、RFC情報ページに表示されるメタデータの現在のリストです。
o RFC number
o RFC番号
o Canonical URI
o 正規URI
o Title
o 題名
o Status
o 状態
o Updates (if applicable)
o 更新（該当する場合）
o Updated by (if applicable)
o 更新者（該当する場合）
o Obsoletes (if applicable)
o 廃止（該当する場合）
o Obsoleted by (if applicable)
o 廃止（該当する場合）
o Authors
o 著者
o Stream
o ストリーム
o Abstract
o 概要
o Content-Type
o コンテンツタイプ
o Character Set
o キャラクターセット
o ISSN
o ISSN
o Publication date
o 発行日
o Digital Object Identifier (DOI)
o デジタルオブジェクト識別子（DOI）
The following metadata will be added in the future:
次のメタデータは将来追加される予定です。
o Publication format URIs Info pages also include links to errata, IPR searches, and both plain-text and XML citation files.
o公開形式のURI情報ページには、正誤表、IPR検索、プレーンテキストとXMLの両方の引用ファイルへのリンクも含まれています。
In terms of best practice, all documents used as normative references within an RFC would also be stored in the archive. While this is done automatically when the normative reference is another RFC (the usual case), retaining a copy of third-party documents is considered out of scope for the RFC Editor. As the digital archive industry stabilizes, services such as Perma.cc [PERMACC] may be a reasonable compromise. These services provide a permanent URI and image capture of online documents, with a goal of buffering against URI and online availability changes.
ベストプラクティスの観点から、RFC内の規範的な参照として使用されるすべてのドキュメントもアーカイブに保存されます。これは、規範的な参照が別のRFC（通常のケース）である場合に自動的に行われますが、サードパーティのドキュメントのコピーを保持することは、RFCエディターの範囲外と見なされます。デジタルアーカイブ業界が安定するにつれ、Perma.cc [PERMACC]などのサービスは妥当な妥協案になる可能性があります。これらのサービスは、恒久的なURIとオンラインドキュメントの画像キャプチャを提供し、URIとオンラインの可用性の変更に対するバッファリングを目標としています。
2.4. Normalization and Standardization of Canonical File Structure and Format
2.4. 正規のファイル構造とフォーマットの正規化と標準化
The normalization process is perhaps the most technically critical part of digital archiving. The purpose is content preservation -- making sure the data accepted for archiving are in the most stable and easily accessed formats possible for the long-term future and require the least amount of re-engineering and emulation of environments in order to view the document in the future. Normalization is about enabling long-term access to the information within a document.
正規化プロセスは、おそらくデジタルアーカイブの最も技術的に重要な部分です。目的はコンテンツの保存です。アーカイブ用に受け入れられたデータが、長期的に可能な限り最も安定してアクセスしやすい形式であることを確認し、ドキュメントを表示するために環境のリエンジニアリングとエミュレーションを最小限に抑える必要があります。未来。正規化とは、ドキュメント内の情報に長期間アクセスできるようにすることです。
Over the history of the RFC Series, documents have been submitted for publication in a variety of formats, including paper for the earliest RFCs. Today, the majority of RFCs are available in both a canonical plain-text format and PDF format. For exceptions, see the RFC Online Project [RFC-ONLINE].
RFCシリーズの歴史の中で、ドキュメントは、初期のRFCのペーパーを含むさまざまな形式で公開のために提出されてきました。今日、RFCの大部分は、標準のプレーンテキスト形式とPDF形式の両方で利用できます。例外については、RFCオンラインプロジェクト[RFC-ONLINE]を参照してください。
Currently, all RFCs are printed out to paper and stored at time of publication. This has been a reasonable backup plan for several decades. With few of the features one might expect from a digital document format (such as links, metadata within the document, and line drawings), plain-text files do not lose much, if any, information when printed out to paper. However, as the published formats change (see RFC 6949), printing to paper provides less value as much of the metadata that is an intrinsic yet invisible part of the rendered document will be lost in such printing. With that in mind, the focus needs to change to preserving the new file formats electronically.
現在、すべてのRFCは紙に印刷され、公開時に保存されています。これは数十年の間、妥当なバックアップ計画でした。デジタルドキュメント形式に期待される機能（リンク、ドキュメント内のメタデータ、線画など）がほとんどないため、プレーンテキストファイルは、紙に印刷したときに情報が失われることはありません。ただし、公開されたフォーマットが変更されると（RFC 6949を参照）、紙に印刷しても、レンダリングされたドキュメントの本質的でありながら見えない部分であるメタデータの多くがそのような印刷で失われるため、あまり価値がありません。それを念頭に置いて、新しいファイル形式を電子的に保存することに焦点を変更する必要があります。
While each RFC today is printed to paper and all electronic versions stored on multiple hard drives, no particular effort is made to ensure copies of the software used to render or read the canonical plain-text RFC are also archived. The RFC Editor has several choices on how to adapt to the need to archive a more complex set of data and follow best practice as defined by the digital archive community:
今日の各RFCは紙に印刷され、すべての電子バージョンは複数のハードドライブに保存されますが、正規の平文RFCのレンダリングまたは読み取りに使用されるソフトウェアのコピーもアーカイブされるようにするための特別な努力は行われていません。 RFCエディターには、より複雑なデータセットをアーカイブし、デジタルアーカイブコミュニティで定義されているベストプラクティスに従うというニーズに適応する方法について、いくつかの選択肢があります。
o a simplified bitstream preservation model that focuses on standard "best effort" data-retention practices, which rely on backups, upgrades, and regular equipment change to preserve the data. This model assumes that emulators may be built when needed if the formats used go out of common use (a significant part of the model currently followed by the RFC Editor).
o データを保存するためにバックアップ、アップグレード、および定期的な機器の変更に依存する標準の「ベストエフォート」データ保持の手法に焦点を当てた、簡略化されたビットストリーム保存モデル。このモデルは、使用されるフォーマットが一般的に使用されなくなった場合（現在RFCエディターが従うモデルの重要な部分）、必要に応じてエミュレーターを構築できると想定しています。
o a content preservation model that focuses on one publication format as the version most likely to be viewable and provide all necessary metadata in the future. This is a viable option considering that PDF/A-3 [PDF], one of the intended publication formats, was designed for this type of archiving.
o 表示可能性が最も高いバージョンとして1つの公開形式に焦点を当て、将来必要なすべてのメタデータを提供するコンテンツ保存モデル。これは、意図されたパブリケーション形式の1つであるPDF / A-3 [PDF]がこのタイプのアーカイブ用に設計されたことを考えると、実行可能なオプションです。
o a complex bitstream and content preservation model that focuses on archiving the canonical XML and the entire computing environment required to create, view and render all outputs from that file. This is the "best practice" from an archivist's perspective.
o そのファイルからすべての出力を作成、表示、レンダリングするために必要な正規XMLとコンピューティング環境全体のアーカイブに焦点を当てた複雑なビットストリームとコンテンツ保存モデル。これは、アーキビストの観点から見た「ベストプラクティス」です。
Those options are listed in order of least to greatest complexity and expense. More detail on each option is described below.
これらのオプションは、複雑さと費用の少ないものから順に記載されています。各オプションの詳細については、以下で説明します。
When dealing with very simple data structures such as plain-text, ASCII-only files, the experience of the RFC Series suggests that for the last few decades, hardware and operating system changes have had minimal impact on the document files being stored. While a complete failure of an operating system migration corrupted the dataset in the past, that situation represents a somewhat different problem than the tools themselves changing such that plain-text files are not easily read with existing technology. Given that the basic plain-text format and ASCII encoding remain in common use, the standard protections against file corruption and data loss, such as disk mirroring, off-site backups, and periodic restoration testing, will continue to provide access to the entirety of the RFC Series for the foreseeable future. As has been pointed out, both in this document and in broader community discussion, that is not sufficient for complex formats such as XML, HTML, PDF, or other proprietary formats offered by today's large IT companies. The risk of technological change resulting in the file formats mentioned being deprecated or changed without backwards compatibility is fairly high when looking decades or centuries into the future.
プレーンテキスト、ASCIIのみのファイルなどの非常に単純なデータ構造を扱う場合、RFCシリーズの経験から、過去数十年の間、ハードウェアとオペレーティングシステムの変更が、保存されるドキュメントファイルに与える影響は最小限であることが示唆されています。オペレーティングシステムの移行が完全に失敗すると、過去にデータセットが破損しますが、その状況は、ツール自体が変更するのとは多少異なる問題であり、プレーンテキストファイルを既存のテクノロジーで簡単に読み取ることができません。基本的なプレーンテキスト形式とASCIIエンコードが引き続き使用されていることを考えると、ディスクミラーリング、オフサイトバックアップ、定期的な復元テストなど、ファイルの破損とデータ損失に対する標準的な保護機能により、引き続き全体にアクセスできます。近い将来のRFCシリーズ。このドキュメントと広範なコミュニティディスカッションの両方で指摘されているように、XML、HTML、PDFなどの複雑なフォーマット、または今日の大規模IT企業が提供する他の独自フォーマットには十分ではありません。言及されたファイル形式が下位互換性なしに廃止または変更されることになる技術的変更のリスクは、数十年または数世紀先を見た場合、かなり高くなります。
It is recommended that this model of archiving the RFC Series cease to be the primary model after the plain-text, ASCII-only format is no longer the canonical format. Best effort data retention is a necessary but not sufficient level of effort for preserving a digital archive. For more guidance on how to define best effort data retention, the section on "Media and Formats, Summary Recommendations" in the 2009 version of the Digital Preservation Handbook [DPC2009] provides useful and concrete information.
平文、ASCIIのみの形式が標準形式ではなくなった後、RFCシリーズをアーカイブするこのモデルが主要モデルでなくなることをお勧めします。ベストエフォートのデータ保持は、デジタルアーカイブを保存するために必要ですが、十分ではありません。ベストエフォートデータ保持を定義する方法の詳細については、2009年版デジタル保存ハンドブック[DPC2009]の「メディアと形式、推奨事項の概要」のセクションに、有用で具体的な情報が記載されています。
If preserving the information described by a document, rather than the document itself, is the primary purpose of an archive, then focusing efforts on a single file format is a reasonable option. Some well-supported archival tooling projects follow this route, such as Archivematica [ARCHIVEMATICA]. By selecting a feature-rich yet fundamentally stable file format for documents, an organization may avoid expensive whole-environment reconstruction in order to view the document. The PDF/A formats were designed to be an archival format for electronic documents, and PDF/A-3 is one of the options intended for publication as the RFC Series moves from a plain-text canonical format to an XML canonical format with multiple publication formats. A PDF/A-3 file can be produced that embeds the XML from which the PDF/A-3 file was created; this allows for both original and rendered document validation if one has the correct tools available to see the source of the PDF/A-3 file [RFC7995]. The XML is not otherwise visible when viewing the PDF/A-3 file through typical PDF reader software.
ドキュメント自体ではなく、ドキュメントによって記述された情報を保持することがアーカイブの主な目的である場合、単一のファイル形式に焦点を当てることは合理的なオプションです。 Archivematica [ARCHIVEMATICA]など、一部のよくサポートされているアーカイブツールプロジェクトはこのルートに従います。機能豊富であるが根本的に安定したファイル形式をドキュメントに選択することにより、組織はドキュメントを表示するために環境全体の高額な再構築を回避できます。 PDF / A形式は、電子文書のアーカイブ形式になるように設計されており、PDF / A-3は、RFCシリーズがプレーンテキストの正規形式から複数の公開を持つXML正規形式に移行するため、公開を目的としたオプションの1つです。フォーマット。 PDF / A-3ファイルの作成元のXMLを埋め込むPDF / A-3ファイルを作成できます。これにより、PDF / A-3ファイル[RFC7995]のソースを表示するために利用できる正しいツールがあれば、元のドキュメントとレンダリングされたドキュメントの両方の検証が可能になります。通常のPDFリーダーソフトウェアでPDF / A-3ファイルを表示する場合、XMLは表示されません。
When looking at the need to archive RFCs in a resource-limited environment, a content-preservation-only model has merit, but it is not without risks. First, PDF/A-3 will not be the canonical format; it is intended to be one of the rendered outputs. It may contain rendering bugs that were not intended to be in the document. Second, while the various PDF/A formats were designed to be archival, they have not been put to the test of time to determine if they will actually live up to the design goals.
リソースが限られた環境でRFCをアーカイブする必要性を検討する場合、コンテンツ保存のみのモデルにはメリットがありますが、リスクがないわけではありません。まず、PDF / A-3は標準形式ではありません。レンダリングされた出力の1つになることを目的としています。ドキュメントに含まれることを意図していないレンダリングのバグが含まれている可能性があります。第2に、さまざまなPDF / A形式がアーカイブ用に設計されていますが、実際に設計目標を達成できるかどうかを判断するためのテストは行われていません。
This is a valid option to consider, but the risks, priorities, and costs must be discussed by the community before a decision is made to follow this path. The best option may be to combine this with one of the other methods of archiving described in this document to help minimize both risk and cost.
これは考慮すべき有効なオプションですが、リスク、優先順位、およびコストについては、この道をたどる決定を下す前にコミュニティーが話し合う必要があります。最良のオプションは、これをこのドキュメントで説明されている他のアーカイブ方法の1つと組み合わせて、リスクとコストの両方を最小限に抑えることです。
Preserving everything published by the RFC Editor in order to have a permanent record of information, standards, and best practice is arguably the whole point of being an archival series. One can argue that it is not only about the information described in an RFC, it is also about supporting Intellectual Property Rights (IPR) and retaining the history of the Internet. In following this model, however, one must consider the complexity of the archival environment as matching, and possibly exceeding, the complexity of the file formats being preserved.
情報、標準、およびベストプラクティスの永続的な記録を保持するために、RFC Editorによって公開されたすべてのものを保持することは、おそらく、アーカイブシリーズであることの要点です。 RFCに記述されている情報だけでなく、知的財産権（IPR）のサポートとインターネットの履歴の保持についても言えるでしょう。ただし、このモデルに従う場合、アーカイブ環境の複雑さは、保存されているファイル形式の複雑さと一致し、場合によってはそれを超えると見なす必要があります。
Consider a future where XML has been obsoleted for half a century, HTML5 was a format used three to four human generations ago, and PDF/ A-3 is no longer supported by any existing company's reading software. For RFCs that were produced with XML as their canonical format, an archive must not only hold the data, it must also hold the entire computing environment that allows the data to be rendered and viewed. Operating systems and hardware on which those OSs can run, each major version of each piece of software used or relied upon during the publication of an RFC, browsers and readers for HTML, PDF, and any other publication format must be preserved in some fashion. This is considered best practice when archiving digital documents. This is also the most expensive method, and the cost only increases over time as more and more instances of the computing environment must be preserved over the lifetime of the Series.
XMLが半世紀前に廃止された未来を考えてみてください。HTML5は3〜4世代前に使用された形式であり、PDF / A-3は既存の企業の読み取りソフトウェアでサポートされなくなりました。 XMLを標準形式として作成されたRFCの場合、アーカイブはデータを保持するだけでなく、データのレンダリングと表示を可能にするコンピューティング環境全体も保持する必要があります。これらのOSを実行できるオペレーティングシステムとハードウェア、RFCの公開中に使用または依存される各ソフトウェアの各メジャーバージョン、HTML、PDFのブラウザーとリーダー、およびその他の公開形式は、何らかの方法で保存する必要があります。これは、デジタルドキュメントをアーカイブする場合のベストプラクティスと見なされます。これは最も高価な方法でもあり、シリーズの存続期間にわたってコンピューティング環境のインスタンスを維持する必要があるため、時間の経過とともにコストが増加するだけです。
This is a valid option to consider, but the sheer scope of resources required suggests that this must be discussed by the community before a decision is made. Pursuing this may require an entirely different paradigm for the RFC Editor from what has been considered in the past; expanding the scope and resources for the RFC Editor, finding a third party to take over the responsibilities of archiving, or some other option may be necessary.
これは検討すべき有効なオプションですが、必要なリソースの範囲が広いため、決定を下す前にコミュニティがこれを話し合う必要があることを示唆しています。これを追求するには、RFCエディタに、これまで検討されてきたものとはまったく異なるパラダイムが必要になる場合があります。 RFCエディターの範囲とリソースの拡大、アーカイブの責任を引き継ぐ第三者の検索、またはその他のオプションが必要になる場合があります。
Because normalization is a complex subject, it is important to consider how to mitigate the risk of failure of the normalization process.
正規化は複雑なテーマであるため、正規化プロセスの失敗のリスクを軽減する方法を検討することが重要です。
The RFC Editor is responsible for making RFCs available to the Internet community. The canonical version of an RFC does not change once published; any formats officially rendered from the canonical version, however, may change. One way to mitigate the need to preserve the entire computing environment for an RFC, including web browsers and PDF readers, would be to take advantage of the non-canonical nature of the publication formats and re-render them from the canonical source at the point that browser or reader technology has changed sufficiently to make RFCs largely unavailable to 'modern' tools.
RFCエディタは、RFCをインターネットコミュニティで利用できるようにする責任があります。 RFCの正規バージョンは、一度公開されると変更されません。ただし、正規バージョンから正式にレンダリングされた形式は変更される可能性があります。 WebブラウザーやPDFリーダーを含む、RFCのコンピューティング環境全体を保持する必要性を軽減する1つの方法は、パブリケーション形式の非標準的な性質を利用して、その時点で標準的なソースから再レンダリングすることです。そのブラウザーまたはリーダーテクノロジは、RFCを「最新の」ツールでほとんど利用できないようにするために十分に変更されています。
For example, the RFC Editor may develop the practice of annually reviewing the tools needed to view the publication formats created by the RFC Editor to determine whether or not the current common and popular reader technologies (i.e., web browsers, PDF viewers, e-readers) can view the existing publication formats. During that review, the RFC Editor would work with the community to determine if the current publication formats meet the needs of the community and whether any should be retired or added to improve the availability of information to the community at that time.
たとえば、RFCエディターは、RFCエディターによって作成されたパブリケーションフォーマットを表示するために必要なツールを毎年レビューして、現在の一般的で人気のあるリーダーテクノロジー（つまり、Webブラウザー、PDFビューア、eリーダー）かどうかを判断する手法を開発する場合があります。 ）は、既存の発行フォーマットを表示できます。そのレビュー中に、RFCエディターはコミュニティと協力して、現在の公開形式がコミュニティのニーズを満たしているかどうか、その時点でコミュニティへの情報の可用性を向上させるために廃止または追加する必要があるかどうかを判断します。
While the industry best practice on the backup and restoration of data is not sufficient as a long-term archival solution, it is still a necessary part of keeping the Series available now and into the future. In the past, nearly 800 RFCs had to be manually transcribed from paper back to electronic format due to a failed server migration and insufficient backups.
データのバックアップと復元に関する業界のベストプラクティスは、長期的なアーカイブソリューションとしては十分ではありませんが、シリーズを現在および将来にわたって利用できるようにしておくための必要な部分です。以前は、サーバーの移行が失敗し、バックアップが不十分だったため、800近くのRFCを紙から電子形式に手動で転記する必要がありました。
The underlying servers hosting the tools, database, RFCs, and errata are the physical link in the archival environment. While such systems cannot and should not remain static and unchanging, there must be clear documentation regarding the environment, in particular, the storage, backups, and recovery processes for all RFC-related material. The documentation must include information on the refresh cycle for the physical storage and backup media and describe a regular cycle of data restoration and/or migration testing.
ツール、データベース、RFC、およびエラッタをホストしている基盤となるサーバーは、アーカイブ環境の物理リンクです。そのようなシステムは静的で不変のままではあり得ないし、そうであるべきではないが、環境、特にすべてのRFC関連資料のストレージ、バックアップ、およびリカバリープロセスに関する明確な文書がなければならない。ドキュメントには、物理ストレージとバックアップメディアの更新サイクルに関する情報を含め、データの復元や移行テストの定期的なサイクルについて説明する必要があります。
Having a policy regarding digital archiving provides input into the budget process. The main costs associated with digital archives come from the complexity and quantity of the material being archived, as described in Section 2.4 on normalization.
デジタルアーカイブに関するポリシーを持つことは、予算プロセスへのインプットを提供します。正規化に関するセクション2.4で説明されているように、デジタルアーカイブに関連する主なコストは、アーカイブされる資料の複雑さと量から生じます。
Estimating potential costs and providing figures are outside of the scope of this document, but it should be noted that costs are a major factor when determining what level of archival practice an organization will follow.
潜在的なコストの見積もりと数値の提供はこのドキュメントの範囲外ですが、組織が従うアーカイブの実践レベルを決定する際には、コストが主要な要素であることに注意してください。
For more information on potential business plans and cost modeling for digital preservation, see the "Business cases, benefits, costs, and impact" section of the Digital Preservation Handbook [DPC].
デジタル保護の潜在的なビジネスプランとコストモデリングの詳細については、デジタル保護ハンドブック[DPC]の「ビジネスケース、メリット、コスト、および影響」セクションを参照してください。
Given the need to balance cost and complexity with retention of information for historic, legal, and informational purposes, preservation efforts should focus on the XML canonical format files, the PDF/A-3 format files, the xml2rfc tool and its documentation, and at least two PDF reader applications capable of extracting the embedded XML. Care should be taken that the software being included in this archive has a provision for free copies for backup or archival purposes. All other formats and the overall computing environment should be stored as described in "best effort" data retention (Section 2.4.1), which should in turn be described in the appropriate vendor contract for the RFC Publisher.
コストと複雑さのバランスをとり、歴史的、法的、および情報的な目的で情報を保持する必要性を考えると、保存作業は、XML正規フォーマットファイル、PDF / A-3フォーマットファイル、xml2rfcツールとそのドキュメント、および埋め込まれたXMLを抽出できる少なくとも2つのPDFリーダーアプリケーション。このアーカイブに含まれているソフトウェアには、バックアップまたはアーカイブのために無料のコピーが用意されていることに注意してください。他のすべてのフォーマットおよび全体的なコンピューティング環境は、「ベストエフォート」データ保持（セクション2.4.1）に記載されているとおりに格納する必要があります。これは、RFCパブリッシャーの適切なベンダー契約に記載されている必要があります。
Particular preservation efforts should be made by:
特定の保護努力は以下によってなされるべきです：
o choosing a format designed for archiving RFCs (PDF/A-3 as indicated by [RFC7995])
o RFCのアーカイブ用に設計されたフォーマットの選択（[RFC7995]で示されるPDF / A-3）
o embedding the canonical XML format within the PDF/A-3 file for RFCs
o RFCのPDF / A-3ファイル内に正規のXML形式を埋め込む
o retaining a copy of the plain-text or XML file submitted for approved I-Ds
o 承認されたI-Dのために提出されたプレーンテキストまたはXMLファイルのコピーを保持する
o retaining all major versions of the tools and their associated documentation used to acquire and ingest an RFC
o RFCの取得と取り込みに使用されるツールのすべてのメジャーバージョンとそれに関連するドキュメントを保持する
o retaining the final XML file as well as the PDF/A-3 file with the embedded XML
o 最終的なXMLファイルおよびXMLが埋め込まれたPDF / A-3ファイルを保持する
o retaining at least two software reader applications to ensure the PDF/A-3 and XML files can be viewed in the future
o 少なくとも2つのソフトウェアリーダーアプリケーションを保持して、将来PDF / A-3およびXMLファイルを表示できるようにする
o partnering with other digital archives around the world to mirror copies of the target data
o 世界中の他のデジタルアーカイブと提携して、ターゲットデータのコピーをミラーリングする
In order to control costs and focus the archiving effort on the entire content of an RFC, including the metadata and other features embedded within each RFC published in more than just plain text, printing each RFC to paper upon publication is no longer reasonable. Proper data storage and mirrored copies of RFCs provide more efficient and effective copies in case of catastrophic failure of the existing archive of material.
コストを管理し、RFCのコンテンツ全体にアーカイブ作業を集中させるために、プレーンテキストだけでなく、公開された各RFCに埋め込まれたメタデータやその他の機能を含め、公開時に各RFCを紙に印刷することはもはや妥当ではありません。 RFCの適切なデータストレージとミラーコピーは、既存の資料のアーカイブに壊滅的な障害が発生した場合に、より効率的で効果的なコピーを提供します。
Particular focus should be given to finding partners that specialize in digital preservation to ingest RFCs. Ideally, they will ingest all material associated with an RFC, including all metadata, digital signatures, and the approved I-D that was submitted to the RFC Editor. The possibilities and options should be discussed with each archival partner; at minimum, they must ingest copies of RFCs as they are published, with the basic metadata associated with each document.
RFCを取り込むためにデジタル保存を専門とするパートナーを見つけることに特に焦点を当てる必要があります。理想的には、すべてのメタデータ、デジタル署名、およびRFCエディターに送信された承認済みのI-Dを含む、RFCに関連するすべての資料を取り込みます。可能性とオプションについては、各アーカイブパートナーと話し合う必要があります。少なくとも、発行されたRFCのコピーを取り込み、基本的なメタデータを各ドキュメントに関連付ける必要があります。
Preservation efforts should be reviewed and validated through a biennial audit that will verify that the targeted content and all its associated metadata can be read with existing tools. The full process from acquisition to ingestion should be reviewed to ensure that best current practice is being followed from the perspective of the digital archive community. Since the overall model for the digital archive maintained by the RFC Editor follows the OAIS reference model, the associated audit guidelines should also be followed. While the RFC Editor does not seek to be recognized as 'OAIS-compliant' at this time, use of the ISO standard "Space data and information transfer systems -- Audit and certification of trustworthy digital repositories" [ISO16363] would provide a solid, accepted method for structuring an audit for this digital archive.
保存の取り組みは、対象となるコンテンツとそれに関連するすべてのメタデータが既存のツールで読み取れることを確認する隔年監査を通じてレビューおよび検証する必要があります。取得から取り込みまでの全プロセスを見直して、デジタルアーカイブコミュニティの観点から現在のベストプラクティスが確実に実行されるようにする必要があります。 RFC Editorによって維持されるデジタルアーカイブの全体的なモデルはOAIS参照モデルに従っているため、関連する監査ガイドラインにも従う必要があります。 RFCエディタは現時点では「OAIS準拠」として認識されることを求めていませんが、ISO標準の「スペースデータおよび情報転送システム-信頼できるデジタルリポジトリの監査および認証」[ISO16363]を使用すると、確実な結果が得られます。このデジタルアーカイブの監査を構造化するための受け入れられた方法。
The RFC Series is worth archiving. It contains the history of the early Internet, as well as some of the key standards for Internet technology and best practice today. Who knows what the community will create in the future? There are many ways to preserve the Series, from relying on preservation of the bits, to focusing on a single file format, to preserving the entire computing environment. Each possibility, or permutations of them, involves risks and requires varying levels of resources. The goal of this document is to describe the possibilities and associated risks so that the community can come to an informed decision regarding what it is willing to see supported far into the future.
RFCシリーズはアーカイブする価値があります。これには、初期のインターネットの歴史だけでなく、インターネット技術と今日のベストプラクティスの主要な標準も含まれています。コミュニティが将来何を作成するかを誰が知っていますか？シリーズを保持するには、ビットの保持に依存することから、単一のファイル形式に焦点を合わせること、コンピューティング環境全体を保持することまで、多くの方法があります。それぞれの可能性、またはそれらの順列にはリスクが伴い、さまざまなレベルのリソースが必要になります。このドキュメントの目的は、コミュニティが将来にわたってサポートされることを望んでいることに関して情報に基づいた意思決定にコミュニティが参加できるように、可能性と関連するリスクを説明することです。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
This document assumes that the origination of RFCs via the RFC Editor is secure and trusted. With that assumption, the activities discussed in this document do not affect the security of the Internet.
このドキュメントは、RFCエディタによるRFCの作成が安全で信頼できることを前提としています。その前提の下で、このドキュメントで説明するアクティビティはインターネットのセキュリティに影響を与えません。
[ARCHIVEMATICA] "Archivematica", <https://www.archivematica.org/wiki/ Main_Page>.
[ARCHIVEMATICA] "Archivematica"、<https://www.archivematica.org/wiki/ Main_Page>。
[DPC] Digital Preservation Coalition, "Digital Preservation Handbook", 2015, <http://dpconline.org/handbook>.
[DPC] Digital Preservation Coalition、「Digital Preservation Handbook」、2015年、<http://dpconline.org/handbook>。
[DPC2009] Digital Preservation Coalition, "Digital Preservation Handbook", 2009, <http://www.dpconline.org/docman/digital-preservation-handbook/304-digital-preservation-handbook-media-and-formats>.
[DPC2009] Digital Preservation Coalition、「Digital Preservation Handbook」、2009、<http://www.dpconline.org/docman/digital-preservation-handbook/304-digital-preservation-handbook-media-and-formats>。
[ISO14721] International Organization for Standardization, "Space data and information transfer systems -- Open archival information system (OAIS) -- Reference model", ISO 14721:2012, 2012.
[ISO14721]国際標準化機構、「宇宙データおよび情報転送システム-オープンアーカイブ情報システム（OAIS）-参照モデル」、ISO 14721：2012、2012。
[ISO16363] International Organization for Standardization, "Space data and information transfer systems -- Audit and certification of trustworthy digital repositories", ISO 16363:2012, 2012.
[ISO16363]国際標準化機構、「宇宙データおよび情報転送システム-信頼できるデジタルリポジトリの監査および認証」、ISO 16363：2012、2012。
[LIFE] Hole, B., "LIFE^3: Predictive Costing of Digital Preservation", July 2010, <http://www.life.ac.uk/3/docs/Hole_pasig_v1.pdf>.
[LIFE] Hole、B。、「LIFE ^ 3：Predictive Costing of Digital Preservation」、2010年7月、<http://www.life.ac.uk/3/docs/Hole_pasig_v1.pdf>。
[PDF] International Organization for Standardization, "Document management -- Electronic document file format for long-term preservation -- Part 3: Use of ISO 32000-1 with support for embedded files (PDF/A-3)", ISO 19005-3:2012, 2012.
[PDF]国際標準化機構、「ドキュメント管理-長期保存のための電子ドキュメントファイル形式-パート3：埋め込みファイルをサポートするISO 32000-1の使用（PDF / A-3）」、ISO 19005- 3：2012、2012。
[PERMACC] "Perma.cc", <http://perma.cc/>.
[PERMACC]「Perma.cc」、<http://perma.cc/>。
[RFC-HISTORY] RFC Editor, "Internet Archaeology: Documents from Early History", <http://www.rfc-editor.org/history.html>.
[RFC-HISTORY] RFC Editor、「Internet Archaeology：Documents from Early History」、<http://www.rfc-editor.org/history.html>。
[RFC-ONLINE] RFC Editor, "History of RFC Online Project", <http://www.rfc-editor.org/rfc-online-2000.html>.
[RFC-ONLINE] RFCエディタ、「History of RFC Online Project」、<http://www.rfc-editor.org/rfc-online-2000.html>。
[RFC-PUB] RFC Editor, "Publication Process", <http://www.rfc-editor.org/pubprocess.html>.
[RFC-PUB] RFC Editor、「Publication Process」、<http://www.rfc-editor.org/pubprocess.html>。
[RFC-SERIES] RFC Editor, "About Us", <http://www.rfc-editor.org/RFCoverview.html>.
[RFC-SERIES] RFC Editor、 "About Us"、<http://www.rfc-editor.org/RFCoverview.html>。
[RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 2012, <http://www.rfc-editor.org/info/rfc6635>.
[RFC6635] Kolkman、O。、編、Halpern、J。、編、およびIAB、「RFC Editor Model（Version 2）」、RFC 6635、DOI 10.17487 / RFC6635、2012年6月、<http：// www。 rfc-editor.org/info/rfc6635>。
[RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format Requirements and Future Development", RFC 6949, DOI 10.17487/RFC6949, May 2013, <http://www.rfc-editor.org/info/rfc6949>.
[RFC6949] Flanagan、H。およびN. Brownlee、「RFCシリーズフォーマットの要件と将来の開発」、RFC 6949、DOI 10.17487 / RFC6949、2013年5月、<http://www.rfc-editor.org/info/rfc6949> 。
[RFC7841] Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed., "RFC Streams, Headers, and Boilerplates", RFC 7841, DOI 10.17487/RFC7841, May 2016, <http://www.rfc-editor.org/info/rfc7841>.
[RFC7841] Halpern、J.、Ed。、Daigle、L.、Ed。、and O. Kolkman、Ed。、 "RFC Streams、Headers、and Boilerplates"、RFC 7841、DOI 10.17487 / RFC7841、May 2016、<http ：//www.rfc-editor.org/info/rfc7841>。
[RFC7995] Hansen, T., Ed., Masinter, L., and M. Hardy, "PDF Format for RFCs", RFC 7995, DOI 10.17487/RFC7995, December 2016, <http://www.rfc-editor.org/info/rfc7995>.
[RFC7995] Hansen、T.、Ed。、Masinter、L.、and M. Hardy、 "PDF Format for RFCs"、RFC 7995、DOI 10.17487 / RFC7995、December 2016、<http：//www.rfc-editor。 org / info / rfc7995>。
[TLP] IETF Trust, "Trust Legal Provisions (TLP)", <https://trustee.ietf.org/trust-legal-provisions.html>.
[TLP] IETF Trust、「Trust Legal Provisions（TLP）」、<https://trustee.ietf.org/trust-legal-provisions.html>。
[USLOC] LeFurgy, B., "Life Cycle Models for Digital Stewardship", February 2012, <http://blogs.loc.gov/digitalpreservation/2012/02/ life-cycle-models-for-digital-stewardship/>.
[USLOC] LeFurgy、B。、「デジタルスチュワードシップのライフサイクルモデル」、2012年2月、<http://blogs.loc.gov/digitalpreservation/2012/02/ life-cycle-models-for-digital-stewardship /> 。
IAB Members at the Time of Approval
承認時のIABメンバー
The IAB members at the time this document was approved were (in alphabetical order):
このドキュメントが承認されたときのIABメンバーは（アルファベット順）でした。
Jari Arkko Ralph Droms Ted Hardie Joe Hildebrand Lee Howard Erik Nordmark Robert Sparks Andrew Sullivan Dave Thaler Martin Thomson Brian Trammell Suzanne Woolf
ジャリアルコラルフドロムステッドハーディジョーヒルデブランドリーハワードエリックノードマークロバートスパークスアンドリューサリバンデイブターラーマーティントムソンブライアントラメルスザンヌウルフ
Author's Address
著者のアドレス
Heather Flanagan RFC Editor
ヘザーフラナガンRFCエディター
Email: rse@rfc-editor.org
URI: http://orcid.org/0000-0002-2647-2220