[要約] RFC 4452は、公共の名前空間で識別子を持つ情報資産のための「info」URIスキームについての要約と目的を提供しています。

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

パブリックネームスペースに識別子を持つ情報資産の「情報」URIスキーム

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).

Copyright(c)The Internet Society(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)スキームを定義します。「情報」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
        
1. Introduction
1. はじめに

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)スキームを定義します。「情報資産」により、このドキュメントは、パブリックネームスペース内にIDを持つ情報構成を意図しています。

1.1. Terminology
1.1. 用語

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.

このドキュメントでは、キーワードは「必要はない」、「そうしない」、「しなければ」、「そうしない」、「そうではない」、「そうでない」、「5月」、「可能性がない」、「推奨」は解釈する必要がありますRFC 2119 [RFC2119]で説明されており、準拠した実装の要件レベルを示しています。

1.2. Information Assets
1.2. 情報資産

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 10進分類[Dewey]、議会図書館管理番号[LCCN]、NISOシリアルアイテムと貢献識別子[SICI]、NASA Astrophysics Data System Bibcodes [Bibcode]、およびNational Library of MedicineのPabmed [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の割り当ての一部ではないパブリックネームスペースの宣言をサポートします。これにより、NameSpace Authorityの独立したURI登録とリソース表現の維持の負担を課すことなく、情報資産のURIの構築を促進します。登録済みの名前空間内で特定された情報資産は、名前空間当局のビジネスプロセスに従って追加または削除されますが、「情報」URIを介してネットワークアプリケーション内で、追加のアクションなしでオープンで標準化された方法で参照される場合があります。名前空間権限。

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スキームは、グローバル解像度の方法をサポートしていません。

2. Application of the "info" URI Scheme
2. 「情報」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スキームの範囲外です。登録は、登録された名前空間内の識別子の名前空間固有のセマンティクスを定義しませんが、許容される文字セットと正規化ルールはセクション4および5で指定されており、そのような識別子を使用して作成されたURIが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割り当ての他の場所で追加の公開の名前空間を適格にする可能性のあるその名前空間に関連するサービスのさらなる開発を排除しません。

3. The "info" Registry
3. 「情報」レジストリ

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.

National Information Standards OrganizationであるNISO [NISO]は、「情報」レジストリのメンテナンス機関として機能し、「情報」レジストリの日々の運用をレジストリオペレーターに委任します。メンテナンス機関として、NISOは、レジストリオペレーターがNISOガバナンスの下で確立され、「情報」Webサイト<http://info-uri.infoで利用可能になった公開されたポリシー文書に従って「情報」レジストリを運用することを保証します。/>。「情報」レジストリポリシーは、候補者の名前空間のレビュープロセスを定義し、品質管理と名前空間の入力の適合性の尺度を提供します。

3.1. Management Characteristics of the "info" Registry
3.1. 「情報」レジストリの管理特性

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の後援の下で確立されたポリシーに従って管理されます。そのようなポリシーはすべて、「情報」レジストリの名前空間宣言が公開されます。

3.2. Functional Characteristics of the "info" Registry
3.2. 「情報」レジストリの機能的特性

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補助文書

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で定義されている対応する「名前空間」および「識別子」コンポーネントを参照しています。

3.3. Maintenance of the "info" Registry
3.3. 「情報」レジストリのメンテナンス

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.

American National Standards Institute(ANSI)が認定した非営利団体であるNISOは、デジタル環境で情報を管理するための技術基準を特定、開発、維持、公開しています。NISO標準は、検索、再利用、保管、メタデータ、保存など、情報関連のニーズの全範囲にテクノロジーを適用します。

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.

1939年に設立され、1983年に非営利教育協会として設立され、翌年の現在の名前を想定して、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はANSIによって指定され、情報と文書に関する国際標準化機関(ISO)技術委員会46の米国の利益を代表しています。

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にあります。(詳細については、NISO Webサイト<http://www.niso.org/>を参照してください。)

4. The "info" URI Scheme
4. 「情報」URIスキーム
4.1. Definition of "info" URI Syntax
4.1. 「情報」URI構文の定義

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構文に準拠しています。この仕様では、RFC 4234 [RFC4234]の拡張されたBackus-Naurフォーム(ABNF)表記を使用して、URIを定義します。次のコアABNFプロダクションは、RFC 4234の付録B.1:Alpha、Digit、Hexdigで定義されているように、この仕様で使用されます。

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つの部分で表示されます。パートAには「情報」URIスキームに固有のプロダクションが含まれていますが、パートBにはRFC 3986 [RFC3986]の一般的なプロダクションが含まれています。次のプロダクションセット(パートA)は、「情報」URIスキームに固有です。

; Part A: ; productions specific to the "info" URI scheme

;パートA:;「情報」URIスキームに固有のプロダクション

   info-URI        = info-scheme ":" info-identifier [ "#" fragment ]
        
   info-scheme     = "info"
        

info-identifier = namespace "/" identifier

info-identifier = namespace "/"識別子

   namespace       = scheme
        
   identifier      = *( 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
        

This next set of productions (Part B) are generic productions reproduced from RFC 3986 [RFC3986]:

この次の一連のプロダクション(パートB)は、RFC 3986 [RFC3986]から再現された一般的なプロダクションです。

; Part B: ; generic productions from RFC 3986 [RFC3986]

;パートB:;RFC 3986 [RFC3986からのジェネリックプロダクション

   scheme          = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
        
   pchar           = unreserved / pct-encoded / sub-delims / ":" / "@"
        
   fragment        = *( pchar / "/" / "?" )
        
   unreserved      = ALPHA / DIGIT / "-" / "." / "_" / "~"
        

pct-encoded = "%" HEXDIG HEXDIG

pct-encoded = "%" 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.
        

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スキーム文字のみで構成される名前のトークンです(「スキーム」制作を参照)。彼らは、「識別子」コンポーネントの(UNESCAPED)値が発生し、「情報」レジストリに登録されているパブリックネームスペースを特定し、独自性と持続性を保証します。「名前空間」コンポーネントはケースインスセンシティブですが、標準形式は小文字であり、「名前空間」コンポーネントの値を指定するドキュメントは、小文字を使用してそれを行う必要があります。実装は、堅牢性のために、「名前空間」名の小文字に相当するものとして大文字を受け入れる必要がありますが、一貫性のために小文字の「名前空間」名のみを生成する必要があります。

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」生産を参照)、セグメントはスラッシュで分離されています。ただし、階層デリミッターとしての「/」文字のセマンティック解釈は想定してはなりません。発信されるパブリックネームスペースでは、「識別子」コンポーネントの(UNESCAPED)値が情報資産を識別します。「識別子」コンポーネントの値は、この構文で要求されるように%エスケープでなければなりません。「識別子」コンポーネントは、ケースに敏感なものとして扱う必要がありますが、「情報」レジストリは、特定の登録されたパブリックネームスペースから識別子の症例感度を記録する場合があります。「情報」レジストリは、句読点などの処理に関する追加の正規化ルールを開示する場合があります。

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.

「情報」の「フラグメント」コンポーネントの値は、パスセグメント文字(「PCHAR」生産を参照)とスラッシュ "/「文字と疑問符」で構成された文字列です。」キャラクター。スラッシュ「/」文字と疑問符」には、セマンティックの役割は割り当てられていませんか?」「フラグメント」コンポーネント内の文字。「フラグメント」コンポーネントの(UNESCAPED)値は、「情報識別子」によって参照される一次情報資産に関する二次情報資産を識別します。「フラグメント」コンポーネントの値は、この構文で要求されるように%エスケープでなければなりません。「フラグメント」コンポーネントは、症例に敏感であると扱わなければなりません。

4.2. Allowed Characters Under the "info" URI Scheme
4.2. 「情報」URIスキームの下で文字を許可します

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構文は、一般的なURIにRFC 3986 [RFC3986]で指定されているのと同じ許可されたUS-ASCII文字のセットを使用します。「情報」URI文字列は、Unicode [Unicode]文字列として表現し、UTF-8 [RFC3629]フォームにエンコードする必要があります。予約済みのキャラクター、除外されたUS-ASCIIキャラクターと非US-ASCIIキャラクターは、URIを形成する前に%エスケープでなければなりません。%エスケープエンコードの詳細は、RFC 3986 [RFC3986]、セクション2.4にあります。

4.3. Examples of "info" URIs
4.3. 「情報」ウリスの例

Some examples of syntactically valid "info" URIs are given below:

構文的に有効な「情報」の例を以下に示します。

a) info:ddc/22/eng//004.678

a) 情報:DDC/22/ENG // 004.678

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 10桁分類[Dewey] NameSpaceの「名前空間」コンポーネントであり、「22/eng // 004.678」は、その名前空間内の情報資産の識別子の「識別子」コンポーネントです。

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」によって識別された情報資産(22nd ed。)の英語のデューイ10進分類は分類です

"Internet"

"インターネット"

b) info:lccn/2002022641

