RFC 5785 - Defining Well-Known Uniform Resource Identifiers (URIs) 日本語訳

URL : https://tools.ietf.org/html/rfc5785
タイトル : RFC 5785 - 定義よく知られているユニフォームリソース識別子（URI）
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                     M. Nottingham
Request for Comments: 5785                               E. Hammer-Lahav
Updates: 2616, 2818                                           April 2010
Category: Standards Track
ISSN: 2070-1721

        Defining Well-Known Uniform Resource Identifiers (URIs)

Abstract

抽象

This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.

このメモは、選択されたユニフォームリソース識別子（URI）スキームにおいて、「よく知られている場所」、「/.well-known/」のパスプレフィックスを定義します。

Status of This Memo

このメモのステータス

This is an Internet Standards Track document.

これは、インターネット標準化過程文書です。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5785.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5785で取得することができます。

著作権表示

著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
     1.1.  Appropriate Use of Well-Known URIs  . . . . . . . . . . . . 3
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . . . 3
   3.  Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
     5.1.  The Well-Known URI Registry . . . . . . . . . . . . . . . . 4
       5.1.1.  Registration Template . . . . . . . . . . . . . . . . . 5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . . . 7
   Appendix B.  Frequently Asked Questions . . . . . . . . . . . . . . 7

1. Introduction

1. はじめに

It is increasingly common for Web-based protocols to require the discovery of policy or other information about a host ("site-wide metadata") before making a request. For example, the Robots Exclusion Protocol <http://www.robotstxt.org/> specifies a way for automated processes to obtain permission to access resources; likewise, the Platform for Privacy Preferences [W3C.REC-P3P-20020416] tells user-agents how to discover privacy policy beforehand.

Webベースのプロトコルが要求を行う前に、ポリシーまたはホスト（「サイト全体のメタデータ」）に関するその他の情報の発見を必要とすることは、ますます一般的になっています。例えば、ロボット排除プロトコル<http://www.robotstxt.org/>はリソースにアクセスする許可を得るために、自動化されたプロセスのための方法を指定します。同様に、プライバシー設定[W3C.REC-P3P-20020416]のプラットフォームは、事前にプライバシーポリシーを発見する方法をユーザーエージェントに指示します。

