[要約] RFC 2655は、SOIFオブジェクトのためのCIPインデックスオブジェクト形式に関する規格です。このRFCの目的は、SOIFオブジェクトを効率的にインデックス化するためのフォーマットを提供することです。
Network Working Group T. Hardie
Request for Comments: 2655 Equinix
Category: Experimental M. Bowman
Transarc
D. Hardy
Netscape
M. Schwartz
Affinia, Inc.
D. Wessels
NLANR
August 1999
CIP Index Object Format for SOIF Objects
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
The Common Indexing Protocol (CIP) allows servers to form a referral mesh for query handling by defining a mechanism by which cooperating servers exchange hints about the searchable indices they maintain. The structure and transport of CIP are described in (Ref. 1), as are general rules for the definition of index object types. This document describes SOIF, the Summary Object Interchange Format, as an index object type in the context of the CIP framework. SOIF is a machine-readable syntax for transmitting structured summary objects, currently used primarily in the context of the World Wide Web.
一般的なインデックスプロトコル（CIP）は、サーバが、彼らは維持する、検索インデックスについてのサーバ交換のヒントを協調するメカニズムを定義することにより、クエリ処理のための紹介メッシュを形成することができます。インデックス・オブジェクト・タイプの定義のための一般的なルールであるようにCIPの構造及び輸送は、（参考文献1）に記載されています。この文書では、CIPのフレームワークのコンテキストのインデックスオブジェクトタイプとして、SOIF、概要Objectインターチェンジ形式を記述する。 SOIFは現在、主に、ワールド・ワイド・ウェブの文脈で使用される構造化サマリーオブジェクトを、送信するための機械読み取り可能な構文です。
Query referral has often been dismissed as an ineffective strategy for handling searches of Web resources, and Web resources certainly present challenges not present in structured directory services like Rwhois. In situations where a keyword-based free text search is desired, query referral is not likely to be effective because the query will probably be routed to every server participating in the referral mesh. Where a search can be limited by reference to a specific resource attribute, however, query referral is an effective tool. SOIF can be used to create such a known-attribute query mesh because it provides a method for associating attributes with net-addressable resources.
クエリの紹介は、多くの場合、Webリソースの検索、およびWebリソース確かRwhoisのような構造のディレクトリサービスに存在しない存在の課題を処理するための無効な戦略として却下されました。クエリは、おそらく紹介メッシュに参加するすべてのサーバーにルーティングされますので、キーワードベースのフリーテキスト検索が要求される状況では、クエリの紹介が有効である可能性が高いではありません。検索は、特定のリソース属性を参照することによって制限することができる場合は、しかし、クエリの紹介は、効果的なツールです。 SOIFは、それがネットアドレス可能リソースと属性を関連付けるための方法を提供するので、このような既知の属性クエリメッシュを作成するために使用することができます。
SOIF was first defined by the Harvest project [Ref 2.] in January 1994. SOIF was derived from a combination of the Internet Anonymous FTP Archives IETF Working Group (IAFA) templates [Ref 3.] and the BibTeX bibliography format [Ref 4.]. The combination was originally noted for its advantages of providing a convenient and intuitive way for delimiting objects within a stream, and setting apart the URL for easy object access or invocation, while still preserving compatibility with IAFA templates.
SOIFは、最初SOIFは、インターネットの匿名FTPアーカイブIETFワーキンググループ（IAFA）テンプレートの組み合わせ[参考文献3]とのBibTeX書誌フォーマット[参考資料4に由来した1994年1月中に収穫プロジェクト[参考文献2]で定義されました。 ]。組み合わせは、もともとまだIAFAテンプレートとの互換性を維持しながら、ストリーム内のオブジェクトを区切るための便利で直感的な方法を提供し、簡単にオブジェクトへのアクセスや呼び出しのURLを別に設定するその利点のために認められました。
Mic Bowman, Darren Hardy, Mike Schwartz, and Duane Wessels each contributed to the creation of the SOIF format as part of the Harvest Project; later work took place as part of the FIND working group.
マイク・ボウマン、ダレン・ハーディ、マイク・シュワルツ、およびデュアン・ウェッセルそれぞれが収穫プロジェクトの一環として、SOIF形式の創造に貢献しました。以降の作業は、FINDワーキンググループの一部として行われました。
The index object described below will have the MIME type of application/index.obj.HARVEST-SOIF-1.
以下に説明する索引オブジェクトは、アプリケーション/ index.obj.HARVEST-SOIF-1のMIMEタイプを有することになります。
Each summary object has 3 fundamental components: a template type, a URL, and zero or more ATTRIBUTE-VALUE pairs. Because the VALUEs in the ATTRIBUTE-VALUE pairs may contain arbitrary data (cf. Section 3.5), SOIF objects should be encoded in Base64 unless the template type unambiguously establishes that the VALUEs do not contain binary data.
テンプレートタイプ、URL、およびゼロまたはそれ以上の属性値ペア：各サマリーオブジェクトは、3つの基本構成要素を有しています。属性値ペアの値が任意のデータ（参照セクション3.5）を含有してもよいので、テンプレートの種類が明確値はバイナリデータが含まれていないことを確立していない限り、SOIFオブジェクトは、Base64で符号化されるべきです。
The Template type is used to identify the set of ATTRIBUTEs contained within a particular SOIF object. SOIF does not define the template types themselves; it only provides a way to associate the summary object with a predefined template type name. Template types may be registered or unregistered. Unregistered template types provide an indication of available ATTRIBUTE-VALUE pairs, but these may vary both according to the original resource and the method by which the summary object was generated. Registered template types must refer to a formally specified description of all mandatory and optional ATTRIBUTE-VALUE pairs available for that type. See [10] for a description of the process of registering template types with the IANA.
テンプレートタイプは、特定のSOIFオブジェクト内に含まれる属性のセットを識別するために使用されます。 SOIFは、テンプレートの種類そのものを定義していません。それだけで事前に定義されたテンプレート型の名前で要約オブジェクトを関連付けるための方法を提供します。テンプレートの種類は、登録または登録解除することができます。未登録のテンプレートタイプは、利用可能な属性と値のペアの指標を提供するが、これらは両方ともオリジナルのリソースとサマリー・オブジェクトが生成された方法に応じて変化してもよいです。登録されたテンプレートタイプは、そのタイプで使用可能なすべての必須およびオプションの属性と値のペアの正式指定の説明を参照する必要があります。 IANAでテンプレートタイプの登録処理の詳細については[10]を参照してください。
Historically, the template types used by SOIF were derived from IAFA template types (Ref. 3). SOIF objects generated by the Harvest system have a "FILE" template type; in current practice this is the most common template type. The "FILE" template type is a generic template type meant to handle a large variety of web-based resources. No formal specification of it is available, though a list of ATTRIBUTE-VALUE pairs common to the "FILE" template type is found in Appendix A. "DOCUMENT" and "OBJECT" are other generic template-types.
歴史的には、SOIFによって使用されるテンプレートタイプはIAFAテンプレートタイプ（参考文献3）に由来しました。収穫システムによって生成されたSOIFオブジェクトは、「FILE」テンプレートの種類を持っています。現在実際には、これは最も一般的なテンプレートの種類です。 「FILE」テンプレートの種類は、Webベースのリソースの多種多様を扱うためのもの汎用テンプレートの種類です。 「FILE」テンプレートタイプに共通する属性値ペアのリストは、付録A「文書」中に見出され、「OBJECT」されているが、それの正式な仕様は、利用できない他の汎用テンプレート・タイプです。
The use of unregistered template types obviously presents some problems to the correct operation of query referral. Two efforts have been mounted to allow peer-to-peer agreement on the association of template types with specific attribute sets: Netscape's RDM (Ref. 6) and the STARTS project (Ref. 7). Initially, CIP meshes based on systems which use unregisterested template types may need to use these or similar methods to associate template types with specific attribute sets.
未登録のテンプレートタイプを使用することは、明らかに、クエリの紹介を正しく動作させるにはいくつかの問題を提起します。特定の属性を設定して二つの努力は、テンプレートの種類の関連にピア・ツー・ピアの合意ができるようにマウントされています：NetscapeのRDM（参考文献6）とSTARTSプロジェクト（参考文献7）。最初に、CIPは、特定の属性のセットを持つテンプレートタイプを関連付けるために、これらのまたは同様の方法を使用する必要がありunregisterestedテンプレートタイプを使用するシステムに基づいてメッシュ。
Mesh operators are strongly encouraged, however, to migrate to registered template types as soon as is practical. Registered template types allow CIP meshes to derive the definitions of attributes, which enables multiple-language interfaces to the base attributes. In addition, registered template types allow CIP meshes and other users of SOIF to establish the permitted data types and encodings of the VALUEs associated with each ATTRIBUTE. This makes deriving the appropriate matching semantics for a particular VALUE much more straightforward and eliminates the limitations of the default octet-by-octet matching (cf. Section 4.).
すぐに実用的であるとして登録テンプレートタイプに移行し、しかし、オペレータが強く奨励されているメッシュ。登録されたテンプレートの種類は、基本属性に複数言語のインターフェースを可能にする、CIPは、属性の定義を導出するためにメッシュを可能にします。また、登録されたテンプレートの種類は、CIPメッシュとSOIFの他のユーザーが各属性に関連付けられた値の許容データ型と符号化を確立することを可能にします。これは、はるかに簡単な特定の値のための適切なマッチングセマンティクスを導出なり、デフォルトのオクテットごとのオクテットマッチング（節参照4）の制限がなくなります。
Uniform Resource Locators (URLs) (Ref 5.) are used by SOIF as object IDENTIFIERs. SOIF associates its summary objects with net-addressable resources by using the URL by which the resource was addressed as the initial field of the object body. See section 3.4 for the formal grammar associated with SOIF objects.
ユニフォーム・リソース・ロケータ（URL）（参考文献5）は、オブジェクト識別子としてSOIFによって使用されます。 SOIFは、リソースがオブジェクト本体の初期フィールドとして扱われたことにより、URLを使用することにより、ネットアドレス可能リソースとその要約オブジェクトを関連付けます。 SOIFオブジェクトに関連付けられている正式な文法のためのセクション3.4を参照してください。
This association allows the same resource to have multiple summary objects, differentiated only by the URL by which the resource was accessed. This possibility does not, however, impact the usability of the URL as an object IDENTIFIER. Furthermore, since it can be argued that the net address is a salient part of the metadata, there may be compensating benefits to using the URL as an object IDENTIFIER.
この関連付けは、同じリソースは、リソースがアクセスされたURLによってのみ区別複数のサマリーオブジェクトを、有することを可能にします。この可能性は、しかし、オブジェクト識別子としてURLの使いやすさに影響を与えません。それはネットアドレスは、メタデータの凸部であることを主張することができるため、オブジェクト識別子としてURLを使用するメリットが補償することができます。
As noted in Appendix A, the Harvest project used several additional identity attributes ("Gatherer-Name", "Gatherer-Host", "Gatherer-Port" and "Gatherer-Version") to further identify the provenance of a particular object. Within the context of CIP, it may be useful to identify the base sources of particular index objects; see Appendix B for one example of how a SOIF-based CIP hint could use the base source URL.
付録Aで述べたように、収穫プロジェクトは、特定のオブジェクトの出所を特定するためにいくつかの追加のID属性（「Gathererの-名」、「Gathererの-ホスト」、「Gathererのポート」および「Gathererの-バージョン」）を使用しました。 CIPの文脈内では、特定のインデックスオブジェクトのベース・ソースを識別するのに有用であり得ます。 SOIFベースのCIPのヒントは、ベースのソースURLを使用することができる方法の一例については、付録Bを参照してください。
Each summary object has zero or more ATTRIBUTE-VALUE pairs, which contain metadata about the net-addressable resource referenced by the URL. Pairs are composed of an ATTRIBUTE IDENTIFIER, the length of the VALUE, a delimeter, and the VALUE. It should be stressed that ATTRIBUTE VALUE pairs are not CR/LF terminated, but parsed according to grammar set out in section 3.4. In the examples in Section 3.6 and in many other representations of SOIF objects, ATTRIBUTE-VALUE pairs are represented on individual lines to enhance readability. VALUEs may contain CR/LF, however, and implementors must be careful to parse the full VALUE. Implementors of SOIF parsers MUST ignore <CR>,<LF>,<TAB>,<SPACE>, or other whitespace found between the VALUE of an ATTRIBUTE-VALUE pair and the ATTRIBUTE-IDENTIFIER of the subsequent pair.
各要約オブジェクトは、URLで参照されるネット・アドレス可能リソースに関するメタデータを含むゼロ以上の属性と値のペアを持っています。ペアは、属性識別子、VALUE、区切り文字の長さ、および値で構成されています。属性値ペアがCR / LFが終了するが、セクション3.4に記載された文法に従って解析されていないことを強調すべきです。セクション3.6およびSOIFオブジェクトの多くの他の表現の例では、属性値ペアは、可読性を高めるために、個々の行に表されています。値は、しかし、CR / LFを含むことができ、および実装は、完全な値を解析するように注意する必要があります。 SOIFパーサの実装は、<CR> <LF>、<TAB>、<SPACE>、または属性値ペアの値と、それに続く一対の属性識別子との間に見られる他の空白を無視しなければなりません。
The SOIF syntax does not explicitly allow for a single ATTRIBUTE to have multiple VALUEs. To handle multiple VALUEs for the same ATTRIBUTE, SOIF uses an ATTRIBUTE naming convention; a hyphen and positive integer are appended to the ATTRIBUTE name to create an ATTRIBUTE IDENTIFIER VALUE associated with a specific ATTRIBUTE. For example, the ATTRIBUTE IDENTIFIERs "Author-1", "Author-2", and "Author-3" can be used to represent three VALUEs associated with the ATTRIBUTE "Author" where a specific resource has three authors. See section 4 for the implications of this strategy on matching semantics.
SOIFの構文は、明示的に複数の値を持つ単一の属性を許可しません。同じ属性に複数の値を処理するために、SOIFは、命名規則属性を使用しています。ハイフン正の整数が特定の属性に関連付けられた属性識別子の値を作成するために、属性名に付加されています。例えば、属性識別子「著者-1」、「著者-2」、及び「著者-3」は、特定のリソースが3人の著者を有する属性「作成者」に関連する3つの値を表すために使用することができます。一致する意味論上のこの戦略の意味合いのためのセクション4を参照してください。
The SOIF syntax is defined by the following grammar:
SOIFの構文は以下の文法で定義されています。
SOIF ::= OBJECT SOIF |
OBJECT
OBJECT ::= @ TEMPLATE-TYPE { URL ATTRIBUTE-LIST }
TEMPLATE-TYPE ::= IDENTIFIER
ATTRIBUTE-LIST ::= ATTRIBUTE ATTRIBUTE-LIST |
ATTRIBUTE |
NULL
ATTRIBUTE ::= IDENTIFIER {VALUE-SIZE} DELIMITER VALUE
URL ::= RFC1738-URL-Syntax | "-"
IDENTIFIER ::= ALPHA-NUMERIC-STRING
VALUE ::= ARBITRARY-DATA
VALUE-SIZE ::= NUMERIC-STRING
DELIMITER ::= ":<TAB>"
URL a Uniform Resource Locator encoded in the syntax defined by RFC 1738 [3]. If the summary object has no URL associated with it, then a Latin-1 hyphen (octal \055) is used instead.
URLユニフォームリソースロケータ[3] RFC 1738によって定義されたシンタックスでエンコード。要約オブジェクトは、それに関連付けられたURLを持っていない場合は、Latin-1のハイフンは（8進数\ 055）の代わりに使用されています。
IDENTIFIER an ASCII character string that only contains alphanumeric characters and hyphens or underscores. IDENTIFIERs should avoid including hyphens followed by positive integers except when constructing multiple-VALUE ATTRIBUTE IDENTIFIERs.
IDENTIFIER英数字のみとハイフンやアンダースコアが含まれているASCII文字列。識別子は複数値属性識別子を構築する場合を除き、正の整数が続くハイフンを含めないようにしてください。
VALUE a buffer of VALUE-SIZE octets containing the VALUE. The VALUE may contain data in arbitrary formats or encodings, which recipients recognize based on Template-Type.
VALUE値を含むVALUE-SIZEオクテットのバッファ。 VALUEは、受信者がテンプレートタイプに基づいて認識する任意の形式又は符号化データを含むことができます。
VALUE-SIZE a non-negative integer encoded as an ASCII character string. The integer indicates how many octets the VALUE occupies after the DELIMITER.
VALUE-SIZE ASCII文字列としてエンコードされた非負の整数。整数値はDELIMITERの後に占有しているどのように多くのオクテットを示しています。
DELIMITER a two octet delimiter which is a Latin-1 colon (:) and a tab (\t), (octal \072\011).
DELIMITER Latin-1のコロン（:)とタブ（\ t）である2つのオクテットの区切り文字、（011 \進\ 072）。
{ } the Latin-1 curly braces (octal \173 and \175) are used to wrap the VALUE-SIZE (no spaces) as well as the URL and ATTRIBUTE-LIST combination.
{}ラテン1中括弧（173 \ 175 \オクタル）はVALUE-SIZE（スペースなし）並びにURL及び属性リスト組み合わせを包むために使用されます。
@TEMPLATE-TYPE the Latin-1 @ (octal \100) and TEMPLATE-TYPE (no space between them) is used to mark the beginning of the SOIF object.
@ TEMPLATE-TYPEラテン-1 @（8進数100 \）とTEMPLATE-TYPE（それらの間のスペースなし）はSOIFオブジェクトの始まりをマークするために使用されます。
NUMERIC-STRING Zero or more ASCII numerals.
NUMERIC-STRINGゼロ以上のASCII数字。
ALPHA-NUMERIC-STRING Zero or more ASCII letters or numerals, plus hyphens or underscore. [a-z,A-Z,0-9,- and _].
英数字の文字列のゼロ以上のASCII文字や数字、プラスハイフンまたはアンダースコア。 [-Z、A-Z、0-9、 - および_]。
ARBITRARY-DATA Octets of data in arbitrary formats or encodings.
任意の形式又は符号化データの任意データオクテット。
As was discussed in Section 1, query referral of SOIF objects will be most effective when a query identifies a particular ATTRIBUTE or set of ATTRIBUTEs as the target of the query match. A query-identified ATTRIBUTE should be considered to match a SOIF ATTRIBUTE when a case-insentive character-by-character comparison matches that portion of the ATTRIBUTE IDENTIFIER prior to any hyphen-integer suffix. For example, a query which asks for a match on the ATTRIBUTE "author" should match the IDENTIFIERs "author", "Author", "AUTHOR", and "Author-1". [10] discourages the registration of template types containing ATTRIBUTEs which have previously been registered with substantially different definitions. This will help eliminate mis-referral, but a CIP mesh may nonetheless need to maintain a thesaurus matching ATTRIBUTEs from particular template-types to those of other, especially unregistered, template-types.
第1節で説明したように、クエリは、クエリ一致の対象と属性の特定の属性またはセットを識別するとき、SOIFオブジェクトのクエリ照会が最も効果的であろう。クエリ同定ATTRIBUTEは大文字insentive文字単位で比較が前の任意のハイフン整数サフィックスに属性識別子の部分と一致する場合SOIF属性と一致するように考慮されるべきです。例えば、ATTRIBUTE「作者」の一致を要求するクエリは、「著者」、「著者」、「AUTHOR」、および「著者-1」の識別子を一致させる必要があります。 [10]以前に、実質的に異なる定義に登録された属性を含むテンプレートタイプの登録を阻止します。これは誤紹介を排除するのに役立ちますが、CIPメッシュはそれにもかかわらず、他の、特に未登録、テンプレートの種類のものに特定のテンプレート・タイプから属性を一致シソーラスを維持する必要があるかもしれません。
The matching semantics appropriate for a particular VALUE are derived from its data type and encoding. For VALUEs associated with ATTRIBUTEs which are part of a registered template type, the data type and encoding are readily available. For VALUEs associated with ATTRIBUTES associated with unregistered template-types, an octet-by-octet comparison is the default. In cases where previous experience has demonstrated that a particular ATTRIBUTE contains string data, a case-insensitive substring match may be used. For example, in a query against the "AUTHOR" ATTRIBUTE of the generic "DOCUMENT" template type, the query VALUE "Garcia" should match the SOIF VALUEs "Garcia", "GARCIA", and "Jose Garcia y Montes".
特定の値のための適切なマッチングセマンティクスはそのデータ型と符号化から誘導されます。登録されたテンプレートの種類の一部である属性に関連付けられた値のために、データ・タイプおよび符号化は、容易に入手可能です。未登録のテンプレートの種類に関連付けられた属性に関連付けられた値の場合、オクテットごとのオクテットの比較がデフォルトです。以前の経験は、特定の属性は、文字列データが含まれていることを実証している場合には、大文字と小文字を区別しないストリングの一致を使用してもよいです。例えば、一般的な「文書」テンプレート型の「AUTHOR」ATTRIBUTEに対するクエリでは、クエリのVALUE「ガルシアは」SOIF値「ガルシア」、「GARCIA」、および「ホセ・ガルシアYモンテス」に一致する必要があります。
Over time, there may well emerge an understanding of which attributes tend to produce correct query referrals within a mesh. As such understandings emerge, mesh maintainers may wish to define a particular SOIF TEMPLATE-TYPE which restricts included ATTRIBUTES to those likely to foster correct referrals.
時間が経つにつれて、うまくメッシュ内の正しいクエリの紹介を生成する傾向がある属性をの理解が出現することがあります。そのような理解が現れるように、メッシュ保守は、正しい参照を促進する可能性が高いものに含まれている属性を制限する特定のSOIFテンプレート・タイプを定義することを望むかもしれません。
The internationalization of SOIF depends on the registration of template-types. Since TEMPLATE-TYPEs and ATTRIBUTE IDENTIFIERs must be in ASCII characters, only languages which use the ASCII character set are fully supported for unregistered TEMPLATE-TYPEs. For registered template types, in contrast, the specification of an ATTRIBUTE's definition will allow UI designers to present a native-language mapping of the ATTRIBUTE to the end user. Further, the inclusion of data type and encoding information in the description of VALUEs means that any language encoding or character set required by a particular application may be supported. For unregistered template types, the ability of peer servers to pass schema definitions may provide a form of "private registration" which could provide some of the facilities for internationalization available to registered template types. (See above, section 3.1 and Refs. 6 and 7.)
SOIFの国際化は、テンプレートタイプの登録に依存します。テンプレートの種類と属性識別子は、ASCII文字でなければなりませんので、ASCII文字セットを使用する唯一の言語は完全に未登録のテンプレートタイプのためにサポートされています。登録テンプレートのタイプについては、対照的に、属性の定義の仕様はUIの設計者は、エンドユーザーに属性のネイティブ言語マッピングを提示することができます。さらに、値の説明ではデータ型を含めるとコード情報は、特定の用途によって必要とされる任意の言語エンコードまたは文字セットがサポートされてもよいことを意味します。未登録のテンプレートタイプの場合は、スキーマ定義を渡すために、ピア・サーバの能力は、登録されたテンプレートタイプに利用できる国際化のための施設の一部を提供することができ、「民間の登録」の形を提供することができます。 （セクション3.1およびREF、上記を参照。6および7）
The appendices contain example summary objects encoded using specific template types. The following are some example summary objects using the generic "DOCUMENT" SOIF template-type:
付録には、特定のテンプレートの種類を使用してエンコードされた例の概要オブジェクトが含まれています。以下は、一般的な「文書」SOIFテンプレート型を使用して、いくつかの例の概要オブジェクトです：
@DOCUMENT { http://home.netscape.com:80/ Title{19}: Welcome to Netscape Content-Type{9}: text/html Content-Length{5}: 33262 }
@DOCUMENT {http://home.netscape.com:80/タイトル{19}：ネットスケープのContent-Typeへようこそ{9}：テキスト/ HTMLコンテンツ長{5}：33262}
@DOCUMENT { http://home.netscape.com/eng/ssl3/ssl-toc.html Title{19}: SSL Protocol V. 3.0 Content-Type{9}: text/html Content-Length{5}: 5870 Author-1{14}: Alan O. Freier Author-2{14}: Philip Karlton Author-3{14}: Paul C. Kocher Abstract{318}: This document specifies Version 3.0 of the <B>Secure Sockets Layer (SSL V3.0)</B> protocol, a security protocol that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. }
@DOCUMENT {http://home.netscape.com/eng/ssl3/ssl-toc.htmlタイトル{19}：SSLプロトコルV. 3.0のContent-Type {9}：テキスト/ HTMLコンテンツ長{5}：5870著者-1 {14}：アランO.フライアー著者-2 {14}：フィリップKarlton著者-3 {14}：ポールC.コッヘル抽象{318}：この文書は、<B>のSecure Sockets Layerバージョン3.0を指定（ SSL V3.0）</ B>プロトコル、インターネット上で通信プライバシーを提供するセキュリティプロトコル。プロトコルは、クライアント/サーバアプリケーションは、盗聴、改ざん、またはメッセージ偽造を防ぐために設計された方法で通信することができます。 }
@DOCUMENT { http://www.nissanmotors.com/1996/300ZX/pictures/300zx.jpg
Content-Type{10}: image/jpeg
Content-Length{5}: 25940
Last-Modified{31}: Tuesday, 11-Jun-96 19:18:44 GMT
Thumbnail{259}: ..................
}
Please see (Ref. 1) for a general discussion of Security concerns for the CIP framework.
CIPフレームワークのセキュリティ上の懸念の一般的な議論のために（参考文献1）を参照してください。
SOIF currently contains no requirement that any template type contain an authentication ATTRIBUTE. SOIF summary objects lacking authentication ATTRIBUTEs must, therefore, be treated as unreliable indicators of the referenced resource's content. A hostile party could create a summary object which significantly misrepresented a resource's content. As part of a CIP mesh, this data could either channel a large number of requestors to a resource (possibly resulting in a denial of service) or away from a resource (possibly resulting in a loss of appropriate visibility).
SOIFは現在のテンプレートの種類が認証属性が含まれているという要件が含まれていません。認証属性を欠いSOIFサマリーオブジェクトは、それゆえ、参照リソースの内容の信頼性が低い指標として扱われなければなりません。敵対的な政党が大幅にリソースの内容を誤って伝え概要オブジェクトを作成することができます。 CIPメッシュの一部として、このデータは、リソース（おそらくサービスの拒否をもたらす）、または離れてリソースから（おそらく適切な視認性の喪失）にリクエスタ多数のチャネル可能性のいずれか。
[1] Allen, J. and M. Mealling, "The Architecture of the Common Indexing Protocol (CIP)", RFC 2651, August 1999.
[1]アレン、J.とM. Mealling、 "共通インデックスプロトコル（CIP）のアーキテクチャ"、RFC 2651、1999年8月。
[2] The Harvest Information Discovery and Access System: <URL:http://harvest.transarc.com/>.
[2]収穫情報発見とアクセスシステム：<URL：のhttp：//harvest.transarc.com/>。
[3] D. Beckett, IAFA Templates in Use as Internet Metadata, 4th Int'l WWW Conference, December 1995, <URL:http://www.hensa.ac.uk/tools/www/iafatools/>
[3] D.ベケット、インターネットメタデータとして使用中のIAFAテンプレート、第4回国際WWW会議、1995年12月、<URL：のhttp：//www.hensa.ac.uk/tools/www/iafatools/>
[4] L. Lamport, LaTeX: A Document Preparation System, Addison-Wesley, Reading, Mass., 1986.
[4] L.ランポート、乳液：文書準備システム、アディソン・ウェズリー、レディング、マサチューセッツ、1986。
[5] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[5]バーナーズ=リー、T.、Masinter、LとM. McCahill、 "ユニフォームリソースロケータ（URL）"、RFC 1738、1994年12月。
[6] D. Hardey, Resource Description Messages (RDM), W3C Note-rdm-960724, July 24, 1996, <URL:http://www.w3.org/pub/WWW/TR/NOTE-rdm.html>
[6] D. Hardey、リソース記述メッセージ（RDM）、W3Cノート-RDM-960724、1996年7月24日、<URL：のhttp：//www.w3.org/pub/WWW/TR/NOTE-rdm.html >
[7] L. Gravano, K. Chang, H. Garcia-Molina, C. Lagoze, A. Paepcke, STARTS: Stanford Protocol Proposal for Internet Retrieval and Search, January 1997, <URL:http://www-db.stanford.edu/~gravano/starts.html>
[7] L. Gravano、K.チャン、H.ガルシア - モリーナ、C. Lagoze、A. Paepckeは、STARTS：インターネット検索と検索、1997年1月、スタンフォードプロトコルの提案<URL：のhttp：// WWW-DB。 stanford.edu/~gravano/starts.html>
[8] S. Weibel, J. Kunze, C. Lagoze, Dublin Core Metadata for Simple Resource Description, Work in Progress.
[8] S.ヴァイベル、J.クンツェ、C. Lagoze、ダブリンコアメタデータの単純なリソースの説明のために、進行中で働いています。
[9] E. Miller, Dublin Core Element Set Crosswalk, January 1997, <URL:http://www.oclc.org:5046/~emiller/DC/crosswalk.html>
[9] E. Miller氏、ダブリンコア要素セットの横断歩道、1997年1月、<URL：のhttp：//www.oclc.org：5046 /〜/ DC emiller / crosswalk.html>
[10] Hardie, T., "Registration Procedures for SOIF Template Types", RFC 2656, August 1999.
[10]ハーディ、T.、 "SOIFテンプレートタイプの登録手順"、RFC 2656、1999年8月。
Ted Hardie Equinix 901 Marshall Street Redwood City, CA 94063 USA
テッドハーディーエクイニクス901マーシャルストリートレッドウッドシティ、CA 94063 USA
EMail: hardie@equinix.com
メールアドレス：hardie@equinix.com
Mic Bowman Transarc Corporation The Gulf Tower 707 Grant Street Pittsburgh, PA 15219 USA
マイクボーマンTransarcの株式会社湾岸タワー707グラントストリートピッツバーグ、PA 15219 USA
Phone: +1 412 338 4400 EMail: mic@transarc.com
電話：+1 412 338 4400 Eメール：mic@transarc.com
Darren Hardy Netscape Communications Corp. 685 E. Middlefield Road Mountain View, CA 94043 USA
ダレン・ハーディネットスケープ・コミュニケーションズ社685 E.ミドルロード、マウンテンビュー、CA 94043 USA
Phone: +1 415 937 2555 EMail: dhardy@netscape.com
電話：+1 415 937 2555 Eメール：dhardy@netscape.com
Mike Schwartz Affinia, Inc. 621 17th Street, Suite 1700 Denver, CO 80293
マイク・シュワルツアフィニア、Inc.の621 17thストリート、スイート1700デンバー、CO 80293
Phone: +1 (303) 292-4818 E-mail: mfs@affinia.net
電話：+1（303）292-4818 Eメール：mfs@affinia.net
Duane Wessels National Laboratory for Applied Network Research
アプライド・ネットワーク研究のためのデュアン・ウェッセル国立研究所
Phone: +1 303 497 1822 EMail: wessels@nlanr.net
電話：+1 303 497 1822 Eメール：wessels@nlanr.net
Appendix A.
付録A.
Common Attributes for "FILE" Template-type Summary Objects created by Harvest:
収穫が作成した「FILE」テンプレート型の概要オブジェクトの共通属性：
Abstract Brief abstract about the object.
オブジェクトに関する抽象簡単な要約。
Author Author(s) of the object.
オブジェクトの作者の著者。
Description Brief description about the object.
オブジェクトについての説明簡単な説明。
File-Size Number of bytes in the object.
オブジェクト内のバイトのファイルサイズの数。
Full-Text Entire contents of the object.
フルテキストオブジェクトの内容全体。
Gatherer-Host Host on which the Gatherer ran to extract information from the object.
Gathererがオブジェクトから情報を抽出するために実行したGathererの-ホストホスト。
Gatherer-Name Name of the Gatherer that extracted information from the object. (eg. Full-Text, Selected-Text, or Terse).
オブジェクトから情報を抽出収集部の収集者名の名前。 （例えばフルテキスト、選択したテキスト、または簡潔）。
Gatherer-Port Port number on the Gatherer-Host that serves the Gatherer's information.
採集者の情報を提供していますGathererの-ホスト上のGathererのポートのポート番号。
Gatherer-Version Version number of the Gatherer.
Gathererの-バージョン採集のバージョン番号。
Update-Time The time that Gatherer updated the content summary for the object.
更新時Gathererがオブジェクトの内容の要約を更新した時間。
Keywords Searchable keywords extracted from the object.
キーワード検索可能なキーワードは、オブジェクトから抽出されました。
Last-Modification-Time The time that the object was last modified.
最終更新タイムオブジェクトが最後に変更された時間。
MD5 MD5 16-byte checksum of the object.
オブジェクトのMD5 MD5 16バイトのチェックサム。
Refresh-Rate The number of seconds after Update-Time when the summary object is to be re-generated. Defaults to 1 month.
要約オブジェクトを再生成する場合には更新時の秒数をレートに更新します。 1ヶ月にデフォルト設定。
Time-to-Live The number of seconds after Update-Time when the summary object is no longer valid. Defaults to 6 months.
要約オブジェクトが有効なくなったアップデートタイム後の秒のタイム・ツー・ライブ数。 6ヶ月にデフォルト設定。
Title Title of the object.
オブジェクトのタイトルタイトル。
Type The object's type. Some example types are:
オブジェクトの型を入力します。いくつかの例のタイプは次のとおりです。
Archive
Audio
Awk
Backup
Binary
C
CHeader
Command
Compressed
CompressedTar
Configuration
Data
Directory
DotFile
Dvi
FAQ
FYI
Font
FormattedText
GDBM
GNUCompressed
GNUCompressedTar
HTML
Image
Internet-Draft
MacCompressed
Mail
Makefile
ManPage
Object
OtherCode
PCCompressed
Patch
Perl
PostScript
RCS README RFC SCCS ShellArchive Tar Tcl Tex Text Troff Uuencoded WaisSource
RCSのREADME RFC SCCS ShellArchiveタールのTclテックステキストtroffのuuencodeされWaisSource
Update-Time The time that the summary object was last updated. REQUIRED field, no default.
更新時のサマリーオブジェクトが最後に更新された時間。必須フィールド、デフォルトなし。
URL-References Any URL references present within HTML objects.
URL-参照HTMLオブジェクト内に存在する任意のURLを参照します。
Appendix B.
付録B.
Proposed Attributes for a "CIP-HINT" Template Type
「CIP-ヒント」テンプレートの種類のための提案の属性
Attribute-Identifier-List A comma-delimited list whose entries take the form Template-Type:Attribute . This list identifies the attributes against which queries are supported. Because of the current limitation on Identifiers, this list must be in ASCII.
属性：そのエントリーフォームテンプレート型を取るカンマ区切りのリストを属性識別子-LIST。このリストは、クエリがサポートされ、それに対して属性を識別します。そのための識別子の現在の制限のため、このリストはASCIIでなければなりません。
Source The URI of the service which created some or all of the index objects to which this hint applies. Note that this service may be and often is distinct from the server which provides query access to those objects.
ソースこのヒントが適用されるインデックスオブジェクトの一部またはすべてを作成したサービスのURI。このサービスがあることと、多くの場合、それらのオブジェクトへの照会アクセスを提供するサーバーとは区別されることがあります。
Total-Object-Count The total number of index objects in the collection for which the Hint applies. This should be a positive integer.
ヒントが適用されるコレクション内のインデックスオブジェクトの合計数を合計-オブジェクトカウント。これは、正の整数でなければなりません。
Weightlist-[Attribute-Identifier] This construction allows the HINT to contain a weighted list of values for a specific Attribute-Identifier. There may be as many Weightlist entries as there Attribute-Identifiers in the Attribute-Identifier-List. Each Weightlist entry takes the form of Value;Object-Count, where the object count is a positive integer representing the number of objects within the collection which contain that value. Weightlists are comma- delimited.
Weightlist- [属性-識別子]この構造は、ヒントは、特定の属性、識別子の値の重み付きリストを含めることができます。属性-識別子-リストであっ属性-識別子限り多くWeightlistエントリがあるかもしれません。オブジェクト数、オブジェクト数がその値を含むコレクション内のオブジェクトの数を表す正の整数であり;各Weightlistエントリは、値の形をとります。 Weightlists区切りをカンマされています。
Should a Value contain a comma, it should be escaped when incorporated into the weightlist.
weightlistに組み込まれたときの値にカンマが含まれている必要があり、それをエスケープする必要があります。
Threshold-[Attribute-Identifier] If a server wishes not to report infrequently occurring Values in a specific Weightlist, it may declare a threshold under which it will not report Values.
Threshold- [属性-識別子]サーバが特定Weightlistでまれに発生する値を報告しないことを望む場合、それは値を報告しないであろうその下の閾値を宣言することができます。
Certification-Type The type of Certification used for this object
このオブジェクトのために使用され、認証の種類を認定型
Certification The Value of the Certification.
Certification認定の価値。
Date The Date at which the hint was generated
日付ヒントが生成された日付
Example:
例：
@CIP-HINT{ http://nic.nasa.gov:80/Harvest/brokers/NASA/ Attribute-Identifier-list{49}: DOCUMENT:Author, DOCUMENT:Keywords, IMAGE:Subject Source-1{45}: http://nic.nasa.gov/Harvest/gatherers/Eureka/ Source-2{46}: http://techreports.larc.nasa.gov/cgi-bin/NTRS/ Total-Object-Count{5}: 10000 Weightlist-[IMAGE:Subject]{40}: Shuttle;100, Planet;227, Moon;15, Sun;33 Threshold-[IMAGE:Subject]{2}: 10 Weightlist-[DOCUMENT:Author]{49}: Grizzard;12, Aldrin\, Buzz;15, Aldrin\, James;45, Threshold-[DOCMENT:Author]{1}: 5 Certification-Type{13}: PGP-Signature Certification{51}: mQCNAzFNm5QAAEEALUBOolOWKpby+=YtmtBxUZWQgSGFyZGllID Date{29}: Sun, 05 Jan 1997 08:33:33 GMT }
@ CIP-HINT {http://nic.nasa.gov:80/Harvest/brokers/NASA/項目-識別子リスト{49}：DOCUMENT：著者、DOCUMENT：キーワード、IMAGE：件名ソース-1 {45}。 http://nic.nasa.gov/Harvest/gatherers/Eureka/ソース-2 {46}：http://techreports.larc.nasa.gov/cgi-bin/NTRS/全オブジェクト数{5}。 10000 Weightlist- [IMAGE：件名] {40}：シャトル、100、プラネット; 227、月、15日、33 Threshold- [IMAGE：件名] {2}：10 Weightlist- [DOCUMENT：著者] {49}。 Grizzard; 12、アルドリン\、バズ; 15、アルドリン\、ジェームス; 45、Threshold- [DOCMENT：著者] {1}：5認定タイプ{13}：PGP署名証明{51}：mQCNAzFNm5QAAEEALUBOolOWKpby + = YtmtBxUZWQgSGFyZGllID日{ 29}：日、1997年1月5日午前8時33分33秒GMT}
Appendix C.
付録C.
A "Dublin-Core" Template Type [Ref. 8,9]
「ダブリンコア」テンプレートの種類[参考文献。 8,9]
TITLE The name given to the resource by the CREATOR or PUBLISHER.
TITLE CREATORまたはPUBLISHERによってリソースに与えられた名前。
CREATOR The person(s) or organization(s) primarily responsible for the intellectual content of the resource. For example, authors in the case of written documents, artists, photographers, or illustrators in the case of visual resources.
CREATOR人（複数可）または組織（s）は、リソースの知的内容を主に担当。視覚的なリソースの場合の例については、書かれた文書の場合の著者、アーティスト、写真家、またはイラストレーター。
SUBJECT The topic of the resource, or keywords or phrases that describe the subject or content of the resource. The intent of the specification of this element is to promote the use of controlled vocabularies and keywords. This element might well include scheme-qualified classification data (for example, Library of Congress Classification Numbers or Dewey Decimal numbers) or scheme-qualified controlled vocabularies (such as Medical Subject Headings or Art and Architecture Thesaurus descriptors) as well.
SUBJECTリソースの件名や内容を説明し、リソース、またはキーワードやフレーズの話題。この要素の仕様の意図は、統制語彙やキーワードの使用を促進することです。この要素は、ほかにもスキーム修飾分類データ（例えば、米国議会図書館分類の数やデューイ十進数）、または（例えば医療件名見出しやアートと建築シソーラスディスクリプタなど）方式修飾統制語彙が含まれる場合があります。
DESCRIPTION A textual description of the content of the resource, including abstracts in the case of document-like objects or content descriptions in the case of visual resources. Future metadata collections might well include computational content description (spectral analysis of a visual resource, for example) that may not be embeddable in current network systems. In such a case this field might contain a link to such a description rather than the description itself.
ビジュアルリソースの場合の文書のようなオブジェクト又はコンテンツの記述の場合には抄録を含むリソースのコンテンツの説明Aのテキスト記述、。将来のメタデータコレクションはうまく現在のネットワークシステムでは、組み込み可能ではないかもしれない（例えば、視覚的資源のスペクトル解析、）計算内容の記述が含まれる場合があります。そのような場合には、このフィールドには、そのような記述はなく、説明自体へのリンクが含まれている場合があります。
PUBLISHER The entity responsible for making the resource available in its present form, such as a publisher, a university department, or a corporate entity. The intent of specifying this field is to identify the entity that provides access to the resource.
PUBLISHERな出版社、大学部門、または企業体として、現在の形で使用可能なリソースを作るための責任を負うエンティティ。このフィールドを特定する意図は、リソースへのアクセスを提供するエンティティを識別することです。
CONTRIBUTOR Person(s) or organization(s) in addition to those specified in the CREATOR element who have made significant intellectual contributions to the resource but whose contribution is secondary to the individuals or entities specifed in the CREATOR element (for example, editors, transcribers, illustrators, and convenors).
リソースへの重要な知的貢献をしたが、その貢献CREATOR要素にspecifedた個人または団体に二次的である（例えば、編集者、書き起こしている人CREATOR要素で指定されたものに加えて、寄稿者（複数可）または組織（S） 、イラストレーター、およびコンビーナ）。
DATE The date the resource was made available in its present form. The recommended best practice is an 8 digit number in the form YYYYMMDD as defined by ANSI X3.30-1985. In this scheme, the date element for the day this is written would be 19961203, or December 3, 1996. Many other schema are possible, but if used, they should be identified in an unambiguous manner.
DATE日付資源は、その現在の形で利用できるようになりました。 ANSI X3.30-1985によって定義されるように推奨されるベストプラクティスは、フォームYYYYMMDDで8桁の番号です。この方式では、これが書かれている日の日付要素は19961203、または12月3日、1996年他の多くのスキーマは可能ですが、使用している場合、彼らは明確な方法で識別されなければならないのだろう。
TYPE The category of the resource, such as home page, novel, poem, working paper, technical report, essay, dictionary. It is expected that RESOURCE TYPE will be chosen from an enumerated list of types.
そのようなホームページ、小説、詩、ワーキングペーパー、技術報告書、エッセイ、辞書として、リソースのカテゴリを入力します。リソースタイプがタイプの列挙されたリストから選択されることが期待されます。
FORMAT The data representation of the resource, such as text/html, ASCII, Postscript file, executable application, or JPEG image. The intent of specifying this element is to provide information necessary to allow people or machines to make decisions about the usability of the encoded data (what hardware and software might be required to display or execute it, for example). As with RESOURCE TYPE, FORMAT will be assigned from enumerated lists such as registered Internet Media Types (MIME types). In principal, formats can include physical media such as books, serials, or other non-electronic media.
FORMAT、テキスト/ HTML、ASCII、ポストスクリプトファイル、実行可能なアプリケーション、またはJPEG画像としてリソースのデータ表現。この要素を特定する意図は、人や機械が符号化されたデータ（例えば、それを表示または実行するために必要かもしれないもののハードウェアおよびソフトウェア）のユーザビリティに関する意思決定を行うことができるように必要な情報を提供することです。リソースタイプと同じように、FORMATは、登録されたインターネットメディアタイプ（MIMEタイプ）として列挙されたリストから割り当てられます。主に、フォーマットは、書籍、雑誌、または他の非電子媒体などの物理媒体を含むことができます。
IDENTIFIER String or number used to uniquely identify the resource. Examples for networked resources include URLs and URNs (when implemented). Other globally-unique identifiers,such as International Standard Book Numbers (ISBN) or other formal names would also be candidates for this element.
リソースを一意に識別するために使用される識別子の文字列または数字。ネットワークリソースの例は、URLとのURNを（実装時）が挙げられます。こうした国際標準図書番号（ISBN）またはその他の正式名称などの他のグローバル一意識別子は、また、この要素の候補になります。
SOURCE The work, either print or electronic, from which this resource is derived, if applicable. For example, an html encoding of a Shakespearean sonnet might identify the paper version of the sonnet from which the electronic version was transcribed.
SOURCE該当する場合、このリソースは、由来する仕事、印刷または電子、。例えば、シェークスピアのソネットのHTML符号化は、電子版が転写されたソネットの紙バージョンを識別するかもしれません。
LANGUAGE Language(s) of the intellectual content of the resource. Where practical, the content of this field should coincide with the NISO Z39.53 three character codes for written languages.
リソースの知的内容の言語言語（複数可）。どこで実用的な、このフィールドの内容は書かれた言語のためのNISO Z39.53 3文字コードと一致する必要があります。
RELATION Relationship to other resources. The intent of specifying this element is to provide a means to express relationships among resources that have formal relationships to others, but exist as discrete resources themselves. For example, images in a document, chapters in a book, or items in a collection. A formal specification of RELATION is currently under development. Users and developers should understand that use of this element should be currently considered experimental.
他のリソースへのRELATION関係。この要素を特定する意図は、自分自身を他の人に正式な関係を持つリソース間の関係を表現しますが、個別のリソースとして存在するための手段を提供することです。例えば、文書内の画像、本の章、またはコレクション内の項目。 RELATIONの正式な仕様は現在開発中です。ユーザーと開発者は、この要素の使用は、現在、実験的と見なされるべきであることを理解する必要があります。
COVERAGE The spatial locations and temporal durations characteristic of the resource. Formal specification of COVERAGE is currently under development. Users and developers should understand that use of this element should be currently considered experimental.
資源の特性カバレッジ空間的位置および時間的な期間。報道の正式な仕様は現在開発中です。ユーザーと開発者は、この要素の使用は、現在、実験的と見なされるべきであることを理解する必要があります。
RIGHTS The content of this element is intended to be a link (a URL or other suitable URI as appropriate) to a copyright notice, a rights-management statement, or perhaps a server that would provide such information in a dynamic way. The intent of specifying this field is to allow providers a means to associate terms and conditions or copyright statements with a resource or collection of resources. No assumptions should be made by users if such a field is empty or not present.
権利は、この要素のコンテンツは、著作権表示へのリンク（URLまたは必要に応じて他の適切なURI）、権利管理ステートメント、またはおそらく動的な方法でそのような情報を提供するサーバーであることを意図しています。このフィールドを特定する意図は、プロバイダにリソースのリソースまたはコレクションでの契約条件や著作権を関連付けるための手段を可能にすることです。そのようなフィールドが存在し、空であるかどうかいいえ仮定は、ユーザーによって作られるべきではありません。
Example:
例：
@Dublin-Core-1 { ftp://ds.internic.net/internet-drafts/ draft-kunze-dc-00.txt TITLE{52}: Dublin Core Metadata for Simple Resource Description CREATOR-1{9}: S. Weibel CREATOR-2{8}: J. Kunze CREATOR-3{9}: C. Lagoze SUBJECT{44}: The Dublin Core Set of Elements for Metadata DESCRIPTION{46}: Reference description of Dublin Core elements. PUBLISHER{31}: Internet Engineering Task Force CONTRIBUTOR-1{11}: Nick Arnett CONTRIBUTOR-2{15}: Eliot Christian CONTRIBUTOR-3{14}: Martijn Koster CONTRIBUTOR-4{18}: Christian Mogensen CONTRIBUTOR-5{14}: Timothy Niesen CONTRIBUTOR-6{11}: Andrew Wood CONTRIBUTOR-7{10}: Mic Bowman CONTRIBUTOR-8{11}: Dan Connoly CONTRIBUTOR-9{15}: Michael Mauldin CONTRIBUTOR-10{12}: Wick Nichols DATE{16}: February 9, 1997 TYPE{14}: Internet draft FORMAT{4}: Text IDENTIFIER:{21} draft-kunze-dc-00.txt SOURCE{41}: http://purl.oclc.org/metadata/dublin_core LANGUAGE{3}: eng RELATION{24}: Draft Reference Standard COVERAGE{22}: Expires August 8, 1997 RIGHTS{58}: Unlimited Distribution; readers must not cite as standard. }
@ダブリンコア-1 {ftp://ds.internic.net/internet-drafts/ドラフトクンツェ-DC-00.txtのTITLE {52}：ダブリン・コア・メタデータのための単純なリソース説明CREATOR-1 {9}：S 。ヴァイベルCREATOR-2 {8}：J.クンツェCREATOR-3 {9}：C. LagozeのSUBJECT {44}：ダブリンコア要素のリファレンスの説明：メタデータ記述{46}の要素のダブリンコアセット。 PUBLISHER {31}：インターネットエンジニアリングタスクフォースコントリビュータ-1 {11}：ニックアーネットコントリビュータ-2 {15}：エリオットクリスチャンCONTRIBUTOR-3 {14}：マーテホン・コスターコントリビュータ-4 {18}：クリスチャンMogensenのCONTRIBUTOR-5 {14 }：ティモシーNiesenコントリビュータ-6 {11}：アンドリュー・ウッドコントリビュータ-7 {10}：マイクボーマンコントリビュータ-8 {11}：ダン・コノリーコントリビュータ-9 {15}：マイケル・モールディンコントリビュータ-10 {12}：ウィックニコルスDATE {16}：1997年2月9日TYPE {14}：インターネットドラフトFORMAT {4}：テキストID：{21}ドラフトクンツェ-DC-00.txt SOURCE {41}：http://purl.oclc.org/メタデータ/ dublin_core言語{3}：ENG関係{24}：参照標準COVERAGE {22}ドラフト：1997年8月8日RIGHTS {58}有効期限：無制限の配布;読者は、標準として引用してはいけません。 }
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。