RFC4452 日本語訳

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

Commentsのために作業部会H.ヴァンde Sompel Requestをネットワークでつないでください: 4452年のLANLカテゴリ: 情報のT.ハモンドNPG E.NeylonはS.ウェイベルOCLC2006年4月にソリューションを表します。

                         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)インターネット協会(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.

このドキュメントは識別子で公共の名前空間で情報資産の「インフォメーション」Uniform Resource Identifier(URI)計画を定義します。 「インフォメーション」URI計画に参加する名前空間が「インフォメーション」Registryメカニズムによって規制されます。

Van de Sompel, et al.        Informational                      [Page 1]

RFC 4452                 The "info" URI Scheme                April 2006

ヴァンde Sompel、他 情報[1ページ]のRFC4452「インフォメーション」URI計画2006年4月

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. 序論…3 1.1. 用語…3 1.2. 情報資産…3 2. 「インフォメーション」URI計画のアプリケーション…4 3. 「インフォメーション」登録…5 3.1. 「インフォメーション」登録の管理の特性…5 3.2. 「インフォメーション」登録の機能特性…5 3.3. 「インフォメーション」登録の維持…6 4. 「インフォメーション」URI計画…6 4.1. 「インフォメーション」URI構文の定義…6 4.2. キャラクターは「インフォメーション」URI計画の下で許容しました…8 4.3. 「インフォメーション」URIに関する例…9 5. 「インフォメーション」URIの正常化と比較…10 6. 原理…12 6.1. なぜ公共の名前空間から識別子の新しいURI計画を作成しますか? ...............................................12 6.2. なぜ公共の名前空間からの識別子に既存のURI計画を使用しませんか? ...................................12 6.3. なぜ公共の名前空間から識別子のための新しいつぼのNamespace IDを作成しませんか? .......................12 7. セキュリティ問題…13 8. IANA問題…14 9. 承認…14 10. 参照…14 10.1. 標準の参照…14 10.2. 有益な参照…15

Van de Sompel, et al.        Informational                      [Page 2]

RFC 4452                 The "info" URI Scheme                April 2006

ヴァンde Sompel、他 情報[2ページ]のRFC4452「インフォメーション」URI計画2006年4月

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配分の一部でない情報資産の「インフォメーション」Uniform Resource Identifier(URI)計画を定義します。 「情報資産」で、このドキュメントは公共の名前空間の中にアイデンティティを持っているどんな情報構造物も意図します。

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.

このドキュメント、キーワード“MUST"、「必須NOT」“SHALL"で「」、“SHOULD"、「」、「5月」、RFC2119で[RFC2119]について説明して、対応する実現のために要件レベルを示すとき、「5月のNOT」、「推薦されたこと」は解釈されることになっているべきであるものとします。

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計画で参照可能でない公共の名前空間における識別子がある多くの情報資産が存在しています。 そのような名前空間に関する例はデューイ10進分類法[デューイ]、議会図書館Control民数記[LCCN]、NISO Serial Item、Contribution Identifiers[SICI]、NASA Astrophysics Data System Bibcodes[BIBCODE]、および国立医学図書館PubMed識別子[PMID]を含んでいます。 他の候補名前空間はオンライン・コンピュータ図書館センターOCLC民数記[OCLCNUM]とNISO OpenURL Framework識別子[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によってそのような公共の名前空間における識別子を持っている情報資産の参照箇所を容易にします。 [RFC3986]とSHALLが同じように楽しむRFC3986年に定義される「リソース」考えられた一般的な構文の、そして、意味的で、共有された言語がURIプレゼンテーションが与える利益であったなら「インフォメーション」URI、資産SHALLによる情報資産に参照をつけるとき。 そういうものとして、「インフォメーション」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

「インフォメーション」URI計画の下で宣言された名前空間は「インフォメーション」Registryメカニズムによって規制されます。 「インフォメーション」Registryは、URI配分の一部でない公共の名前空間が登録手続でそれ(Namespace Authority)を管理する組織によって宣言されるのを許容します。 「インフォメーション」Registryは情報資産でNamespace Authorityにおけるリソース表現の独立しているURI登録と維持の負担を課さないでURIの工事を容易にする方法でURI配分の一部でない公共の名前空間の宣言を支持します。 aの中で特定された情報資産は登録されました。

Van de Sompel, et al.        Informational                      [Page 3]

RFC 4452                 The "info" URI Scheme                April 2006

ヴァンde Sompel、他 情報[3ページ]のRFC4452「インフォメーション」URI計画2006年4月

   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.

名前空間SHALLはNamespace Authorityのビジネスプロセスに応じて、加えられるか、または削除されますが、開いていて、標準化された方法で「インフォメーション」URIでNamespace Authority側のネットワーク応用の中で追加措置なしで参照をつけられるかもしれません。

   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計画は主として身元確認の目的で存在しています。 実現は、Namespace Authoritiesが登録で登録された名前空間から識別子に関係するサービスメカニズムに記録的な参照を明らかにするかもしれませんが、URIによって特定されたリソースの表現に「インフォメーション」URIに「反-参照をつけ」ることができると仮定してはいけません。 「インフォメーション」URI計画のアプリケーションはそのような情報資産に関連するどんなサービスもインターネットを通してアクセスしやすいかどうかにかかわらずそのような情報資産に関する識別子を比較するための情報資産の識別と正常化規則の宣言に制限されます。 そのようなサービスの参照は「インフォメーション」登録記録の中で明らかにされるかもしれなくて、唯一のこれらはサービスSHALL NOTです。正式であると見なされます。 「インフォメーション」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配分の一部でない公共の名前空間は名前空間として「インフォメーション」Registryの中に登録されるかもしれません。 名前空間Authoritiesは「インフォメーション」Registryのこれらの名前空間を登録するかもしれません、その結果、URIによってこれらの名前空間を参考情報資産にそうしなければならないアプリケーションに利用可能にします。 敵対的な強奪から受入れられて、その結果身を守らないことであるNamespace Authority SHALL以外のパーティーによる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.

「インフォメーション」Registryの下における公共の名前空間の登録は情報資産の識別以外の登録された名前空間から識別子のどんな特定の機能性も含意しません。 「インフォメーション」URI計画のために解決メカニズムを全く想定できません、ネットワーク・サービスに識別子を決議するためのメカニズムはどんな特定の名前空間のためにも存在するかもしれませんが。 そのようなサービスの定義は「インフォメーション」URI計画の範囲をそらせます。 登録は識別子のために登録された名前空間の中で名前空間特有の意味論を定義しません、許容できる文字の組と正常化規則はそのような識別子を使用することで作成されたURIが確実にURIを使用するアプリケーションで対応するのになるようにするためにセクション4と5で指定されますが。

Van de Sompel, et al.        Informational                      [Page 4]

RFC 4452                 The "info" URI Scheme                April 2006

ヴァンde Sompel、他 情報[4ページ]のRFC4452「インフォメーション」URI計画2006年4月

   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.

サービスのRegistry SHALLがさらに排除しない「インフォメーション」開発における、公共の名前空間の登録は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.

「インフォメーション」Registryは情報資産の識別に使用されて、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](National情報Standards Organization)は「インフォメーション」RegistryのためのMaintenance Agencyとして機能して、「インフォメーション」Registryの日常業務をRegistry Operatorへ代表として派遣するでしょう。 Maintenance Agencyとして、NISOは、NISO支配で確立されて、「インフォメーション」ウェブサイトで利用可能にされた公的に明確に話された方針ドキュメントによると、Registry Operatorが「インフォメーション」Registryを操作するのを確実にするでしょう、<http://インフォメーション-uri.info/>。「インフォメーション」Registry方針は、候補名前空間のために吟味の過程を定義して、品質管理と適合の基準を名前空間のエントリーに提供します。

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の前兆で確立された方針によると、「インフォメーション」Registryは管理されるでしょう。 そのようなすべての方針、および「インフォメーション」Registryにおける名前空間宣言は公共になるでしょう。

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:

「インフォメーション」Registryは公的にアクセスしやすく、以下の発見(人間とマシンの両方による)を支持するでしょう。

   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ネットワーク参照で(もしあれば)のサービスメカニズムの記述に維持された識別子のためにRegistryがユニークさの保証を提供する名前空間と識別子のためのNamespace Authorities 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で定義されます)。