b) 情報: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] Namespaceの「Namespace」コンポーネントであり、「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."

「新人、エリック。ウェブサービスの理解:XML、WSDL、SOAP、およびUDDI。Boston:Addison-Wesley、2002。」

       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] NameSpaceおよび「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
        
       "Library Journal, Vol. 120, no. 5. March 15, 1995."
              d) <rdf:Description about="info: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.

ここで、「bibcode」はNASA天体物理学データシステム(ADS)bibcode [bibcode] namespaceの「名前空間」コンポーネントと「2003icar..163..263z」です。。この例は、リソース説明フレームワーク(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ビブコードの名前空間にある識別子「2003icar..163..263z」によって特定された情報資産は、ジャーナル記事を説明する広告システムのメタデータレコードです

"K. Zahnle, P. Schenk, H. Levison and L. Dones, Cratering rates in the outer Solar System, Icarus, 163 (2003) pp. 263-289."

「K. Zahnle、P。Schenk、H。Levison、L。Dones、外太陽系のクレーター率、Icarus、163(2003)pp。263-289」

e) info:pmid/12376099

e) 情報: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 Identifier [PMID] NameSpaceの「名前空間」コンポーネントであり、「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」によって特定された情報資産は、Journalの記事を説明する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."

「Wijesuriya SD、Bristow J、Miller WL。ヒトTenascin-Xの主要プロモーターのローカリゼーションと分析。2002OCT; 80(4):443-52。」

