Network Working Group H. Van de Sompel
Request for Comments: 4452 LANL
Category: Informational T. Hammond
NPG
E. Neylon
Manifest Solutions
S. Weibel
OCLC
April 2006
The "info" URI Scheme
for Information Assets with Identifiers in Public Namespaces
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document defines the "info" Uniform Resource Identifier (URI) scheme for information assets with identifiers in public namespaces. Namespaces participating in the "info" URI scheme are regulated by an "info" Registry mechanism.
この文書では、公共の名前空間内の識別子との情報資産の「情報」のURI（Uniform Resource Identifier）スキームを定義します。 「情報」URIスキームに参加する名前空間は、「情報」レジストリメカニズムによって規制されています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Information Assets .........................................3
2. Application of the "info" URI Scheme ............................4
3. The "info" Registry .............................................5
3.1. Management Characteristics of the "info" Registry ..........5
3.2. Functional Characteristics of the "info" Registry ..........5
3.3. Maintenance of the "info" Registry .........................6
4. The "info" URI Scheme ...........................................6
4.1. Definition of "info" URI Syntax ............................6
4.2. Allowed Characters Under the "info" URI Scheme .............8
4.3. Examples of "info" URIs ....................................9
5. Normalization and Comparison of "info" URIs ....................10
6. Rationale ......................................................12
6.1. Why Create a New URI Scheme for Identifiers from Public
Namespaces? ...............................................12
6.2. Why Not Use an Existing URI Scheme for Identifiers
from Public Namespaces? ...................................12
6.3. Why Not Create a New URN Namespace ID for
Identifiers from Public Namespaces? .......................12
7. Security Considerations ........................................13
8. IANA Considerations ............................................14
9. Acknowledgements ...............................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................15
This document defines the "info" Uniform Resource Identifier (URI) scheme for information assets that have identifiers in public namespaces but are not part of the URI allocation. By "information asset" this document intends any information construct that has identity within a public namespace.
この文書では、公共の名前空間内の識別子を持っていますが、URI配分の一部ではない情報資産のための「情報」のURI（Uniform Resource Identifier）スキームを定義します。 「情報資産」とは、この文書では、公共の名前空間内の同一性を有する任意の情報構造を意図しています。
In this document, the keywords "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", "MAY NOT", and "RECOMMENDED" are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "NOT SHALL"、 "SHOULD" "ものと"、 "べきではない" "MAY"、 "ないかもしれません"、と解釈されるべきである "お勧め" RFC 2119に記載されているように[RFC2119]及び対応する実装の要求レベルを示します。
There exist many information assets with identifiers in public namespaces that are not referenceable by URI schemes. Examples of such namespaces include Dewey Decimal Classifications [DEWEY], Library of Congress Control Numbers [LCCN], NISO Serial Item and Contribution Identifiers [SICI], NASA Astrophysics Data System Bibcodes [BIBCODE], and National Library of Medicine PubMed identifiers [PMID]. Other candidate namespaces include Online Computer Library Center OCLC Numbers [OCLCNUM] and NISO OpenURL Framework identifiers [OFI].
URIスキームによって参照可能ではない公共の名前空間内の識別子を持つ多くの情報資産が存在します。そのような名前空間の例としては、デューイ十進分類[DEWEY]、アメリカ議会図書館管理番号[LCCN]、NISOシリアル項目と貢献識別子[SICI]、NASA天体物理学データシステムBibcodes [BIBCODE]、および医学PubMedの識別子の国立図書館[PMID]を含めます。他の候補の名前空間は、オンラインコンピュータ図書館センターOCLC番号[OCLCNUM]とNISO OpenURLフレームワーク識別子[OFI]を含んでいます。
The "info" URI scheme facilitates the referencing of information assets that have identifiers in such public namespaces by means of URIs. When referencing an information asset by means of its "info" URI, the asset SHALL be considered a "resource" as defined in RFC 3986 [RFC3986] and SHALL enjoy the same common syntactic, semantic, and shared language benefits that the URI presentation confers. As such, the "info" URI scheme enables public namespaces that are not part of the URI allocation to be represented within the allocation. The "info" URI scheme thus provides a bridging mechanism to allow public namespaces to become part of the URI allocation.
「情報」URIスキームがURIの手段によって、このような公共の名前空間内の識別子を持つ情報資産の参照を容易にします。その「情報」URIによる情報資産を参照する場合、RFC 3986で定義されているように、資産は「資源」とみなされる[RFC3986]およびURIのプレゼンテーション与えることを同じ共通の構文、意味、および共有の言語のメリットを享受する。そのため、「情報」URIスキームが割り当て以内に表現するURI配分の一部ではない公共の名前空間を可能にします。 「情報」URIスキームは、このように公共の名前空間は、URI配分の一部になることを可能にするブリッジングメカニズムを提供します。
Namespaces declared under the "info" URI scheme are regulated by an "info" Registry mechanism. The "info" Registry allows a public namespace that is not part of the URI allocation to be declared in a registration process by the organization that manages it (the Namespace Authority). The "info" Registry supports the declaration of public namespaces that are not part of the URI allocation in a manner that facilitates the construction of URIs for information assets without imposing the burdens of independent URI registration and maintenance of resource representations on the Namespace Authority. Information assets identified within a registered namespace SHALL be added or deleted according to the business processes of the Namespace Authority, and yet MAY be referenced within network applications via the "info" URI in an open, standardized way without additional action on the part of the Namespace Authority.
「情報」のURIスキームの下で宣言した名前空間は、「情報」レジストリメカニズムによって規制されています。 「情報」のレジストリは、それを管理する組織（名前空間庁）によって登録プロセスの中で宣言されるURI配分の一部ではない公共の名前空間を可能にします。 「情報」のレジストリは、名前空間の権限に依存しないURIの登録とリソース表現のメンテナンスの負担をかけることなく、情報資産のURIの建設を促進する方法で、URI配分の一部ではない公共の名前空間の宣言をサポートしています。登録された名前空間内で識別情報資産を追加または削除名前空間庁の業務プロセスに応じて、およびの一部に追加のアクションなしでオープン、標準化された方法で「情報」URIを経由してネットワークアプリケーション内で参照されるかもしれないまだされるものとする（SHALL）名前空間の権限。
The "info" URI scheme exists primarily for identification purposes. Implementations MUST NOT assume that an "info" URI can be dereferenced to a representation of the resource identified by the URI although Namespace Authorities MAY disclose in the registration record references to service mechanisms pertaining to identifiers from the registered namespace. Applications of the "info" URI scheme are restricted to the identification of information assets and the declaration of normalization rules for comparing identifiers of such information assets regardless of whether any services relating to such information assets are accessible via the Internet. References to such services MAY be disclosed within an "info" registration record, but these services SHALL NOT be regarded as authoritative. The "info" URI scheme does not support global resolution methods.
「情報」URIスキームは識別目的のために主に存在します。実装は、名前空間当局は、登録の名前空間から識別子に関連するサービスの仕組みへの登録レコードの参考文献に開示するかもしれないが、「情報」URIは、URIで識別されるリソースの表現に逆参照することができることを仮定してはいけません。 「情報」URIスキームのアプリケーションは、情報資産の識別とにかかわらず、このような情報資産に関連するサービスは、インターネット経由でアクセス可能であるかどうかのような情報資産の識別子を比較するための正規化ルールの宣言に制限されています。このようなサービスへの参照は、「情報」登録レコードに開示することもできるが、これらのサービスは、権威とみなされません。 「情報」URIスキームは、世界的な解決方法をサポートしていません。
Public namespaces that are used for the identification of information assets and that are not part of the URI allocation MAY be registered as namespaces within the "info" Registry. Namespace Authorities MAY register these namespaces in the "info" Registry, thereby making these namespaces available to applications that need to reference information assets by means of a URI. Registrations of public namespaces that are not part of the URI allocation by parties other than the Namespace Authority SHALL NOT be permitted, thereby ensuring against hostile usurpation or inappropriate usage of registered service marks or the public namespaces of others.
情報資産の識別に使用し、それはURI配分の一部ではない公共の名前空間は、「情報」レジストリ内の名前空間として登録することも可能です。名前空間当局は、それによってURIにより情報資産を参照する必要があるアプリケーションにこれらの名前空間を利用可能にする、「情報」のレジストリでこれらの名前空間を登録することもできます。名前空間機関以外の当事者によってURI配分の一部ではない公共の名前空間の登録がそれによって敵対強奪または登録サービスマーク等の公共の名前空間の不適切な使用に対して確実に、認められません。
Registration of a public namespace under the "info" Registry implies no particular functionalities of the identifiers from the registered namespace other than the identification of information assets. No resolution mechanisms can be assumed for the "info" URI scheme, though for any particular namespace there MAY exist mechanisms for resolving identifiers to network services. The definition of such services falls outside the scope of the "info" URI scheme. Registration does not define namespace-specific semantics for identifiers within a registered namespace, though allowable character sets and normalization rules are specified in Sections 4 and 5 so as to ensure that the URIs created using such identifiers are compliant with applications that use URIs.
「情報」のレジストリの下で公共の名前空間の登録は、情報資産の識別以外の登録の名前空間から識別子の特別な機能がないことを意味します。任意の特定の名前空間のためのネットワークサービスへの識別子を解決するためのメカニズムが存在するかもしれませんんが解決機構は、「情報」URIスキームのために仮定することはできません。このようなサービスの定義は、「情報」URIスキームの範囲外。 URIは、そのような識別子を使用して作成することを確実にするためとして許容文字セットと正規化ルールがそのようにセクション4および5で指定されているものの登録は、登録した名前空間内の識別子の名前空間固有のセマンティクスを定義していないURIを使用するアプリケーションに準拠しています。
The registration of a public namespace in the "info" Registry SHALL NOT preclude further development of services associated with that namespace that MAY qualify the namespace for additional publication elsewhere within the URI allocation.
「情報」レジストリ内の公共の名前空間の登録は、URIの割り当て内の他の場所に追加の出版物の名前空間を修飾することを名前空間に関連付けられているサービスの一層の発展を妨げるものではありません。
The "info" Registry provides a mechanism for the registration of public namespaces that are used for the identification of information assets and that are not part of the URI allocation.
「情報」レジストリは、情報資産の識別のために使用され、URI配分の一部ではない公共の名前空間を登録するための機構を提供します。
NISO [NISO], the National Information Standards Organization, will act as the Maintenance Agency for the "info" Registry and will delegate the day-to-day operation of the "info" Registry to a Registry Operator. As the Maintenance Agency, NISO will ensure that the Registry Operator operates the "info" Registry in accordance with a publicly articulated policy document established under NISO governance and made available on the "info" website, <http://info-uri.info/>. The "info" Registry policy defines a review process for candidate namespaces and provides measures of quality control and suitability for entry of namespaces.
NISO [NISO]、国家情報標準化機構は、「情報」のレジストリのための維持管理機関として機能し、レジストリオペレータに「情報」レジストリの日々のオペレーションを委譲します。維持管理機関として、NISOはhttp://info-uri.info <、レジストリオペレータが公にの関節ポリシー文書NISOガバナンスの下で設立され、「情報」のウェブサイト上で利用可能に合わせて「情報」のレジストリを動作することを保証します/>。 「情報」レジストリポリシーは、候補の名前空間のためのレビュープロセスを定義し、名前空間のエントリのための品質管理や適性の対策を提供します。
The "info" Registry will be managed according to policies established under the auspices of NISO. All such policies, as well as the namespace declarations in the "info" Registry, will be public.
「情報」レジストリはNISOの後援の下で定められた方針に従って管理されます。すべてのそのような政策だけでなく、「情報」レジストリ内の名前空間宣言は、パブリックになります。
The "info" Registry will be publicly accessible and will support discovery (by both humans and machines) of:
「情報」レジストリが公にアクセス可能になりますとの（人間と機械の両方による）検出をサポートします：
o string literals identifying the namespaces for which the Registry provides a guarantee of uniqueness and persistence o names and contact information of Namespace Authorities o syntax requirements for identifiers maintained in such namespaces o normalization methodologies for identifiers maintained in such namespaces o network references to a description of service mechanisms (if any) for identifiers maintained in such namespaces o ancillary documentation
レジストリは名前との説明をネットワーク参照Oような名前空間内に維持識別子の正規化方法Oこのような名前空間内に維持識別子の構文要件oを名前空間機関の連絡先O一意性と永続性の保証を提供するための名前空間を識別するO文字列リテラル補助資料Oこのような名前空間内に維持識別子のサービス機構（もしあれば）
Registry entries refer to the corresponding "namespace" and "identifier" components, which are defined in the ABNF given in Section 4.1 of this document.
レジストリエントリは、この文書のセクション4.1で指定されたABNFで定義されている対応する「名前空間」と「識別子」成分を指します。
The public namespaces that MAY be registered in the "info" Registry will be those of interest to the communities served by NISO, and therefore NISO is committed to act as Maintenance Authority for the "info" Registry and to assign a Registry Operator to operate it.
「情報」のレジストリに登録されるかもしれない公共の名前空間は、NISOが提供する地域社会への関心のものとなり、そのためNISOは、「情報」のレジストリのメンテナンス局として動作するようにして、それを動作させるためにレジストリオペレータを割り当てるために尽力して。
NISO, a non-profit association accredited by the American National Standards Institute (ANSI), identifies, develops, maintains, and publishes technical standards to manage information in the digital environment. NISO standards apply technologies to the full range of information-related needs, including retrieval, re-purposing, storage, metadata, and preservation.
NISO、米国規格協会（ANSI）の認定を受けた非営利団体は、特定し開発し、維持し、デジタル環境で情報を管理するための技術基準を公表しています。 NISO規格は、検索、再purposing、ストレージ、メタデータ、および保存を含む情報関連ニーズの全範囲に技術を適用します。
Founded in 1939, incorporated as a not-for-profit education association in 1983, and assuming its current name the following year, NISO draws its support from the communities it serves. The leaders of over 70 organizations in the fields of publishing, libraries, IT, and media serve as its voting members. Hundreds of experts and practitioners serve on NISO committees and as officers of the association.
1983年に非営利教育団体として組み込まれ、1939年に設立され、翌年に現在の名前を想定し、NISOは、それがサービスを提供する地域社会からの支援を描画します。出版、図書館、IT、およびメディアの分野で70以上の組織の指導者たちは、その議決権メンバーとしての役割を果たす。専門家や実務家の何百ものNISO委員会にと協会の役員としての役割を果たす。
NISO has been designated by ANSI to represent US interests to the International Organization for Standardization's (ISO) Technical Committee 46 on Information and Documentation.
NISOは、情報およびドキュメントの標準化の（ISO）技術委員会46のための国際機関に米国の利益を代表するANSIによって指定されています。
The NISO headquarters office is located at 4733 Bethesda Ave., Bethesda, MD 20814, USA. (For further information, see the NISO website, <http://www.niso.org/>.)
NISO本社オフィスは4733ベセスダアベニュー、ベセスダ、MD 20814、USAに位置しています。 （詳細については、NISOのウェブサイト、<http://www.niso.org/>を参照してください。）
The "info" URI syntax presented in this document is conformant with the generic URI syntax defined in RFC 3986 [RFC3986]. This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC 4234 [RFC4234] to define the URI. The following core ABNF productions are used by this specification as defined by Appendix B.1 of RFC 4234: ALPHA, DIGIT, HEXDIG.
この文書の「情報」URI構文は、RFC 3986 [RFC3986]で定義されている一般的なURI構文に準拠しています。この仕様は、URIを定義するためにRFC 4234 [RFC4234]の増補バッカス - ナウアフォーム（ABNF）の表記を使用します。 ALPHA、DIGIT、HEXDIG：RFC 4234の付録B.1によって定義される次のコアABNF制作は、本明細書で使用されます。
The "info" URI syntax is presented in two parts. Part A contains productions specific to the "info" URI scheme, while Part B contains generic productions from RFC 3986 [RFC3986], which are repeated here both for completeness and for reference. The following set of productions (Part A) is specific to the "info" URI scheme:
「情報」URIの構文は、次の2つの部分に示されています。パートBは、完全性のために、参照用の両方ここで繰り返されるRFC 3986 [RFC3986]からの一般的な制作を含有しながらパートAは、「情報」URIスキームに固有の生産を含んでいます。プロダクション（パートA）の次のセットは、「情報」URIスキームに固有のものです：
; Part A: ; productions specific to the "info" URI scheme
;パートA：; 「情報」URIスキームに特有の制作
info-URI = info-scheme ":" info-identifier [ "#" fragment ]
情報-URIは、Info-スキーム= "：" 情報識別子[ "＃" フラグメント]
info-scheme = "info"
情報・スキーム=「情報」
info-identifier = namespace "/" identifier
情報識別子=名前空間「/」識別子
namespace = scheme
名前空間=スキーム
identifier = *( pchar / "/" )
識別子= *（PChar型/ "/"）
; Note that "info" URIs containing dot-segments (i.e., segments ; whose full content consists of "." or "..") MAY NOT be suitable ; for use with applications that perform dot-segment normalization
; 「情報」URIはドットセグメントを含むことに留意されたい（即ち、セグメントを、その完全な内容で構成され、または「..」「」）適当ではないかもしれません。ドットセグメントの正規化を実行するアプリケーションで使用するため
This next set of productions (Part B) are generic productions reproduced from RFC 3986 [RFC3986]:
制作のこの次のセット（パートB）[RFC3986] RFC 3986から再生された一般的な作品です。
; Part B: ; generic productions from RFC 3986 [RFC3986]
;パートB：; RFC 3986 [RFC3986]からの一般的な制作
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
スキーム= ALPHAの*（ALPHA / DIGIT / "+" / " - " / ""）
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
PChar型=予約されていない/ PCT-エンコード/サブdelims / "：" / "@"
fragment = *( pchar / "/" / "?" )
フラグメント= *（PChar型/ "/" / "？"）
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
予約されていない= ALPHA / DIGIT / " - " / "" / "_" / "〜"
pct-encoded = "%" HEXDIG HEXDIG
PCTエンコード= "％" HEXDIG HEXDIG
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" An "info" URI has an "info-identifier" as its scheme-specific part and MAY take an optional "fragment" component. An "info-identifier" is constructed by appending an "identifier" component to a "namespace" component separated by a slash "/" character. The "info" URI scheme is supportive of hierarchical processing as indicated by the presence of the slash "/" character, although the slash "/" character SHOULD NOT be interpreted as a strict hierarchy delimiter.
サブdelims = "！" / "$" / "＆" / "'" / "（" / "）" / "*" / "+" / "、" / ";" /「=」「情報」URIは、スキーマ固有部分として、「情報識別子」を有しており、オプションの「断片」成分を取ることができます。 「情報識別子」スラッシュ「/」文字で区切られた「名前空間」コンポーネントに「識別子」コンポーネントを追加することによって構築されます。スラッシュ「/」文字が厳密な階層の区切り文字として解釈されるべきではないが、スラッシュ「/」文字の存在によって示されるように「情報」URIスキームは、階層処理の支援です。
Values for the "namespace" component of the "info" URI are name tokens composed of URI scheme characters only (cf. the "scheme" production). They identify the public namespace in which the (unescaped) value for the "identifier" component originates, and are registered in the "info" Registry, which guarantees their uniqueness and persistence. Although the "namespace" component is case-insensitive, the canonical form is lowercase and documents that specify values for the "namespace" component SHOULD do so using lowercase letters. An implementation SHOULD accept uppercase letters as equivalent to lowercase in "namespace" names, for the sake of robustness, but SHOULD only generate lowercase "namespace" names, for consistency.
「情報」URIの「名前空間」コンポーネントの値はのみ（「スキーム」の生産を参照されたい）URIスキーム文字で構成される名トークンです。彼らは、「識別子」コンポーネントのための（エスケープ）値が発信されている公共の名前空間を識別し、その独自性と持続性を保証して「情報」のレジストリに登録されています。 「名前空間」コンポーネントは大文字と小文字を区別しないですが、正規の形式は小文字で、「名前空間」コンポーネントの値を指定する文書は小文字を使用し、そうすべきです。実装は堅牢性のために、「名前空間」の名前に小文字に相当すると大文字を受け入れる必要がありますが、唯一の一貫性を保つため、小文字の「名前空間」の名前を生成する必要があります。
Values for the "identifier" component of the "info" URI MAY be viewed as being hierarchical strings composed of path segments built from path segment characters (cf. the "pchar" production), the segments being separated by slash "/" characters, although any semantic interpretation of the "/" character as a hierarchy delimiter MUST NOT be assumed. In their originating public namespace, the (unescaped) values for the "identifier" component identify information assets. The values for the "identifier" component MUST be %-escaped as required by this syntax. The "identifier" component SHOULD be treated as case-sensitive, although the "info" Registry MAY record the case-sensitivity of identifiers from particular registered public namespaces. The "info" Registry MAY also disclose additional normalization rules regarding the treatment of punctuation characters and the like.
「インフォメーション」URIの「識別子」成分の値は、セグメントがスラッシュ「/」文字で区切られている、（「PChar型」生産参照）経路セグメント文字から構築された経路セグメントからなる階層文字列であるとみなすことができます階層区切り文字として「/」文字のいずれかの意味解釈を想定してはならないが。その発信パブリック名前空間に、「識別子」成分に対する（エスケープ）の値は、情報資産を識別する。この構文によって要求されるように、「識別子」成分の値は％でエスケープしていなければなりません。 「情報」レジストリは、特定の登録された公開の名前空間から識別子の大文字と小文字の区別を記録することができるが、「識別子」成分は、大文字と小文字を区別として扱われるべきです。 「情報」のレジストリも句読点の処理等に関する追加の正規化ルールを開示することがあります。
Values for the "fragment" component of the "info" URI are strings composed of path segment characters (cf. the "pchar" production) plus the slash "/" character and the question mark "?" character. No semantic role is assigned to the slash "/" character and the question mark "?" character within the "fragment" component. The (unescaped) values for the "fragment" component identify secondary information assets with respect to the primary information asset, which is referenced by the "info-identifier". The values for the "fragment" component MUST be %-escaped as required by this syntax. The "fragment" component MUST be treated as being case-sensitive.
「情報」URIの「フラグメント」コンポーネントの値は、パスセグメントの文字（「PChar型」の生産を参照）に加えて、スラッシュ「/」の文字と疑問符で構成される文字列です「？」キャラクター。いかなる意味役割は、スラッシュ「/」の文字と疑問符に割り当てられていません「？」 「フラグメント」コンポーネント内の文字。 「断片」成分に対する（エスケープ）の値は、「情報識別子」によって参照される主要情報資産、に対して二次的情報資産を識別する。この構文によって要求されるように、「断片」成分の値は％でエスケープしていなければなりません。 「断片」成分は、大文字と小文字が区別として扱わなければなりません。
The "info" URI syntax uses the same set of allowed US-ASCII characters as specified in RFC 3986 [RFC3986] for a generic URI. An "info" URI string SHOULD be represented as a Unicode [UNICODE] string and be encoded in UTF-8 [RFC3629] form. Reserved characters as well as excluded US-ASCII characters and non-US-ASCII characters MUST be %-escaped before forming the URI. Details of the %-escape encoding can be found in RFC 3986 [RFC3986], Section 2.4.
一般的なURIは、RFC 3986 [RFC3986]で指定されている「情報」URI構文は許さUS-ASCII文字の同じセットを使用しています。 「インフォメーション」URI文字列は、Unicode [UNICODE]文字列として表されるべきであり、UTF-8 [RFC3629]の形で符号化されます。予約文字だけでなく、除外US-ASCII文字と非US-ASCII文字は、URIを形成する前に、％でエスケープでなければなりません。 ％の-escape符号化の詳細は、RFC 3986 [RFC3986]セクション2.4に見出すことができます。
Some examples of syntactically valid "info" URIs are given below:
構文的に有効な「情報」のURIのいくつかの例を以下に示します。
a) info:ddc/22/eng//004.678
A）INFO：DDC / 22 / A // 004678
where "ddc" is the "namespace" component for a Dewey Decimal Classification [DEWEY] namespace and "22/eng//004.678" is the "identifier" component for an identifier of an information asset within that namespace.
「DDC」は、デューイ十進分類法[DEWEY]ネームスペースの「名前空間」成分であり、「// 004.678 22 / ENG」は、その名前空間内の情報資産の識別子は、「識別子」成分である。ここで
The information asset identified by the identifier "22/eng//004.678" in the namespace for (22nd Ed.) English-language Dewey Decimal Classifications is the classification
名前空間内の識別子「22 / ENG // 004.678」で識別される情報資産（22日版）英語デューイ十進分類は、分類であります
"Internet"
"インターネット"
b) info:lccn/2002022641
B）INFO：LCCN / 2002022641
where "lccn" is the "namespace" component for a Library of Congress Control Number [LCCN] namespace and "2002022641" is the "identifier" component for an identifier of an information asset within that namespace.
「LCCN」は会議管理番号[LCCN]ネームスペースのライブラリの「名前空間」成分及び「2002022641」である場合、その名前空間内の情報資産の識別子は、「識別子」成分です。
The information asset identified by the identifier "2002022641" in the namespace for Library of Congress Control Numbers is the metadata record
米国議会図書館のコントロールの数の名前空間内の識別子「2002022641」で識別される情報資産は、メタデータレコードです
"Newcomer, Eric. Understanding Web services: XML, WSDL,
SOAP, and UDDI. Boston: Addison-Wesley, 2002."
c) info:sici/0363-0277(19950315)120:5%3C%3E1.0.TX;2-V
C）INFO：SICI / 0363-0277（19950315）120：5％3C％3E1.0.TX; 2-V
where "sici" is the "namespace" component for a Serial Item and Contribution Identifier [SICI] namespace and "0363-0277(19950315)120:5%3C%3E1.0.TX;2-V" is the "identifier" component for an identifier of an information asset in that namespace in %-escaped form, or in unescaped form "0363-0277(19950315)120:5<>1.0.TX;2-V".
ここで、「SICI」はシリアル項目と貢献識別子[SICI]ネームスペースの「名前空間」成分であり、「0363から0277（19950315）120：5％3C％3E1.0.TX; 2-V」が「識別子」であります％でエスケープ形態で、またはエスケープ形でその名前空間内の情報資産の識別子の成分「0363から0277（19950315）120：5 <> 1.0.TX; 2-V」。
The information asset identified by the identifier "0363-0277(19950315)120:5<>1.0.TX;2-V" in the namespace for Serial Item and Contribution Identifiers is the journal issue
識別子によって識別された情報資産「0363から0277（19950315）120：5 <> 1.0.TX; 2-V」シリアル項目と貢献識別子の名前空間では、ジャーナルの問題です
"Library Journal, Vol. 120, no. 5. March 15, 1995." d) <rdf:Description about="info:bibcode/2003Icar..163..263Z"/>
"図書館雑誌、120巻、なし。5. 3月15日、1995年" D）</ RDF：：= "bibcode / 2003Icar..163..263Z情報" についての説明>
where "bibcode" is the "namespace" component for a NASA Astrophysics Data System (ADS) Bibcode [BIBCODE] namespace and "2003Icar..163..263Z" is the "identifier" component for an identifier of an information asset within that namespace. This example further shows an application of an "info" URI as the subject of a Resource Description Framework (RDF) statement.
NASA天体物理学データシステム（ADS）Bibcode [BIBCODE]名前空間と「2003Icar..163..263Z」はその名前空間内の情報資産の識別子は、「識別子」成分であるため、「bibcode」は、「名前空間」成分であります。この例では、さらにリソース記述フレームワーク（RDF）ステートメントの主語として「情報」URIのアプリケーションを示しています。
The information asset identified by the identifier "2003Icar..163..263Z" in the namespace for NASA ADS Bibcodes is the metadata record in the ADS system that describes the journal article
NASA ADS Bibcodesの名前空間内の識別子「2003Icar..163..263Z」で識別される情報資産は、ジャーナルの記事を記述するADSシステム内のメタデータレコードです
"K. Zahnle, P. Schenk, H. Levison and L. Dones, Cratering rates
in the outer Solar System, Icarus, 163 (2003) pp. 263-289."
e) info:pmid/12376099
E）INFO：PMID / 12376099
where "pmid" is the "namespace" component for a PubMed Identifier [PMID] namespace and "12376099" is the "identifier" component for an identifier of an information asset in that namespace.
「PMID」は、PubMedの識別子[PMID]ネームスペースの「名前空間」成分と「12376099」である場合、その名前空間内の情報資産の識別子は、「識別子」成分です。
The information asset identified by the identifier "12376099" in the namespace for PubMed Identifiers is the metadata record in the PubMed database that describes the journal article
PubMedの識別子の名前空間内の識別子「12376099」で識別される情報資産は、ジャーナルの記事を記述するPubMedのデータベース内のメタデータレコードです
"Wijesuriya SD, Bristow J, Miller WL. Localization and analysis
of the principal promoter for human tenascin-X. Genomics. 2002
Oct;80(4):443-52."
In order to facilitate comparison of "info" URIs, a sequence of normalization steps SHOULD be applied as detailed below. After normalizing the URI strings, comparison of two "info" URIs is then applied on a character-by-character basis as prescribed by RFC 3986 [RFC3986], Section 6.2.1.
「情報」URIの比較を容易にするために、正規化ステップの順序は、以下に詳述するように適用されるべきです。 RFC 3986 [RFC3986]、セクション6.2.1によって規定されたURI文字列を正規化した後、二つの「情報」URIの比較は、その後、文字ごとに適用されます。
The following generic normalization steps SHOULD anyway be applied by applications processing "info" URIs:
次の一般的な正規化手順は、とにかく「情報」のURIを処理するアプリケーションによって適用する必要があります。
a) Normalize the case of the "scheme" component to be
lowercase
b) Normalize the case of the "namespace" component to be
lowercase
c) Unescape all unreserved %-escaped characters in the
"namespace" and "identifier" components
d) Normalize the case of any %-escaped characters in the "namespace" and "identifier" components to be uppercase
D）「名前空間」と「識別子」成分で大文字することを任意％でエスケープ文字の場合を正規化
Further normalization steps MAY be applied by applications to "info" URIs based on rules recorded in the "info" Registry for a registered public namespace, but such normalization steps remain outside of the scope of the "info" URI definition.
また、正規の手順は、登録された公共の名前空間のための「情報」のレジストリに記録されているルールに基づいてアプリケーションへの「情報」のURIによって適用することができるが、このような正規化手順は、「情報」URIの定義の範囲の外に残っています。
Since the "info" URI SHOULD be treated as being case-sensitive, a canonical form MAY only be arrived at by consulting the "info" Registry for possible information on the case-sensitivity for identifiers from a registered public namespace, and any case normalization step to apply. The "info" Registry MAY also disclose additional normalization rules regarding the treatment of punctuation characters and the like.
「情報」URIは、大文字と小文字を区別として扱わなければならないため、標準的な形式しか登録公共の名前空間から識別子の大文字と小文字の区別の可能性については、「情報」のレジストリを参照することによりに到着し、そしてどのような場合の正規化されるかもしれません適用するステップ。 「情報」のレジストリも句読点の処理等に関する追加の正規化ルールを開示することがあります。
In cases, however, where no single canonical form of the "identifier" component exists, it is nevertheless RECOMMENDED that a Namespace Authority nominate a preferred form, which SHOULD be used wherever possible within an "info" URI so that applications MAY have an increased chance of successful comparison of two "info" URIs.
「識別子」コンポーネントの単一のカノニカルフォームが存在しない場合には、しかしながら、名前空間機関はアプリケーションが増加していることができるように「情報」URI内で可能な限り使用されるべきである好ましい形態を指名することをそれにもかかわらず推奨されます2「情報」のURIの比較が成功のチャンス。
Note that "info" URIs containing dot-segments (i.e., segments whose full content consists of "." or "..") MAY NOT be suitable for use with applications that perform dot-segment normalization.
なお、ドットセグメントを含む「情報」のURI（すなわち、その完全な内容で構成されたセグメント「」または「..」）ドットセグメントの正規化を実行するアプリケーションでの使用には適していません。
The following unnormalized forms of an "info" URI
「情報」URIの以下の非正規化形式
U1. INFO:PII/S0888-7543(02)96852-7
U2. info:PII/S0888754302968527
U3. info:pii/S0888%2D7543%2802%2996852%2D7
U4. info:pii/s0888-7543(02)96852-7
are normalized to the following respective forms
以下の各形態に正規化されます
N1. info:pii/S0888-7543(02)96852-7
N2. info:pii/S0888754302968527
N3. info:pii/S0888-7543(02)96852-7
N4. info:pii/s0888-7543(02)96852-7
The "info" URI definition does not prescribe further normalization steps, although applications MAY apply additional normalization steps according to any rules recorded in the "info" Registry for a registered public namespace.
アプリケーションが登録した公共の名前空間のための「情報」のレジストリに記録されたルールに従って、追加の正規化手順を適用することができるが、「情報」URIの定義は、さらに正規の手順を規定していません。
6.1. Why Create a New URI Scheme for Identifiers from Public Namespaces?
6.1. なぜ公共の名前空間から識別子のための新しいURIスキームを作成しますか？
Under RFC 4395, "Guidelines and Registration Procedures for New URI Schemes" [RFC4395], it is stated in Section 2.1 "Demonstrable, New, Long-Lived Utility" that "New URI schemes SHOULD have clear utility to the broad Internet community, beyond that available with already registered URI schemes". The "info" URI scheme allows identifiers within public namespaces, used for the identification of information assets, to be referred to within the URI allocation. Once a namespace is registered in the "info" Registry, the "info" URI scheme enables an information asset with an identifier in that namespace to be referenced by means of a URI. As a result, the information asset SHALL be considered a resource as defined in RFC 3986 [RFC3986] and SHALL enjoy the same common syntactic, semantic, and shared language benefits that the URI presentation confers.
RFC 4395、「ガイドラインと新しいURIスキームのための登録手順」[RFC4395]の下で、それは2.1節に記載されている「論証、新しい、長期性ユーティリティの」新しいURIスキームは広範なインターネットコミュニティへの明確な有用性を有するべきである」ということ、を越えて「既に登録されているURIスキームとその利用可能。 「インフォメーション」URIスキームは、情報資産の識別に使用されるパブリック名前空間内の識別子はURIの割り当て内で参照されることを可能にします。名前空間は、「情報」のレジストリに登録されると、「情報」URIスキームはURIによって参照されるために、その名前空間内の識別子と情報資産を有効にします。その結果、情報資産は、RFC 3986で定義されている[RFC3986]リソース考慮しなければならないとURIのプレゼンテーションが与えるのと同じ一般的な構文、セマンティック、および共有の言語の恩恵を享受する。
6.2. Why Not Use an Existing URI Scheme for Identifiers from Public Namespaces?
6.2. なぜ公共の名前空間から識別子のために既存のURIスキームを使わないのでしょうか？
Existing URI schemes are not suitable for employment as the "info" URI scheme admits of no global dereference mechanism. While examples of resource identifiers minted under other URI schemes MAY not always be dereferenceable, nevertheless there is always a common expectation that such URIs can be dereferenced by various resolution mechanisms, whether they be location-dependent or location-independent resource identifiers. The "info" URI scheme applies to a class of resource identifiers whose Namespace Authorities MAY or MAY NOT choose to disclose service mechanisms. Nevertheless, Namespace Authorities are encouraged to disclose in the "info" registration record references to any such service mechanisms in order to provide a greater utility to network applications.
「情報」URIスキームがありませんグローバル間接参照メカニズムを認めるなど、既存のURIスキームは、雇用には適していません。他のURIスキームの下で鋳造リソース識別子の例は、必ずしもdereferenceableではないかもしれないが、それにもかかわらず、そのようなURIは、それらが位置依存性または位置非依存のリソース識別子であるか否かを、様々な解決メカニズムによって逆参照することができる共通の期待が常に存在します。 「情報」URIスキームが名前空間当局MAYやサービスの仕組みを開示することを選択しない場合がありリソース識別子のクラスに適用されます。それにも関わらず、名前空間当局は、ネットワーク・アプリケーションへのより大きな有用性を提供するために、どのようなサービスの仕組みへの「情報」登録レコードの参考文献に開示することが奨励されています。
6.3. Why Not Create a New URN Namespace ID for Identifiers from Public Namespaces?
6.3. なぜ公共の名前空間から識別子のための新しいURN名前空間のIDを作成しませんか？
RFC 2141 [RFC2141] states that "Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers". The "info" URI scheme, on the other hand, does not assert the persistence of the identifiers created under this scheme but rather of the public namespaces grandfathered under this scheme. It exists primarily to disclose the identity of information assets and to facilitate a lightweight registration mechanism for public namespaces of identifiers managed according to the policies and business models of the Namespace Authorities. The "info" URI scheme is neutral with respect to identifier persistence. Moreover, for
RFC 2141 [RFC2141]は、「統一リソース名（URNのは）として永続的な、場所に依存しない、リソース識別子を提供することを意図している」と述べています。 「情報」URIスキームが、一方で、このスキームの下ではなく、むしろ、このスキームの下で適用除外公共の名前空間を作成した識別子の持続性を主張しません。これは、情報資産の身元を開示することと名前空間当局の政策やビジネスモデルに応じて、管理識別子の公共の名前空間のための軽量の登録メカニズムを促進するために主に存在しています。 「情報」URIスキームは、識別子の持続性に関して中立的です。また、用
"info" to operate as a URN Network Identifier (NID) would require that "info" be constituted as a delegated naming authority. It is not clear that a URN NID would be an appropriate choice for naming authority delegation.
URNネットワーク識別子（NID）として動作する「情報」「情報」が委任命名機関として構成されていることが必要であろう。 URN NIDが権限の委任を命名するための適切な選択であることは明らかではありません。
Further, the "info" URI scheme is not globally dereferenceable in contrast to the specific recommendation given in RFC 1737, "Functional Requirements for Uniform Resource Names" [RFC1737] that "It is strongly recommended that there be a mapping between the names generated by each naming authority and URLs". Individual Namespace Authorities registered in the "info" Registry MAY, however, disclose references to service mechanisms and are encouraged to do so.
さらに、「情報」URIスキームは、強くによって生成された名前との間のマッピングが存在することが推奨される」という「ユニフォームリソース名の機能要件」[RFC1737]は、RFC 1737で与えられた特定の勧告とは対照的に、グローバルdereferenceableではありません各命名権威とURL」。 「情報」レジストリMAYに登録された個別の名前空間の当局は、しかし、サービスの仕組みへの参照を開示し、そうすることが奨励されています。
An extra consideration is that the "urn" URI syntax explicitly excludes generic URI hierarchy by reserving the slash "/" character. An "info" URI, on the other hand, admits of hierarchical processing, while remaining neutral with respect to supporting actual hierarchy, and thus allows the slash "/" character (as well as more liberally allowing the ampersand "&" and tilde "~" characters). It therefore represents a lower barrier to entry for Namespace Authorities in keeping with its intention of acting as a bridging mechanism to allow public namespaces to become part of the URI allocation. In sum, an "info" URI is more widely supportive of "human transcribability" as discussed in RFC 3986 [RFC3986] than is a "urn" URI.
余分な考慮事項は、「URN」URI構文が明示的にスラッシュ「/」文字を予約することにより、一般的なURIの階層を除外することです。実際の階層をサポートに関して中立を維持しながら「情報」URIが、一方、階層処理の余地があり、従って、スラッシュ「/」文字（ならびにより自由にアンパサンドを可能に「＆」とチルダ」が可能〜」文字）。したがって、パブリック名前空間URIの割り当ての一部になることを可能にするブリッジング機構として作用するの意向に合わせて名前空間当局のエントリに低い障壁を表します。 「URN」URIであるよりも、RFC 3986 [RFC3986]で議論するように要するに、「情報」URIは、より広く「ヒトtranscribability」の支援です。
Additionally, the "urn" URI syntax does not support "fragment" components as does the "info" URI syntax for indirect identification of secondary resources.
二次リソースの間接的な識別のための「情報」URIの構文と同様にまた、「URN」URIの構文は、「フラグメント」コンポーネントをサポートしていません。
The "info" URI scheme syntax is subject to the same security considerations as the generic URI syntax described in RFC 3986 [RFC3986].
「情報」URIスキームの構文は、RFC 3986 [RFC3986]で説明した一般的なURI構文と同じセキュリティ上の考慮の対象となります。
While some "info" Namespace Authorities MAY choose to disclose service mechanisms, any security considerations resulting from the execution of such services fall outside the scope of this document. It is strongly recommended that the registration record of an "info" namespace include any such considerations.
いくつかの「情報」名前空間当局はサービスの仕組みを開示することを選択するかもしれないが、そのようなサービスの実行に起因するいかなるセキュリティ上の考慮事項は、この文書の範囲外。強く、「情報」の名前空間の登録レコードがどのような考慮を含めることをお勧めします。
The IANA registry for URI schemes <http://www.iana.org/assignments/uri-schemes.html> SHOULD be updated to include an entry for the "info" URI scheme when the "info" URI scheme is accepted for publication as an RFC. This entry SHOULD contain the following values:
URIスキームのためのIANAレジストリ<http://www.iana.org/assignments/uri-schemes.html>「情報」URIスキームは出版のために受理されたときに「情報」URIスキームのエントリを含めるように更新されるべきですRFCとして。このエントリは、次の値が含まれている必要があります
Scheme Name: info
スキーム名：インフォ
Description: Information Assets with Identifiers in Public Namespaces
説明：公共の名前空間における識別子を持つ情報資産
Reference: RFC 4452
参考：RFC 4452
The authors acknowledge the contributions of Michael Mealling, Verisign, and Patrick Hochstenbach, Ghent University.
著者はマイケル・メオーリング、ベリサイン、およびパトリックHochstenbach、ゲント大学の貢献を認めます。
[RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994.
[RFC1737] Sollins、K.とL. Masinter、 "統一リソース名のための機能要件"、RFC 1737、1994年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141]堀、R.、 "URN構文"、RFC 2141、1997年5月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 115, RFC 4395, February 2006.
[RFC4395]ハンセン、T.、ハーディ、T.、およびL. Masinter、 "新しいURIスキームのためのガイドラインと登録手順"、BCP 115、RFC 4395、2006年2月。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 4.0.0, defined by: The Unicode Standard, Version 4.0". (Reading, MA, Addison-Wesley, 2003). ISBN 0-321-18578-1.
[UNICODE]ユニコードコンソーシアム "によって定義されるUnicode標準、バージョン4.0.0：Unicode規格、バージョン4.0"。 （読書、MA、アディソン・ウェズリー、2003）。 ISBN 0-321-18578-1。
[BIBCODE] "NASA Astrophysics Data System Bibliographic Code", <http://adsdoc.harvard.edu/abs_doc/help_pages/data.html>.
[BIBCODE] "NASA天体物理学データシステム書誌コード"、<http://adsdoc.harvard.edu/abs_doc/help_pages/data.html>。
[DEWEY] "Dewey Decimal Classification", <http://www.oclc.org/dewey/>.
[DEWEY] "デューイ十進分類法"、<http://www.oclc.org/dewey/>。
[LCCN] "Library of Congress Control Number", <http://lcweb.loc.gov/marc/lccn_structure.html>.
[LCCN] "米国議会図書館の管理番号"、<http://lcweb.loc.gov/marc/lccn_structure.html>。
[NISO] "National Information Standards Organization", <http://www.niso.org/>.
[NISO] "国家情報標準化機構"、<http://www.niso.org/>。
[OCLCNUM] "Online Computer Library Center OCLC Control Number", <http://www.oclc.org/bibformats/en/fixedfield/oclc.shtm>.
[OCLCNUM] "オンラインコンピュータ図書館センターOCLC管理番号"、<http://www.oclc.org/bibformats/en/fixedfield/oclc.shtm>。
[OFI] "ANSI/NISO Z39.88-2004, "The OpenURL Framework for Context-Sensitive Services", ISBN 1-880124-61-0", <http://www.niso.org/standards/resources/Z39_88_2004.pdf>.
[OFI] "ANSI / NISO Z39.88-2004、 "文脈依存サービスのためのOpenURLフレームワーク"、ISBN 1-880124-61-0"、<http://www.niso.org/standards/resources/Z39_88_2004 .PDF>。
[PMID] "PubMed Overview", <http://www.ncbi.nlm.nih.gov/entrez/ query/static/overview.html>.
[PMID] "PubMedの概要"、<http://www.ncbi.nlm.nih.gov/entrez/クエリ/静的/ overview.htmlに>。
[SICI] "ANSI/NISO Z39.56-1996 (R2002), "Serial Item and Contribution Identifier (SICI)", ISBN 1-880124-28-9", <http://www.niso.org/standards/resources/Z39-56.pdf>.
【SICI "ANSI / NISO Z39.56-1996（R2002）、 "シリアル項目と貢献識別子（SICI）"、ISBN 1-880124-28-9"、<http://www.niso.org/standards/リソース/ Z39-56.pdf>。
Authors' Addresses
著者のアドレス
Herbert Van de Sompel Los Alamos National Laboratory Research Library, MS-P362 PO Box 1663 Los Alamos, NM 87545-1362 USA
ハーバート・バン・デ・ソンペルロスアラモス国立研究所研究図書館、MS-P362私書箱1663のロスアラモス、NM 87545から1362 USA
EMail: herbertv@lanl.gov
メールアドレス：herbertv@lanl.gov
Tony Hammond Nature Publishing Group Macmillan House 4 Crinan Street London N1 9XW UK
トニー・ハモンドネイチャー・パブリッシング・グループマクミランハウス4 CrinanストリートロンドンN1 9XW英国
EMail: t.hammond@nature.com
メールアドレス：t.hammond@nature.com
Eamonn Neylon Manifest Solutions Bicester, Oxfordshire OX26 2HX UK
イーモンNeylonマニフェストソリューションビスター、オックスフォードシャーOX26 2HX英国
EMail: eneylon@manifestsolutions.com
メールアドレス：eneylon@manifestsolutions.com
Stuart L. Weibel OCLC Online Computer Library Center, Inc. 6565 Frantz Road Dublin, OH 43017-3395 USA
スチュアートL.ワイベルOCLCオンラインコンピュータ図書館センター株式会社6565フランツ・ロードダブリン、オハイオ州43017から3395 USA
EMail: weibel@oclc.org
メールアドレス：weibel@oclc.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。