Van de Sompel, et al.        Informational                      [Page 5]

RFC 4452                 The "info" URI Scheme                April 2006

ヴァンde Sompel、他 情報[5ページ]のRFC4452「インフォメーション」URI計画2006年4月

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.

「インフォメーション」Registryに登録されるかもしれない公共の名前空間はNISOによって役立たれた共同体に興味があるそれらになるでしょう、そして、したがって、NISOは、「インフォメーション」RegistryのためのMaintenance Authorityとして機能して、それを操作するためにRegistry Operatorを割り当てるために送られます。

   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(American National Standards Institut(ANSI)によって信任された非営利協会)は、デジタル環境における情報を管理するために規格を特定して、開発して、維持して、発行します。 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は、情報の国際標準化機構(ISO)の技術的なCommittee46とDocumentationへの米国関心を表すために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ベセスダAveに位置している、ベセスダ、MD 20814、米国。 (詳しくはNISOウェブサイト、<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構文は一般的なURI構文がRFC3986[RFC3986]で定義されているconformantです。 この仕様は、URIを定義するのにRFC4234[RFC4234]のAugmented BN記法(ABNF)記法を使用します。 RFC4234のAppendix B.1によって定義されるように以下のコアABNF創作はこの仕様で使用されます: アルファー、ケタ、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計画に特定の創作を含んでいます、Part Bは完全性と参照のためにここで繰り返されるRFC3986[RFC3986]からの一般的な創作を含んでいますが。 以下のセットの創作(部分A)は「インフォメーション」URI計画に特定です:

Van de Sompel, et al.        Informational                      [Page 6]

RFC 4452                 The "info" URI Scheme                April 2006

ヴァンde Sompel、他 情報[6ページ]のRFC4452「インフォメーション」URI計画2006年4月

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

; 部分A: ; 「インフォメーション」URI計画に特定の創作

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

「インフォメーションURI=インフォメーション計画」:、」 インフォメーション識別子[「#」断片]

   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[RFC3986]から再生した一般的な創作です:

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

; 部分B: ; RFC3986からの一般的な創作[RFC3986]

   scheme          = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

計画=アルファー*「(アルファ/ケタ/「+」/「-」/、」、」、)

   pchar           = unreserved / pct-encoded / sub-delims / ":" / "@"

「=無遠慮であるかpctによってコード化されたかサブdelimsのpchar/」:、」 / "@"

   fragment        = *( pchar / "/" / "?" )

断片=*「(pchar/」 /」 /“?")

   unreserved      = ALPHA / DIGIT / "-" / "." / "_" / "~"

「無遠慮な=アルファー/ 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は“!"と等しいです。 / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" その計画特有の部分と5月が任意の「断片」コンポーネントを取るとき、/「=」「インフォメーション」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

「インフォメーション」URIの「名前空間」コンポーネントのための値はURI計画キャラクタ(Cf「計画」生産)だけで構成された名前象徴です。 それらは、「識別子」コンポーネントのための(非エスケープしました)値が由来する公共の名前空間を特定して、「インフォメーション」Registryに登録されます。(Registryはそれらのユニークさを保証します)。

Van de Sompel, et al.        Informational                      [Page 7]

RFC 4452                 The "info" URI Scheme                April 2006

ヴァンde Sompel、他 情報[7ページ]のRFC4452「インフォメーション」URI計画2006年4月

   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.

そして、固執。 「名前空間」コンポーネントは大文字と小文字を区別しないのですが、標準形は小文字です、そして、「名前空間」コンポーネントSHOULDに値を指定するドキュメントがそう使用に小文字をします。 SHOULDが丈夫さのために「名前空間」名で小文字で印刷するために大文字が同等であると受け入れる実現、SHOULDだけが小文字の「名前空間」名を発生させるだけです、一貫性のために。

   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がそうするインフォメーションが経路セグメントキャラクタ(Cf"pchar"生産)から築き上げられた経路セグメントで構成された階層的なストリングであるとして見なされて、切り離されるセグメントはなでぎりする」という/の「識別子」コンポーネントのために、評価する」、」 /、」 階層構造デリミタとしてのキャラクタを思ってはいけません。 それらの由来している公共の名前空間では、「識別子」コンポーネントのための(非エスケープしました)値は情報資産を特定します。 「識別子」コンポーネントがあるに違いないので、値は必要に応じてこれで構文から何%も逃げました。 「識別子」コンポーネントSHOULDが大文字と小文字を区別するとして扱われて、「インフォメーション」ですが、Registryは特定の登録された公共の名前空間から識別子のケース感度を記録するかもしれません。 また、「インフォメーション」Registryは句読文字と同様のものの処理に関する追加正常化規則を明らかにするかもしれません。

   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の「断片」コンポーネントのための値は経路セグメントキャラクタ(Cf"pchar"生産)で構成されたストリングであり、スラッシュは/です」というキャラクタと疑問符“?"キャラクタ。 」 /をなでぎりしてください。「意味役割が全く割り当てられない、」 キャラクタと「断片」コンポーネントの中の疑問符“?"キャラクタ。 「断片」コンポーネントのための(非エスケープしました)値は一次情報資産に関して二次情報資産を特定します。(それは、「インフォメーション識別子」によって参照をつけられます)。 「断片」コンポーネントがあるに違いないので、値は必要に応じてこれで構文から何%も逃げました。 「断片」コンポーネントを大文字と小文字を区別しているとして扱わなければなりません。

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に同じセットの指定されることへのRFC3986[RFC3986]の許容米国-ASCII文字を使用します。 「インフォメーション」URIはSHOULDを結びます。ユニコード[ユニコード]ストリングとして表されてください、そして、UTF-8[RFC3629]フォームでコード化されてください。 URIを形成する前に、除かれた米国-ASCII文字と非米国のASCII文字と同様に控え目なキャラクタは%で逃げなければなりません。 RFC3986[RFC3986]、セクション2.4で%エスケープコード化の詳細を見つけることができます。

Van de Sompel, et al.        Informational                      [Page 8]

RFC 4452                 The "info" URI Scheme                April 2006

ヴァンde Sompel、他 情報[8ページ]のRFC4452「インフォメーション」URI計画2006年4月

4.3.  Examples of "info" URIs

4.3. 「インフォメーション」URIに関する例

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

シンタクス上有効な「インフォメーション」URIに関するいくつかの例が以下に出されます:

       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"がデューイ10進分類法[デューイ]名前空間のための「名前空間」コンポーネントであり、「22/eng//4.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エド)のための名前空間における22/eng//4.678インチ」を特定しました。 英語デューイ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"が議会図書館Control Number[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."

「新来者、エリック。」 理解ウェブサービス: XML、WSDL、石鹸、およびUDDI。 ボストン: 「アディソン-ウエスリー、2002。」

       c) info:sici/0363-0277(19950315)120:5%3C%3E1.0.TX;2-V

c)インフォメーション: sici/0363-0277(19950315)120: 5%3C%に3Eの1.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"がSerial ItemとContribution Identifier[SICI]名前空間のための「名前空間」コンポーネントである、「0363-0277(19950315) 120:5 3Eの%3Cの%1.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."

「図書館Journal、Vol.120、No.5。」 「1995年3月15日。」

Van de Sompel, et al.        Informational                      [Page 9]

RFC 4452                 The "info" URI Scheme                April 2006

ヴァンde Sompel、他 情報[9ページ]のRFC4452「インフォメーション」URI計画2006年4月

       d) <rdf:Description about="info:bibcode/2003Icar..163..263Z"/>

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.

"bibcode"はNASA Astrophysics Data System(ADS)Bibcode[BIBCODE]名前空間のためのどこの「名前空間」コンポーネントですか、そして、"2003Icar"。163.."263Z"はその名前空間の中の情報資産に関する識別子のための「識別子」コンポーネントです。 この例はResource記述Framework(リモート・データ・ファシリティ)声明の対象としてさらに「インフォメーション」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

"2003Icar"という識別子によって特定された情報資産。163..NASA ADS Bibcodesのための名前空間における"263Z"は雑誌の記事について説明するADSシステムでのメタデータ記録です。

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

「K。」 外側の太陽系、イカロス、163(2003)ページのZahnleとP.シェンクとH.LevisonとL.Dones、Crateringレート 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]名前空間のための「名前空間」コンポーネントであり、「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."