5. Normalization and Comparison of "info" URIs
5. 「情報」ウリの正規化と比較

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で規定されているように、2つの「情報」URIの比較が文字ごとに適用されます。

The following generic normalization steps SHOULD anyway be applied by applications processing "info" URIs:

とにかく、次の一般的な正規化手順は、「情報」を処理するアプリケーションで適用する必要があります。

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

a) 「スキーム」コンポーネントのケースを正規化することを正規化するb)「名前空間」コンポーネントのケースを小文字にすることを正規化するc)無駄にない「名前空間」および「識別子」コンポーネントのすべての無予定の%escaped文字

d) Normalize the case of any %-escaped characters in the "namespace" and "identifier" components to be uppercase

d) 「名前空間」および「識別子」コンポーネントの%escaped文字のケースを大文字にするために正規化する

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.

ただし、「識別子」コンポーネントの単一の標準形式が存在しない場合、それにもかかわらず、名前空間当局が優先フォームを指名することをお勧めします。2つの「情報」ウリの比較の成功の可能性。

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.

ドットセグメント(つまり、完全なコンテンツが「」または「..」で構成されているセグメント)を含む「情報」は、ドットセグメント正規化を実行するアプリケーションでの使用には適していない場合があります。

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. Rationale
6. 根拠
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によって参照されます。その結果、情報資産は、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スキームの下で鋳造されたリソース識別子の例は必ずしも逆もはないかもしれませんが、それでも、そのようなURIが場所に依存しているか、位置に依存しないリソース識別子であろうと、そのようなURIがさまざまな解像度メカニズムによって提示される可能性があるという一般的な期待が常にあります。「情報」URIスキームは、名前空間当局がサービスメカニズムを開示するかどうかを選択しない場合があるリソース識別子のクラスに適用されます。それにもかかわらず、ネットワークアプリケーションにより多くのユーティリティを提供するために、名前空間当局は、そのようなサービスメカニズムへの「情報」登録記録の参照で開示することをお勧めします。

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スキームは、RFC 1737に与えられた特定の推奨事項、「ユニフォームリソース名の機能要件」[RFC1737]とは対照的に、グローバルに逆もはありません。各命名権限とURL」。ただし、「情報」レジストリに登録されている個々の名前空間当局は、サービスメカニズムへの参照を開示し、そうすることを奨励される場合があります。

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階層を明示的に除外することです。一方、「情報」ウリは、実際の階層をサポートすることに関してニュートラルを維持しながら、階層処理を認め、したがってスラッシュ「/」文字(さらに自由にAmpersand "&" and "and Tilde"を許可します」〜 "文字)。したがって、パブリックネームスペースがURIの割り当ての一部になることを可能にする橋渡しメカニズムとして行動するという意図に沿って、名前空間当局のエントリへのより低い障壁を表しています。要するに、「情報」URIは、RFC 3986 [RFC3986]で議論されているように、「URN」URIよりも「人間の転写性」を広く支持しています。

Additionally, the "urn" URI syntax does not support "fragment" components as does the "info" URI syntax for indirect identification of secondary resources.

さらに、「urn」URI構文は、「フラグメント」コンポーネントをサポートしていません。

7. Security Considerations
7. セキュリティに関する考慮事項

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.

一部の「情報」名前空間当局は、サービスメカニズムを開示することを選択する場合がありますが、そのようなサービスの実行に起因するセキュリティ上の考慮事項は、このドキュメントの範囲外にあります。「情報」名前空間の登録記録には、そのような考慮事項が含まれることを強くお勧めします。

8. IANA Considerations
8. IANAの考慮事項

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スキームのエントリを含めるように更新する必要があります。RFCとして。このエントリには、次の値を含める必要があります。

Scheme Name: info

スキーム名:情報

Description: Information Assets with Identifiers in Public Namespaces

説明:パブリックネームスペースに識別子を持つ情報資産

Reference: RFC 4452

参照:RFC 4452

9. Acknowledgements
9. 謝辞

The authors acknowledge the contributions of Michael Mealling, Verisign, and Patrick Hochstenbach, Ghent University.

著者は、ゲント大学のマイケル・ミールリングとパトリック・ホッホステンバッハの貢献を認めています。

10. References
10. 参考文献
10.1. Normative References
10.1. 引用文献

[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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.

[RFC2141] Moats、R。、「Urn Syntax」、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] Berners-Lee、T.、Fielding、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] Crocker、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] Hansen、T.、Hardie、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 Consortium、「Unicode Standard、バージョン4.0.0、定義:Unicode Standard、バージョン4.0」。(Reading、Ma、Addison-Wesley、2003)。ISBN 0-321-18578-1。

