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

原文URL : https://datatracker.ietf.org/doc/html/rfc5785
タイトル : RFC 5785 - 有名なユニフォームリソース識別子の定義（URI）
翻訳編集 : 自動生成

[要約] RFC 5785は、Well-Known Uniform Resource Identifiers (URIs)を定義するための規格です。その目的は、特定の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)

有名なユニフォームリソース識別子の定義（URI）

Abstract

概要

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

このメモは、選択された均一なリソース識別子（URI）スキームで、「有名な場所」、「/.Well-Nowns/」のパスプレフィックスを定義します。

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.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5785で取得できます。

著作権表示

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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.

これに対処するために、このメモは、これらの「よく知られている場所」、「/.Well-Nowns/」のHTTP URIのパスプレフィックスを定義します。このようなサイト全体のメタデータのリソースを定義する必要がある将来の仕様は、衝突を回避し、サイトの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を使用できる方法はいくつかあります。ただし、世界的なWeb [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. 有名なウリス

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はURI [RFC3986]です。パスコンポーネントは文字「/.Well-NownS/」で始まり、スキームは「HTTP」、「HTTPS」、または適切に使用するように明示的に指定された別のスキームです。 - 知られているuris。

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

セクション5.1の手順に従って、新しい有名なURIをミントしたいアプリケーションは、それらを登録する必要があります。

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-nown/例'。

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-Nowned/」にあるリソースのフォーマットまたはメディアタイプを定義しておらず、クライアントがその場所にリソースが存在することを期待すべきではないことに注意してください。

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を造るアプリケーションと、それらを展開する管理者は、機密データの露出、サービス拒否攻撃など、いくつかのセキュリティ関連の問題を考慮する必要があります（通常の負荷の問題に加えて、サービス拒否攻撃に加えて）、サーバーとクライアントの認証、DNSのリバインド攻撃に対する脆弱性、およびサーバーへのアクセスが制限されている攻撃が、よく知られているURIがどのように役立つかに影響を与える能力を付与する攻撃。

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は、1人以上の指定された専門家（IESGまたはその代表者によって任命された）のアドバイスで登録され、仕様が必要です（[RFC5226]の用語を使用）。ただし、公開前に価値の割り当てを可能にするために、指定された専門家は、そのような仕様が公開されることに満足した後、登録を承認することができます。

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のリクエスト：例」など）を使用して、レビューとコメントのために、weltnown-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サフィックス：「/.Well-Nownd/」と比較して、有名なURIに要求された名前。例：「例」。

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.

Change Controller：Standard-Track RFCSの場合、「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.

仕様文書：フィールドを指定するドキュメントへの参照、できればドキュメントのコピーを取得するために使用できる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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-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。、「Web分散オーサリングおよびバージョン（WebDAV）のHTTP拡張機能」、RFC 4918、2007年6月。

[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] Martiori、M。、「プライバシー設定のプラットフォーム1.0（P3P1.0）仕様」、World Wide Web Consortiumの推奨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.ウォルシュ、「ワールドワイドウェブの建築、第1巻」、ワールドワイドウェブコンソーシアムの推奨rec- webarch-20041215、2004年12月、<http：// wwwwwwwwwwwwwwwww.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.

このドキュメントにフィードバックとユースケースを提供したすべての人の貢献を認めたいと思います。特に、フィル・アーチャー、ダーク・バルファンツ、アダム・バース、ティム・ブレイ、ブライアン・イートン、ブラッド・フィッツパトリック、ジョー・グレゴリオ、ポール・ホフマン、バリー・レイバ、アショク・マルホトラ、ブレノ・デ・メデイロス、ジョン・パンツァー、ドラモンド・リード。ただし、エラーや省略については責任を負いません。

Appendix B. Frequently Asked Questions

付録B. よくある質問

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

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

Authors' Addresses

著者のアドレス

Mark Nottingham

マーク・ノッティンガム

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

Eran Hammer-Lahav

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