「Wijesuriyaサウスダコタ、ブリストウJ、ミラーWL。」 人間のテネイシンXのための主要なプロモーターのローカライズと分析。 ゲノム解析。 「2002 10月; 80(4): 443-52」

5.  Normalization and Comparison of "info" URIs

5. 「インフォメーション」URIの正常化と比較

   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の比較を容易にするために、以下で詳しく述べられるように適用されていて、正常化の系列はSHOULDを踏みます。 そして、URIストリングを正常にした後に、2つの「インフォメーション」URIの比較はRFC3986[RFC3986]、セクション6.2.1処方されるようにキャラクタごとのベースで適用されます。

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

とにかく適用されていて、以下の一般的な正常化はアプリケーション処理「インフォメーション」URIでSHOULDを踏みます:

        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)になるように「名前空間」コンポーネントに関するケースを正常にしてください。 Unescapeの無遠慮な「名前空間」における%で逃げられたキャラクタと「識別子」コンポーネント

Van de Sompel, et al.        Informational                     [Page 10]

RFC 4452                 The "info" URI Scheme                April 2006

ヴァンde Sompel、他 情報[10ページ]のRFC4452「インフォメーション」URI計画2006年4月

        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.

さらなる正常化ステップは登録された公共の名前空間のための「インフォメーション」Registryに記録された規則に基づく「インフォメーション」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 SHOULD以来、適用するために可能な情報のために「インフォメーション」Registryに相談することによって、登録された公共の名前空間からの識別子のためのケース感度、およびあらゆるケース正常化ステップに大文字と小文字を区別しています、標準形に達するだけであるかもしれないということであるとして扱われてください。 また、「インフォメーション」Registryは句読文字と同様のものの処理に関する追加正常化規則を明らかにするかもしれません。

   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.

