Internet Engineering Task Force (IETF) M. Nottingham Request for Comments: 8615 2019年5月 Obsoletes: 5785 Updates: 7230, 7595 Category: Standards Track ISSN: 2070-1721 Well-Known Uniform Resource Identifiers (URIs) 概要 このメモは、選択された Uniform Resource Identifier (URI) スキーム における「well-known location」のためのパス接頭辞 "/.well-known/" を定義する。 そうすることで、この文書は RFC 5785 を廃止し、RFC 7230 で定義 された URI スキームを更新して、その空間を予約する。さらに、 well-known URI をサポートする URI スキームをその登録簿で追跡 するため、RFC 7595 も更新する。 このメモの位置付け これは Internet Standards Track 文書である。 この文書は Internet Engineering Task Force (IETF) の成果物で ある。これは IETF コミュニティの合意を表すものである。公開 レビューを受け、Internet Engineering Steering Group (IESG) に よって公開が承認されている。Internet Standards に関する詳細は RFC 7841 の Section 2 にある。 この文書の現在の状態、正誤表、およびフィードバックの提供方法 に関する情報は、 https://www.rfc-editor.org/info/rfc8615 で入手できる。 著作権表示 Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. この文書は、公開日時点で有効な BCP 78 および IETF Trust の IETF 文書に関する法的規定 (https://trustee.ietf.org/license-info) の対象となる。これらの 文書には、この文書に関する権利および制限が記載されているため、 注意深く確認すること。この文書から抽出されたコードコンポーネント には、Trust Legal Provisions の Section 4.e に記載される Simplified BSD License テキストを含めなければならず、Simplified BSD License に記載されるとおり、保証なしで提供される。 Nottingham Standards Track [Page 1]
RFC 8615 Well-Known URI 2019年5月 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 表記上の規約 . . . . . . . . . . . . . . . . . . . . . . 3 3. Well-Known URI . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Well-Known URI の登録 . . . . . . . . . . . . . . . . . 4 4. セキュリティに関する考慮事項 . . . . . . . . . . . . . . 5 4.1. Well-Known リソースの保護 . . . . . . . . . . . . . . . 6 4.2. Web ブラウジングとの相互作用 . . . . . . . . . . . . 6 4.3. アプリケーションのスコープ設定 . . . . . . . . . . . 7 4.4. 隠れた能力 . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA に関する考慮事項 . . . . . . . . . . . . . . . . . . 8 5.1. Well-Known URI 登録簿 . . . . . . . . . . . . . . . . . 8 5.2. Uniform Resource Identifier (URI) Schemes 登録簿 . . 9 6. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. 規範的参考文献 . . . . . . . . . . . . . . . . . . . 9 6.2. 参考情報としての参考文献 . . . . . . . . . . . . . . 10 Appendix A. よくある質問 . . . . . . . . . . . . . . . . . . 12 Appendix B. RFC 5785 からの変更 . . . . . . . . . . . . . 12 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . 12 1. はじめに Web 上の一部のアプリケーションは、リクエストを行う前に、 オリジン [RFC6454] に関する情報（「サイト全体のメタデータ」と 呼ばれることもある）を発見する必要がある。たとえば、Robots Exclusion Protocol (http://www.robotstxt.org) は、自動化された プロセスがリソースへアクセスする許可を得る方法を規定している。 同様に、Platform for Privacy Preferences [P3P] は、ユーザー エージェントがオリジンサーバーとやり取りする前にプライバシー ポリシーを発見する方法を示している。 リソースごとのメタデータにアクセスする方法はいくつかある （たとえば、HTTP ヘッダーフィールド、Web Distributed Authoring and Versioning (WebDAV) [RFC4918] における PROPFIND）が、 クライアントから見た遅延や配備上の困難さに関する、認識される オーバーヘッドのため、こうしたシナリオではそれらの使用が しばしば妨げられる。 同時に、HTTP を非 Web プロトコルの基盤として使用することが より一般的になっている。場合によっては、そのようなプロトコルが、 与えられたホスト上の 1 つ以上のリソースを見つける方法を必要と する。 このような場合の 1 つの解決策は、オリジン全体に関連するデータ またはサービスのための「well-known location」を指定し、それを 容易に見つけられるようにすることである。しかし、この方法には、 他のそのように指定された「well-known location」や、オリジンが 作成した（または作成したい）リソースとの衝突の危険がある。 さらに、well-known location を定義することは、オリジン自身の URI 空間に対する制御を奪うことになる [RFC7320]。 Nottingham Standards Track [Page 2]
RFC 8615 Well-Known URI 2019年5月 これらの用途に対応するため、このメモは HTTP、HTTPS、WebSocket (WS)、および Secure WebSocket (WSS) URI において、これらの 「well-known location」のためのパス接頭辞 "/.well-known/" を 予約する。このようなメタデータのためのリソースを定義する必要が ある将来の仕様は、衝突を避け、オリジンの URI 空間への影響を 最小限に抑えるため、その使用を登録できる。 Well-known URI は他の URI スキームでも使用できるが、そのスキーム の定義が明示的にそれを許可している場合に限られる。 2. 表記上の規約 この文書におけるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、ここに示す ようにすべて大文字で現れる場合に限り、 BCP 14 [RFC2119] [RFC8174] に記載される意味で解釈される。 3. Well-Known URI well-known URI とは、パスコンポーネントが "/.well-known/" という 文字で始まる URI [RFC3986] であり、ただしそのスキームが well-known URI をサポートするよう明示的に定義されているものを いう。 たとえば、あるアプリケーションが 'example' という名前を登録した 場合、'http://www.example.com/' 上の対応する well-known URI は 'http://www.example.com/.well-known/example' になる。 この仕様は、well-known URI をサポートするよう "http" [RFC7230] および "https" [RFC7230] スキームを更新する。他の既存のスキームは、 その定義を更新するための適切なプロセスを使用できる。たとえば、 [RFC8307] は "ws" および "wss" スキームについてそれを行っている。 "Uniform Resource Identifier (URI) Schemes" 登録簿は、どの スキームが well-known URI をサポートしているかを追跡する。 Section 5.2 を参照。 新しい well-known URI を作成したいアプリケーションは、 Section 5.1 の手順に従い、以下の要件に従って、それらを 登録しなければならない（MUST）。 登録名は [RFC3986] の "segment-nz" 生成規則に適合しなければ ならない（MUST）。これは、"/" 文字を含められないことを意味する。 特定のアプリケーションの登録名は、それに応じて精密であるべきで ある（SHOULD）。一般的な用語を「占有」することは推奨されない。 たとえば、Example アプリケーションがメタデータの well-known location を望む場合、適切な登録名は "metadata" ではなく "example-metadata"、あるいは "example.com-metadata" であろう。 Nottingham Standards Track [Page 3]
RFC 8615 Well-Known URI 2019年5月 登録は、少なくとも、well-known URI を参照解除することで取得される 形式および関連するメディアタイプを定義する仕様と、その well-known URI を使用できる URI スキームを参照する。URI スキーム が明示的に指定されていない場合、"http" および "https" が仮定 される。 通常、アプリケーションは与えられたスキームのデフォルトポートを 使用する。代替ポートを使用する場合、それは対象のアプリケーション によって明示的に指定されなければならない（MUST）。 登録には、well-known URI に追加される追加のパスコンポーネント、 クエリ文字列、および／またはフラグメント識別子の構文や、 プロトコル固有の詳細（例: HTTP [RFC7231] メソッド処理）などの 追加情報を含めてもよい（MAY）。 この仕様は、特定のアプリケーションのために well-known URI を 見つける際に使用するホスト名の決定方法も、well-known URI を 参照解除することで発見されるメタデータのスコープも定義しない ことに注意すること。どちらもアプリケーション自身によって定義 されるべきである。 また、この仕様は "/.well-known/" に位置するリソースの形式や メディアタイプを定義しておらず、クライアントはその場所に リソースが存在することを期待すべきではない。 Well-known URI は、パス階層の最上位に根を持つ。それらは、パスの 他の部分において定義上 well-known ではない。たとえば、 "/.well-known/example" は well-known URI であるが、 "/foo/.well-known/example" はそうではない。 well-known location に関するセキュリティ上の考慮事項については、 Section 4 も参照すること。 3.1. Well-Known URI の登録 "Well-Known URIs" 登録簿は <https://www.iana.org/assignments/well-known-uris/> にある。登録 申請は、そこにある指示に従うか、 <wellknown-uri-review@ietf.org> メーリングリストにメールを送る ことで行える。 登録申請は、少なくとも次の情報で構成される。 URI suffix: "/.well-known/" からの相対名として要求される well-known URI の名前。例: "example"。 Nottingham Standards Track [Page 4]
RFC 8615 Well-Known URI 2019年5月 Change controller: Standards Track RFC の場合は "IETF" と記す。 それ以外の場合は、責任を負う当事者の名前を示す。その他の詳細 （例: メールアドレス、ホームページ URI）を含めてもよい。 Specification document(s): そのフィールドを規定する文書への参照。 できれば、その文書のコピーを取得するために使用できる URI を 含める。関連する節の表示を含めてもよいが、必須ではない。 Status: "permanent" または "provisional" のいずれか。以下の 指針を参照。 Related information: 関連する追加情報を含む文書への引用を任意で 記載する。 登録値に関する一般要件は Section 3 に記載されている。 Standards Track RFC およびその他のオープン標準（[RFC2026], Section 7.1.1 の意味におけるもの）によって定義される値は、 "permanent" の状態を持つ。他の値も、専門家がコミュニティと協議 したうえで、それらが使用中であると判断した場合、permanent と して登録できる。それ以外の値は "provisional" として登録される べきである。 暫定エントリは、専門家がコミュニティと協議したうえで、それが 使用されていないと判断した場合、削除できる。専門家は暫定 エントリの状態を permanent に変更できる。その際、専門家はその 値がどの程度広く使用されているかを考慮し、事前にコミュニティと 協議すべきである。 上記の「コミュニティと協議」とは、対象の URI スキームについて 責任を負う人々を指すことに注意すること。一般に、これは適切な Working Group（終了している場合もある）のメーリングリスト上で 行われるか、そのようなリストが存在しない場合は <art@ietf.org> 上で行われる。 専門家が、未登録の well-known URI が広く配備されており、そうで なければ適時に登録される見込みがないと判断した場合、well-known URI は第三者（専門家自身を含む）によって登録できる。そのような 登録も、仕様への参照が必要であることを含め、定義された要件の 対象である。 4. セキュリティに関する考慮事項 新しい well-known URI を作成するアプリケーション、およびそれらを 配備する管理者は、機密データの露出、サービス拒否攻撃（通常の 負荷問題に加えて）、サーバー Nottingham Standards Track [Page 5]
RFC 8615 Well-Known URI 2019年5月 およびクライアント認証、DNS リバインディング攻撃への脆弱性、 ならびにサーバーへの限定的なアクセスが well-known URI の提供方法 に影響を与える能力を与える攻撃など、いくつかのセキュリティ関連 の問題を考慮する必要がある（これらに限定されない）。 [RFC3552] には、アプリケーションプロトコルおよびそれらを 配備する管理者に関連する可能性がある、セキュリティ上の考慮事項 の例が含まれている。 4.1. Well-Known リソースの保護 well-known location は実質的にオリジン全体を表すため、サーバー 運用者はそこへの書き込み能力を適切に制御すべきである。これは、 同じオリジン上に複数の主体が同居している場合に特に当てはまる。 単一の主体によって制御され、それを表すオリジンであっても、 well-known location への書き込みアクセスが、サーバー設定を通じて 外部から、または実装権限（例: ファイルシステム上）を通じて ローカルから、不用意に付与されないことを保証するため、十分な 注意を払うべきである。 4.2. Web ブラウジングとの相互作用 "http" または "https" URL のために well-known URI を使用する アプリケーションは、well-known リソースが Web ブラウザーから アクセス可能であり、したがって、そのオリジンの他の部分から取得 されたコンテンツによって操作され得ることを認識する必要がある。 攻撃者がコンテンツを注入できる場合（例: Cross-Site Scripting 脆弱性を通じて）、その攻撃者は well-known リソースに対して潜在的 に任意のリクエストを行える。 HTTP および HTTPS は、Cookie [RFC6265]、Web Storage [WEBSTORAGE]、 ならびにさまざまな能力を含む（ただしこれらに限定されない） 多くの他の仕組みにおいても、オリジンをセキュリティ境界として 使用する。 well-known location を定義するアプリケーションは、これらの仕組み への唯一のアクセス権を持っている、またはオリジンを使用している 唯一のアプリケーションである、と仮定すべきではない。アプリケー ションの性質に応じて、緩和策には次のものが含まれ得る。 o 機密情報を暗号化する o 他のアプリケーションとの衝突を避けるため、識別子（例: cookie 名）の使用に柔軟性を持たせる o Cookie がブラウザーのスクリプト言語にさらされないことを保証 するため、Cookie に 'HttpOnly' フラグを使用する [RFC6265] o Cookie がオリジンの他の部分から利用できないことを保証する ため、Cookie に 'Path' パラメータを使用する [RFC6265] Nottingham Standards Track [Page 6]
RFC 8615 Well-Known URI 2019年5月 o 攻撃者の制御下にあるコンテンツが、Web ブラウザーによって アクティブコンテンツとして解釈される形式へ誘導されないことを 保証するため、X-Content-Type-Options: nosniff [FETCH] を使用 する その他の良い実践には次のものが含まれる。 o Content-Type ヘッダーフィールドでアプリケーション固有の メディアタイプを使用し、それが使用されていない場合は クライアントに失敗を要求する o Content-Security-Policy [CSP] を使用して、アクティブ コンテンツ（HTML [HTML5] など）の能力を制約し、それにより Cross-Site Scripting 攻撃を緩和する o Referrer-Policy [REFERRER-POLICY] を使用して、URL 内の機密 データが Referer リクエストヘッダーフィールドで漏えいすること を防ぐ o 機密情報（例: 認証トークン、パスワード）に対する圧縮の使用を 避ける。Web ブラウザーが提供するスクリプト環境により、攻撃者 は圧縮空間を繰り返し探査できるためである。攻撃者が通信経路へ アクセスできる場合、その能力を用いてその情報を回復できる。 4.3. アプリケーションのスコープ設定 このメモは、well-known URI から取得された情報の適用範囲を指定 せず、特定のアプリケーションの well-known URI を発見する方法も 指定しない。 この仕組みを使用する個々のアプリケーションは、両方の側面を定義 しなければならない。これが指定されていない場合、実装の逸脱や アプリケーション間の境界に関する混乱から、セキュリティ上の問題 が生じ得る。 well-known URI で発見されたメタデータを、同じオリジン上に 同居するもの以外のリソースへ適用すると、管理上およびセキュリティ 上の問題が生じるおそれがある。たとえば、 "https://example.com/.well-known/example" が "https://department.example.com"、"https://www.example.com"、または "https://www.example.com:8000" に対するポリシーに適用されることを 許すと、ホスト間に関係がない可能性があるにもかかわらず、その 関係を仮定し、潜在的な攻撃者に制御を与えることになる。 同様に、特定のホスト名上の well-known URI がプロトコルの ブートストラップに使用されることを指定すると、多数の望ましく ないリクエストを引き起こす可能性がある。たとえば、メールのような 別個のサービスに関するポリシーを見つけるために well-known HTTPS URI が使用される場合、その well-known URI を実装していない場合で も、Web サーバーへのリクエストの洪水を招く可能性がある。 Nottingham Standards Track [Page 7]
RFC 8615 Well-Known URI 2019年5月 そのような望ましくないリクエストは、サービス拒否攻撃に似たもの に見えることがある。 4.4. 隠れた能力 well-known location を使用するアプリケーションは、一部のサーバー 管理者がその存在に気づいていない可能性があることを考慮すべきで ある（特に、名前が "." で始まるディレクトリを隠すオペレーティング システム上で）。これは、攻撃者が .well-known ディレクトリへの 書き込みアクセスを持っている場合、管理者がそれに気づかないまま、 その内容を制御できる可能性があることを意味する。 5. IANA に関する考慮事項 5.1. Well-Known URI 登録簿 この仕様は、[RFC5785] で最初に定義された "Well-Known URI" 登録簿の登録手順を更新する。Section 3.1 を参照。 Well-known URI は、1 人以上の専門家の助言に基づき、Specification Required（[RFC8126] の用語を使用）として登録される。 登録申請を評価する際の専門家の主な考慮事項は次のとおりである。 o Section 3 の要件への適合 o 仕様文書の入手可能性および安定性 o Section 4 で示した考慮事項 IANA は、登録簿へのあらゆる申請の送信者に対し、この文書、および 定義されている場合は専門家が確立したプロセスを案内する。通常、 これは登録簿 Web ページを参照させることを意味する。 この文書により、IANA は次を行った。 o 登録手順を Specification Required に更新した。 o 登録簿に "Status" 列を追加し、既存のすべての登録を "permanent" としてマークした。 Nottingham Standards Track [Page 8]
RFC 8615 Well-Known URI 2019年5月 5.2. Uniform Resource Identifier (URI) Schemes 登録簿 この仕様は、"Uniform Resource Identifier (URI) Schemes" 登録簿の 登録テンプレートに、"Well-Known URI Support" という名前で、 デフォルト値 "-" を持つフィールドを追加する。 ある URI スキームが Section 3 に従って well-known URI を使用する よう明示的に指定されている場合、その値はその仕様への参照に 変更される。"-" ではない初期値を Table 1 に示す。 +------------+------------------------+ | URI Scheme | Well-Known URI Support | +------------+------------------------+ | coap | [RFC7252] | | coap+tcp | [RFC8323] | | coap+ws | [RFC8323] | | coaps | [RFC7252] | | coaps+tcp | [RFC8323] | | coaps+ws | [RFC8323] | | http | [RFC8615] | | https | [RFC8615] | | ws | [RFC8307] | | wss | [RFC8307] | +------------+------------------------+ Table 1: 新しい列が空でない URI Scheme Registry の行 6. 参考文献 6.1. 規範的参考文献 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1997年3月, <https://www.rfc-editor.org/info/rfc2119>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, 2005年1月, <https://www.rfc-editor.org/info/rfc3986>. [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, 2011年12月, <https://www.rfc-editor.org/info/rfc6454>. Nottingham Standards Track [Page 9]
RFC 8615 Well-Known URI 2019年5月 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, 2014年6月, <https://www.rfc-editor.org/info/rfc7230>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, 2017年6月, <https://www.rfc-editor.org/info/rfc8126>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2017年5月, <https://www.rfc-editor.org/info/rfc8174>. 6.2. 参考情報としての参考文献 [CSP] West, M., "Content Security Policy Level 3", World Wide Web Consortium WD WD-CSP3-20160913, 2016年9月, <https://www.w3.org/TR/2016/WD-CSP3-20160913>. [FETCH] WHATWG, "Fetch - Living Standard", <https://fetch.spec.whatwg.org>. [HTML5] WHATWG, "HTML - Living Standard", <https://html.spec.whatwg.org>. [P3P] Marchiori, M., "The Platform for Privacy Preferences 1.0 (P3P1.0) Specification", World Wide Web Consortium Recommendation REC-P3P-20020416, 2002年4月, <http://www.w3.org/TR/2002/REC-P3P-20020416>. [REFERRER-POLICY] Eisinger, J. and E. Stark, "Referrer Policy", World Wide Web Consortium CR CR-referrer-policy-20170126, 2017年1月, <https://www.w3.org/TR/2017/CR-referrer-policy-20170126>. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, 1996年10月, <https://www.rfc-editor.org/info/rfc2026>. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, 2003年7月, <https://www.rfc-editor.org/info/rfc3552>. Nottingham Standards Track [Page 10]
RFC 8615 Well-Known URI 2019年5月 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, DOI 10.17487/RFC4918, 2007年6月, <https://www.rfc-editor.org/info/rfc4918>. [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, 2010年4月, <https://www.rfc-editor.org/info/rfc5785>. [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, 2011年4月, <https://www.rfc-editor.org/info/rfc6265>. [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, 2014年6月, <https://www.rfc-editor.org/info/rfc7231>. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, 2014年6月, <https://www.rfc-editor.org/info/rfc7252>. [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 7320, DOI 10.17487/RFC7320, 2014年7月, <https://www.rfc-editor.org/info/rfc7320>. [RFC8307] Bormann, C., "Well-Known URIs for the WebSocket Protocol", RFC 8307, DOI 10.17487/RFC8307, 2018年1月, <https://www.rfc-editor.org/info/rfc8307>. [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, 2018年2月, <https://www.rfc-editor.org/info/rfc8323>. [WEBSTORAGE] Hickson, I., "Web Storage (Second Edition)", World Wide Web Consortium Recommendation REC-webstorage-20160419, 2016年4月, <http://www.w3.org/TR/2016/REC-webstorage-20160419>. Nottingham Standards Track [Page 11]
RFC 8615 Well-Known URI 2019年5月 Appendix A. よくある質問 well-known location は Web にとって悪いものではないのか？ 悪いものである。しかし、技術的および社会的なさまざまな理由 から、それらが必要になることがある。このメモは、衝突の危険を 減らし、サイト上の既存 URI への影響を最小限に抑えるため、 それらのための「サンドボックス」を定義する。 なぜ "/.well-known" なのか？ 短く、説明的であり、検索インデックスによれば広く使われて いないためである。 これは P3P や robots.txt のような既存の仕組みにどのような影響を 与えるのか？ それらがこの仕組みを使用することを選択するまでは、何も影響は ない。 なぜディレクトリごとの well-known location は定義されないのか？ すべての URI パスセグメントに well-known location（例: "/images/.well-known/"）を持たせると、サイト上の既存 URI との 衝突の危険が増す。また一般に、これらの解決策は過度に 「おしゃべり」であるため、うまくスケールしないことが分かって いる。 Appendix B. RFC 5785 からの変更 o 非 Web の well-known location を許可した o IANA 指示を調整した o 参考文献を更新した o その他さまざまな明確化を行った o "Uniform Resource Identifier (URI) Schemes" 登録簿でサポート するスキームを追跡した 著者の連絡先 Mark Nottingham Email: mnot@mnot.net URI: https://www.mnot.net/ Nottingham Standards Track [Page 12]