While there are several ways to access per-resource metadata (e.g., HTTP headers, WebDAV's PROPFIND [RFC4918]), the perceived overhead (either in terms of client-perceived latency and/or deployment difficulties) associated with them often precludes their use in these scenarios.

アクセスごとのリソースのメタデータ（例えば、HTTPヘッダ、WebDAVののPROPFIND [RFC4918]）にはいくつかの方法がありますが、それらに関連した認知オーバーヘッドは（クライアント知覚の待ち時間の条件および/または展開の困難のいずれか）が多い中で、その使用を妨げますこれらのシナリオ。

When this happens, it is common to designate a "well-known location" for such data, so that it can be easily located. However, this approach has the drawback of risking collisions, both with other such designated "well-known locations" and with pre-existing resources.

これが起こるとき、容易に配置することができるように、そのようなデータは、「よく知られている位置」を指定するのが一般的です。しかし、このアプローチは、そのような他の指定された「よく知られた場所」とし、既存のリソースとの両方、衝突の危険を冒すという欠点があります。

To address this, this memo defines a path prefix in HTTP(S) URIs for these "well-known locations", "/.well-known/". Future specifications that need to define a resource for such site-wide metadata can register their use to avoid collisions and minimise impingement upon sites' URI space.

これに対処するために、このメモは、これらの「既知の位置」のためのHTTP（S）のURIのパス接頭辞「/.well-known/」を定義します。こうしたサイト全体のメタデータのためのリソースを定義する必要があり、将来の仕様は、衝突を回避し、サイトのURIスペース時の衝突を最小限に抑えるために、その使用を登録することができます。

1.1. Appropriate Use of Well-Known URIs

1.1. よく知られているURIの適切な利用

There are a number of possible ways that applications could use Well-known URIs. However, in keeping with the Architecture of the World-Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended for general information retrieval or establishment of large URI namespaces on the Web. Rather, they are designed to facilitate discovery of information on a site when it isn't practical to use other mechanisms; for example, when discovering policy that needs to be evaluated before a resource is accessed, or when using multiple round-trips is judged detrimental to performance.

アプリケーションはよく知られているURIを使用することができます可能ないくつかの方法があります。しかし、ワールド・ワイド・ウェブ[W3C.REC-webarch-20041215]のアーキテクチャに合わせて、周知のURIは、Web上の大きなURI名前空間の一般的な情報検索又は確立のために意図されていません。むしろ、彼らは、他のメカニズムを使用するのは現実的ではないときに、サイト上の情報の発見を容易にするように設計されています。ポリシーを発見する場合、例えば、リソースがアクセスされ、または複数のラウンドトリップを使用する場合に性能に有害と判断される前に評価される必要があること。

As such, the well-known URI space was created with the expectation that it will be used to make site-wide policy information and other metadata available directly (if sufficiently concise), or provide references to other URIs that provide such metadata.

そのため、よく知られたURI空間は、直接（十分に簡潔であれば）、サイト全体のポリシー情報と他のメタデータを利用できるようにする、あるいは、そのようなメタデータを提供する他のURIへの参照を提供するために使用されることを期待して作成されました。

2. Notational Conventions

2.表記規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。

3. Well-Known URIs

3.よく知られたURI

A well-known URI is a URI [RFC3986] whose path component begins with the characters "/.well-known/", and whose scheme is "HTTP", "HTTPS", or another scheme that has explicitly been specified to use well-known URIs.

よく知られているURIは、そのパスコンポーネント文字「/.well-known/」で始まり、そのスキーム「HTTP」、「HTTPS」、または明示的に良く使用することが指定されている別のスキームであるURI [RFC3986]であります-knownのURI。

Applications that wish to mint new well-known URIs MUST register them, following the procedures in Section 5.1.

ミントに新しいよく知られたURIを希望するアプリケーションは、5.1節の手順に従って、それらを登録する必要があります。

For example, if an application registers the name 'example', the corresponding well-known URI on 'http://www.example.com/' would be 'http://www.example.com/.well-known/example'.

アプリケーションは、名前「例」を登録した場合、例えば、「http://www.example.com/」上周知のURIを対応する「http://www.example.com/.well-known/あろう例」。

Registered names MUST conform to the segment-nz production in [RFC3986].

登録名は、[RFC3986]にセグメントNZ生産に適合しなければなりません。

Note that this specification defines neither how to determine the authority to use for a particular context, nor the scope of the metadata discovered by dereferencing the well-known URI; both should be defined by the application itself.

この仕様は、特定のコンテキストで使用する権限を決定する方法をどちらも定義されていないことに注意してください、また、よく知られたURIを逆参照によって発見されたメタデータの範囲。双方は、アプリケーション自体によって定義されるべきです。

Typically, a registration will reference a specification that defines the format and associated media type to be obtained by dereferencing the well-known URI.

典型的には、登録は、周知のURIを逆参照することによって得られるフォーマット及び関連するメディアタイプを定義する仕様を参照します。

It MAY also contain additional information, such as the syntax of additional path components, query strings and/or fragment identifiers to be appended to the well-known URI, or protocol-specific details (e.g., HTTP [RFC2616] method handling).

それはまた、そのような追加のパスコンポーネント、クエリ文字列および/またはフラグメント識別子周知のURIに付加される、またはプロトコル固有の詳細（例えば、HTTP [RFC2616]方法取り扱い）の構文として、追加情報を含んでもよいです。

Note that this specification does not define a format or media-type for the resource located at "/.well-known/" and clients should not expect a resource to exist at that location.

この仕様は、「/.well-known/」にあるリソースのフォーマットやメディアタイプを定義しないと、クライアントがその位置に存在するリソースを期待すべきではないことに留意されたいです。

4. Security Considerations

4.セキュリティについての考慮事項

This memo does not specify the scope of applicability of metadata or policy obtained from a well-known URI, and does not specify how to discover a well-known URI for a particular application. Individual applications using this mechanism must define both aspects.

このメモは、よく知られたURIから取得したメタデータまたはポリシーの適用範囲を指定しないと、特定のアプリケーションのためのよく知られたURIを発見する方法を指定しません。このメカニズムを使用して個々のアプリケーションは、両方の側面を定義する必要があります。

Applications minting new well-known URIs, as well as administrators deploying them, will need to consider several security-related issues, including (but not limited to) exposure of sensitive data, denial-of-service attacks (in addition to normal load issues), server and client authentication, vulnerability to DNS rebinding attacks, and attacks where limited access to a server grants the ability to affect how well-known URIs are served.

通常の負荷の問題に加えて、新たによく知られたURIを鋳造するアプリケーションだけでなく、それらを展開し、管理者、機密データの露出を含む（これらに限定されない）いくつかのセキュリティ関連の問題を、検討する必要がある、サービス拒否攻撃（）、サーバーとクライアントの認証、サーバーへのアクセスが制限さは、よく知られたURIが提供されている方法に影響する能力を付与したDNSリバインディング攻撃、攻撃に対する脆弱性。

5. IANA Considerations

5. IANAの考慮事項

5.1. The Well-Known URI Registry

5.1. よく知られているURIのレジストリ

This document establishes the well-known URI registry.

この文書では、よく知られたURIのレジストリを確立します。

Well-known URIs are registered on the advice of one or more Designated Experts (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]). However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published.