しかしながら、それにもかかわらず、場合では、Namespace Authorityが好まれた形を指名するのが、「識別子」コンポーネントのどんなただ一つの標準形も存在していないところのRECOMMENDEDである、どのSHOULDがどこでも、「インフォメーション」URIの中で可能であるところで使用されるかので、アプリケーション5月には、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

U1。 INFO: 2802%2996852%の2D7 U4インフォメーション: PII/S0888-7543(02)96852-7 U2インフォメーション: PII/S0888754302968527 U3インフォメーション: pii/S0888%2D7543%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

N1インフォメーション: pii/S0888-7543(02)96852-7 N2インフォメーション: pii/S0888754302968527 N3インフォメーション: pii/S0888-7543(02)96852-7 N4インフォメーション: 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定義はさらなる正常化ステップを定めません、登録された公共の名前空間のための「インフォメーション」Registryに記録されたどんな規則に従っても、アプリケーションは追加正常化ステップを当てはまるかもしれませんが。

Van de Sompel, et al.        Informational                     [Page 11]

RFC 4452                 The "info" URI Scheme                April 2006

ヴァンde Sompel、他 情報[11ページ]のRFC4452「インフォメーション」URI計画2006年4月

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.

RFC4395と、「新しいURI計画のためのガイドラインと登録手順」[RFC4395]の下では、それは「新しいURI計画SHOULDは既に登録されたURI計画でそれを超えた利用可能な広いインターネットコミュニティにユーティリティをクリアさせる」「明白で、新しくて、長命のユーティリティ」というセクション2.1に述べられています。 「インフォメーション」URI計画は、情報資産の識別に使用される公共の名前空間の中の識別子がURI配分の中に示されるのを許容します。 名前空間が「インフォメーション」Registryにいったん登録されると、「インフォメーション」URI計画は、その名前空間における識別子がある情報資産がURIによって参照をつけられるのを可能にします。 結果、考えられて、RFCで定義されて、3986の[RFC3986]とSHALLが同じ一般的な構文の、そして、意味的で、共有された言語を楽しむときリソースがそれのためになるという情報資産SHALLとして、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計画はNamespace Authoritiesがサービスメカニズムを明らかにするのを選ぶかもしれないリソース識別子のクラスに適用されます。それにもかかわらず、よりすばらしいユーティリティをネットワーク応用に提供するためにNamespace Authoritiesが「インフォメーション」でどんなそのようなサービスメカニズムの登録記録参照も明らかにするよう奨励されます。