10.2. Informative References
10.2. 参考引用

[BIBCODE] "NASA Astrophysics Data System Bibliographic Code", <http://adsdoc.harvard.edu/abs_doc/help_pages/data.html>.

[bibcode] "NASA Astrophysics Data System Bibliographic Code"、<http://adsdoc.harvard.edu/abs_doc/help_pages/data.html>。

[DEWEY] "Dewey Decimal Classification", <http://www.oclc.org/dewey/>.

[Dewey]「Dewey 10年分類」、<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]「National Information Standards Organization」、<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_2004440044.pdf>。

[PMID] "PubMed Overview", <http://www.ncbi.nlm.nih.gov/entrez/ query/static/overview.html>.

[PMID]「PubMedの概要」、<http://www.ncbi.nlm.nih.gov/entrez/ query/static/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 PO Box 1663 Los Alamos、NM 87545-1362 USA

   EMail: herbertv@lanl.gov
        

Tony Hammond Nature Publishing Group Macmillan House 4 Crinan Street London N1 9XW UK

トニーハモンドネイチャーパブリッシンググループMacmillan House 4 Crinan Street London N1 9XW UK

   EMail: t.hammond@nature.com
        

Eamonn Neylon Manifest Solutions Bicester, Oxfordshire OX26 2HX UK

Eamonn Neylon Manifest Solutions Bicester、Oxfordshire ox26 2Hx UK

   EMail: eneylon@manifestsolutions.com
        

Stuart L. Weibel OCLC Online Computer Library Center, Inc. 6565 Frantz Road Dublin, OH 43017-3395 USA

Stuart L. Weibel OCLCオンラインコンピューターライブラリセンター、6565 Frantz Road Dublin、OH 43017-3395 USA

   EMail: weibel@oclc.org
        

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2006).

Copyright(c)The Internet Society(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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織(もしあれば)が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

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.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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)によって提供されます。