よく知られているURIは、（[RFC5226]から用語を使用）仕様が必要で、（IESGまたはその代理人によって任命された）は、1つまたは複数の指定専門家のアドバイスに登録されています。しかし、従来の出版物への値の割り当てを可能にするために、指定された専門家（単数または複数）は、そのような仕様が公開されることを確認したら、登録を承認することができます。

Registration requests should be sent to the wellknown-uri-review@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for well-known URI: example").

登録要求は、適切な対象（例えば、「：たとえば、よく知られたURIのための要求」）と、レビューとコメントをwellknown-uri-review@ietf.orgメーリングリストに送信する必要があります。

Before a period of 14 days has passed, the Designated Expert(s) will either approve or deny the registration request, communicating this decision both to the review list and to IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@iesg.org mailing list) for resolution.

14日の期間が経過する前に、指定エキスパート（複数可）レビュー一覧にし、IANAに両方この決定を伝える、登録要求を承認または拒否しますか。否定は説明と、該当する場合、要求を成功させる方法についての提案を含める必要があります。 21日よりも長い期間未定されている登録要求は、解決のため（iesg@iesg.orgメーリングリストを使用して）IESGの注意にすることができます。

5.1.1. Registration Template

5.1.1. 登録テンプレート

URI suffix: The name requested for the well-known URI, relative to "/.well-known/"; e.g., "example".

URIサフィックス：よく知られたURIのために要求された名前、「/.well-known/」に関連し、例えば、「一例」。

Change controller: For Standards-Track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, e-mail address, home page URI) may also be included.

変更コントローラ：スタンダードトラックのRFCについては、状態「IETF」。他の人のために、責任者の名前を与えます。その他の詳細（例えば、住所、電子メールアドレス、ホームページURI）が含まれてもよいです。

Specification document(s): Reference to the document that specifies the field, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections may also be included, but is not required.

仕様書（S）：文書のコピーを取得するために使用することができ、好ましくは、URIを含む、フィールドを指定した文書への参照。関連するセクションの指示が含まれてもよいが、必須ではありません。

Related information: Optionally, citations to additional documents containing further relevant information.

関連情報：必要に応じて、さらに関連する情報を含む追加の文書への引用。

6. References

6.参照

6.1. Normative References

6.1. 引用規格

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

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。

6.2. Informative References

6.2. 参考文献

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。