6.3.  Why Not Create a New URN Namespace ID for Identifiers from Public
      Namespaces?

6.3. なぜ公共の名前空間から識別子のための新しいつぼのNamespace 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

「一定のResource Names(URNs)がしつこくて、位置から独立しているリソース識別子に役立つことを意図します。」と、RFC2141[RFC2141]は述べます。 「インフォメーション」URI計画は他方では、この計画の下で作成された識別子について固執について断言するのではなく、むしろこの計画の下で除外された公共の名前空間について断言します。 それは、主として情報資産のアイデンティティを明らかにして、方針によると、管理された識別子の公共の名前空間とNamespace Authoritiesのビジネスモデルのために軽量の登録メカニズムを容易にするために存在しています。 「インフォメーション」URI計画は識別子固執に関して中立です。 おまけに

Van de Sompel, et al.        Informational                     [Page 12]

RFC 4452                 The "info" URI Scheme                April 2006

ヴァンde Sompel、他 情報[12ページ]のRFC4452「インフォメーション」URI計画2006年4月

   "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 Network Identifier(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.

さらに、「それはそこでそれぞれの命名権威とURLで発生する名前の間には、マッピングがあることが強く勧められる」なら、「インフォメーション」URI計画は特定の推薦と対照してグローバルに反参照可能ではありません。 「インフォメーション」Registryに登録された個々のNamespace Authoritiesはしかしながら、サービスメカニズムに参照を明らかにするかもしれなくて、そうするよう奨励されます。

   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.

「余分な考慮はその「」 URI構文がスラッシュを予約しながら明らかに一般的なURI階層構造を遮断するつぼ」/です」というキャラクタ。 「他方では、「インフォメーション」URIは、実際の階層構造をサポートすることに関して中立のままで残っている間、階層的処理を認めて、その結果、」 /をスラッシュに許容する」というキャラクタ(より気前よく“&"とティルド「~」キャラクタをアンパーサンドに許容することと同様に)。 したがって、それはNamespace Authoritiesのために公共の名前空間が橋を架けるメカニズムとして機能することによってURI配分の一部になるという意志で保つ際に低級バリアをエントリーに表します。 要するに、「インフォメーション」URIはRFC3986[RFC3986]で議論するように「人間のtranscribability」を「つぼ」URIより広く支持しています。

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

さらに、「つぼ」URI構文は二次リソースの間接的な識別のための「インフォメーション」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計画構文はRFC3986[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.

いくつかの「インフォメーション」Namespace Authoritiesが、サービスメカニズムを明らかにするのを選んでいるかもしれない間、そのようなサービスの実行から生じるどんなセキュリティ問題もこのドキュメントの範囲をそらせます。 「インフォメーション」名前空間に関する登録記録がどんなそのような問題も含むことが強く勧められます。

Van de Sompel, et al.        Informational                     [Page 13]

RFC 4452                 The "info" URI Scheme                April 2006

ヴァンde Sompel、他 情報[13ページ]のRFC4452「インフォメーション」URI計画2006年4月

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/課題/uri-schemes.html>SHOULDを計画します。アップデートして、「インフォメーション」URI計画が公表のためにRFCとして認められる「インフォメーション」URI計画のためのエントリーを含んでください。 このエントリーSHOULDは以下の値を含んでいます:

   Scheme Name: info

名前を計画してください: インフォメーション

   Description: Information Assets with Identifiers in Public
                Namespaces

記述: 公共の名前空間における識別子がある情報資産

   Reference: RFC 4452

参照: RFC4452

9.  Acknowledgements

9. 承認

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

作者はマイケルMealling、Verisign、およびパトリックHochstenbach、ゲント大学の貢献を承諾します。

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、「一定のリソース名のための機能条件書」、RFC1737、1994年12月。

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

[RFC2141]モウツ(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変化形式」STD63、RFC3629、11月2003日

   [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、「Uniform Resource Identifier(URI):」 「一般的な構文」、STD66、RFC3986、2005年1月。

   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

[RFC4234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。

   [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のためのガイドラインと登録手順は計画します」、BCP115、RFC4395、2006年2月。

Van de Sompel, et al.        Informational                     [Page 14]

RFC 4452                 The "info" URI Scheme                April 2006

ヴァンde Sompel、他 情報[14ページ]のRFC4452「インフォメーション」URI計画2006年4月

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

[ユニコード] ユニコードConsortium、「Standard(バージョン4.0.0)が以下で定義したユニコード」 バージョン4インチユニコード規格。 (読書、MA、アディソン-ウエスリー、2003。) ISBN0-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の天体物理学のデータ・システムの図書目録のコード」、<http://adsdoc.harvard.edu/腹筋_doc/は_ページ/data.html>を助けます。

   [DEWEY]    "Dewey Decimal Classification",
              <http://www.oclc.org/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/しぼりかすの/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/アン/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-610インチ、<が://www.niso.org/規格/リソース/Z39_88_2004.pdf>をhttpする、」

   [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-289インチ、<http://www.niso.org/規格/リソース/Z39-56.pdf>、」

Van de Sompel, et al.        Informational                     [Page 15]

RFC 4452                 The "info" URI Scheme                April 2006

ヴァンde Sompel、他 情報[15ページ]のRFC4452「インフォメーション」URI計画2006年4月

Authors' Addresses

作者のアドレス

   Herbert Van de Sompel
   Los Alamos National Laboratory
   Research Library, MS-P362
   PO Box 1663
   Los Alamos, NM  87545-1362
   USA

ハーバートヴァンde Sompelロスアラモス国立研究所Research図書館、私書箱1663ロスアラモス、MS-P362ニューメキシコ87545-1362米国

   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はソリューションBicester、オックスフォードシャー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オンライン・コンピュータ図書館センターInc.6565フランツおお、Road43017-3395ダブリン(米国)

   EMail: weibel@oclc.org

メール: weibel@oclc.org

Van de Sompel, et al.        Informational                     [Page 16]

RFC 4452                 The "info" URI Scheme                April 2006

ヴァンde Sompel、他 情報[16ページ]のRFC4452「インフォメーション」URI計画2006年4月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Van de Sompel, et al.        Informational                     [Page 17]

ヴァンde Sompel、他 情報[17ページ]