[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.

[RFC4918] Dusseault、L.、RFC 4918、2007年6月 "Web分散オーサリングとバージョン管理（WebDAV）のためのHTTP拡張機能"。

[W3C.REC-P3P-20020416] Marchiori, M., "The Platform for Privacy Preferences 1.0 (P3P1.0) Specification", World Wide Web Consortium Recommendation REC-P3P-20020416, April 2002, <http://www.w3.org/TR/2002/ REC-P3P-20020416>.

[W3C.REC-P3P-20020416] Marchiori、M.、 "プライバシー設定のためのプラットフォーム1.0（P3P1.0）仕様"、World Wide Web Consortium（W3C）の勧告REC-P3P-20020416、2002年4月、<のhttp：// WWW。 w3.org/TR/2002/ REC-P3P-20020416>。

[W3C.REC-webarch-20041215] Jacobs, I. and N. Walsh, "Architecture of the World Wide Web, Volume One", World Wide Web Consortium Recommendation REC- webarch-20041215, December 2004, <http:// www.w3.org/TR/2004/REC-webarch-20041215>.

[W3C.REC-webarch-20041215]ジェイコブス、I.およびN.ウォルシュ、 "ワールド・ワイド・ウェブのアーキテクチャ、ボリュームワン"、World Wide Web Consortium（W3C）の勧告REC- webarch-20041215、2004年12月、<のhttp：// WWW .w3.org / TR / 2004 / REC-webarch-20041215>。

Appendix A. Acknowledgements

付録A.謝辞

We would like to acknowledge the contributions of everyone who provided feedback and use cases for this document; in particular, Phil Archer, Dirk Balfanz, Adam Barth, Tim Bray, Brian Eaton, Brad Fitzpatrick, Joe Gregorio, Paul Hoffman, Barry Leiba, Ashok Malhotra, Breno de Medeiros, John Panzer, and Drummond Reed. However, they are not responsible for errors and omissions.

私たちは、このドキュメントのフィードバックと使用例を提供全員の貢献を認めるしたいと思います。具体的には、フィル・アーチャー、ディルクBalfanz、アダム・バース、ティム・ブレイ、ブライアン・イートン、ブラッド・フィッツパトリック、ジョー・グレゴリオ、ポール・ホフマン、バリー・レイバ、アショク・マルホトラ、Breno・デ・メデイロス、ジョン戦車、そしてドラモンドリード。しかし、彼らはエラーと不作為の責任を負いません。

Appendix B. Frequently Asked Questions

付録B.よくある質問（FAQ）

1. Aren't well-known locations bad for the Web?

1.よく知られた場所は、Web用悪くありませんか？

They are, but for various reasons -- both technical and social -- they are commonly used and their use is increasing. This memo defines a "sandbox" for them, to reduce the risks of collision and to minimise the impact upon pre-existing URIs on sites.

彼らはありますが、様々な理由のために - 技術的、社会的、両方 - 彼らは一般的に使用され、その使用が増加しています。このメモは、衝突の危険性を低減し、サイト上の既存のURIへの衝撃を最小限に抑えるために、彼らのために、「サンドボックス」を定義します。

2. Why /.well-known?

2.なぜ/.well-known？

It's short, descriptive, and according to search indices, not widely used.

それは、短い説明だし、検索インデックスによると、広く使用されていません。

3. What impact does this have on existing mechanisms, such as P3P and robots.txt?

3.これは、P3Pとのrobots.txtなどの既存のメカニズム、上でどのような影響がありますか？

None, until they choose to use this mechanism.

なし、彼らはこのメカニズムを使用することを選択するまで。

4. Why aren't per-directory well-known locations defined?

4.なぜディレクトリごとのよく知られた場所が定義されていませんか？

Allowing every URI path segment to have a well-known location (e.g., "/images/.well-known/") would increase the risks of colliding with a pre-existing URI on a site, and generally these solutions are found not to scale well, because they're too "chatty".

よく知られた場所（例えば、「/images/.well-known/」）を持っているすべてのURIパスセグメントを許可すると、サイト上の既存のURIとの衝突のリスクを増大させるような、一般的にこれらのソリューションはないことが分かりました彼らはあまりにも「おしゃべり」しているので、うまくスケール。

Authors' Addresses

著者のアドレス

Mark Nottingham

マーク・ノッティンガム

EMail: mnot@mnot.net URI: http://www.mnot.net/

電子メール：mnot@mnot.net URI：http://www.mnot.net/

Eran Hammer-Lahav

エランハンマー - Lahav

EMail: eran@hueniverse.com URI: http://hueniverse.com/

電子メール：eran@hueniverse.com URI：http://hueniverse.com/