Network Working Group Internet-Draft Intended status: Informational Expires: July 15, 2015
S. Ruby, Ed.
IBM
L. Masinter
Adobe
January 11, 2015
この文書は、複数のURLのための組織とURLのようなものとの間におそらく競合する規格の問題空間を説明し、競合を解決するためにいくつかのアクションを提案します。ユーザーや開発者の視点から、URLの定義の増殖が存在することは意味もなく、また互換性のない実装の増殖が存在することも意味がありません。これは、競争力のある機能ではありません。したがって、この領域における様々なインターネットドラフト、勧告、および規格を更新・調整に関連する組織の必要性があります。
このインターネットドラフトは、BCP 78およびBCP 79の規定に完全に準拠して提出されます。
インターネットドラフトは、Internet Engineering Task Force（IETF）の作業中の文書です。他のグループはまた、インターネットドラフトとして作業中の文書を配布するかもしれないことに注意してください。現在のインターネットドラフトのリストはhttp://datatracker.ietf.org/drafts/current/にあります。
インターネットドラフトは最大6ヶ月間有効な草稿文書であり、更新、置換、またはいつでも他の文書によって廃止されるかもしれません。参照資料としてインターネットドラフトを使用することまたは「進行中の作業」として以外に引用することは不適切です。
このインターネットドラフトは、2015年7月15日に失効します。
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
この文書では、それらのようなURLや物事のための標準の周り問題空間をレイアウトし、競合を解決するためにいくつかのアクションを提案しています。ユーザーや開発者の視点から、URLの定義の増殖が存在することは意味もなく、また互換性のない実装の増殖が存在することも意味がありません。これは、競争力のある機能ではありません。したがって、この領域における様々なインターネットドラフト、勧告、および規格を更新・調整に関連する組織の必要性があります。
考えられる次の段階は、5章で検討されます。
議論はpublic-ietf-w3c@w3.org[1]（アーカイブ[2]）とpublic-ietf-w3c@w3.org[3]（アーカイブ[4]）で行われています。さらに、W3C TAGがミーティングとメーリングリストでこの問題を議論しました。
この文書だけでなく、テストスイート、参考実装、および[WP-URL]は、issue tracker、Wiki、および関連リソースを含め、[5]で開発されています。文書やテストに編集するためのプルリクエスト[6]を歓迎します。GitHub tracker[7]でissueを問題を作成することも有用です。編集者または電子メールでのメーリングリストへのコメントも歓迎します。
この章は、事情を示すために十分詳細に、URL標準の非常に圧縮された歴史を含みます。レビュアー：歴史は必ずしも完全なものではないですが、誤ったまたは欠落している本質的な事実を報告してください。
URLの最初の標準化過程仕様は、1994年の[RFC1738]でした。（その仕様はより多くの背景資料が含まれます。）これはASCIIのみとしてURLを定義しました。[RFC2396] 後に別々のRFCで定義される具体的なスキームの定義から一般的な構文を分離しました。このスキームの定義の多くは、必要な関心を得ないようになりました。
非ASCII文字を許可することが望ましかったことが明らかとなったとき、ASCIIのみのシステムに基づいてUnicodeに対するサポートが問題であることが判明するだろうことが広く懸念されました。したがってその取り組みは、単独の"URI"を離れ、新しいプロトコル要素、"IRI"を定義することになりました。[RFC3987]は（[RFC3986] URI定義の更新と同期して）2005年に発行されました。これはまた、必要な関心を得ないようになりました。
IETFとHTML5（詳細は4章を参照）の両方で提起された問題に対処するために、IRI working group [8]が2009年にIETFに設立されました。しかし、これは主として噛み合いの欠如のために、IRI working groupで開発されていた文書は、個々の提案として、あるいはIETF applications area working group内で更新することができた計画とともに、IRIグループは2014年に閉鎖されました。具体的には、IRI working groupの項目の1つは[RFC4395]を更新することでした。これは現在IETFのapplication area（[appsawg-uri-scheme-reg]参照）で開発中です。
独立して、WHATWGとW3CにおけるHTML仕様は、一部のブラウザーがしていたものと一致させる試みで、"URL"を再定義しました。この定義は、後に"URL Living Standard" [URL-LS]に移動しました。
W3CはHTML5勧告[9]を作成したとき、WHATWG URL標準への引用規格は、ゲーティングの問題であって、稀な妥協に達しました[10]。これは[URL]参照が単一の文書の参照ではなく、説明の段落で与えられます。
時代は他の方法で移動しました。ICANNは、非ASCIIトップレベルドメインを承認しましたが、IDNA仕様（[RFC3490]と[RFC5895]）は、完全にIRI処理に対処しませんでした。続いて、Unicode consortiumは、通過中のURL処理に言及している、[UTS-46]を作成しました。
web security working groupは、[URL-LS]が再定義する、W3C [CORS]仕様で洗練された[RFC6454]（"ウェブ生成元の概念"）を開発しました。IETFでの更新は放棄されました。WHATWGでの作業は[FETCH]仕様で続いています。
複数の文書を作成している複数の包括的な組織が存在し、また一貫して作成する軌道があるかどうかは不確かです。この章は、現在アクティブな組織と仕様の列挙を試みます。レビュアー：我々が逃したまたは誤って得た重要な進行中の活動はありますか？その現在の作業が影響を受ける利害関係者は誰ですか？（この提供に役立つ必要な組織の調整を決定します。）
組織は、IETF [11]、WHATWG [12]、W3C [13]、Web Platform.org [14]およびUnicode consortium [15]が含まれます。各組織の開発中の関連する仕様があります。
[appsawg-uri-scheme-reg]は、working groupのlast callをパスし、IESGのレビューに入りました。
'file:' [kerwin-file-scheme]と'urn:'を含む、新しいスキームと古いスキームの更新は継続します。
IRI working groupは終了しましたが、作業はApplications Area working groupで継続することができます。現在放棄された、更新を必要とする文書は、3つのドラフト（[iri-3987bis]、[iri-comparison]および[iri-bidi-guidelines]）があります。これは当初 [RFC3987]を廃止することを意図していました。
URNBis working group [16]は、URNの定義を更新するために作業していましたが、[RFC3986]での文言の一部の難しさがあります。具体的には、[17]は更新[RFC3986]を更新します。
[URL-LS]は、living standard [18]として開発されています。これは、主にブラウザーのために重要なものを指定することに焦点を当てています。新しいスキームが登録されるかもしれない手段はまだ定義されていません。この作業は[UTS-46]に基づいており、[RFC3986]と[RFC3987]の両方を時代遅れにする明確な目標が含まれています。
Web Applications Working Group [19]は、TAG[20]と協力して、[W3C-URL]として技術的な内容の違いのないWHATWGの作業を散発的に再発行しています。この関係を形式化するために、[url-workmode]の提案があります。
W3C TAG [21]は、URLの'フラグメント'部分の定義にいくつかの問題点を指摘する、フラグメント識別子とメディアタイプの定義[22]のためのベストプラクティスを開発しました。TAGはリエゾン交換が起こることを確実にするために取り組んでいます。
また、HTML working group [24]によって更新される、[URL] [23]へのHTML5の参照は暫定的な解決策であることに注意してください。
WebPlatform.orgは、W3Cとウェブベンダー[25]が後援する活動です。[WP-URL]は、[URL-LS]に基づいてGitHubのブランチ[26]で開発されています。これは現在、主により分かりやすく親しみある方法でパーサーのロジックを書き換えるために、依然として[URL-LS]に折り返させる必要がある作業が含まれています。意図は、一度準備が整うとこの作業をマージすることであり、同期して2つのバージョンを維持するために積極的に作業することです。
[UTS-46]は、ドメイン名をマッピングするパラメータ化された関数を定義します。[URL-LS]は、パラメーターに使用される特定の値を指定する、この作業をベースにしています。Unicode Consortiumは、[RFC3490]から[RFC5895]へ移動するレジストリー（例えばDENIC）として[UTS-46]を適応させる計画です。
この章は、我々が協調して解決を必要とみなす問題を提示します。レビュアー：我々が見逃しているものはありますか？これら問題のいずれかを解決する価値がありますか？
主な問題は、重複するが互いに適合しない矛盾する仕様が存在することです。
加えて、URLの処理が曖昧でなく安定させるために解決される必要がある問題は、次のとおりです。
上記の問題の多くは、いくつかの組織横断的な協力を必要とします。この章は、文書に関して、可能な更新と手続き上の問題の両面から、選択肢と可能な次の手順を説明します。
レビュアー：必須？十分？見逃しているもの、誤りはありますか？
XML Signature WG [27]は、合同IETF/W3C Working Groupの例です。おそらく、URLとURIのトピックをカバーする合同working groupを形成することができます。[url-workmode]提案の要素は、この新しいWGの憲章に組み込まれ、それによってこの活動の第3の共同参加者としてWHATWGを確立することができます。
それに失敗するならば、それぞれの組織のworking groupにIETFとW3Cにおける責任のいくつかの組織の割り当てをすることが望ましいです。
IETFへのW3CのリエゾンはIETFが応答するまで正式なリエゾン要求を行うことを提案とともに、IETF/W3Cのリエゾンを巻き込む議論がありました。おそらく、リエゾン要求はこの文書を参照するかもしれません。
IETFにおいて、提案された変更の範囲は、IETFコンセンサスを得ることのできる最良の方法を決定することができます。IETF文書に必要な変更の範囲は、個別の提出を通して管理することができたとは考えにくいです。いくつかの意見は、[RFC3986]を更新するおよび/または[RFC3987]を廃止することが、完全なIETF working groupに要求されるというものです。（おそらく問題提起/範囲としてこの文書を使用して）別のグループが起草されない限りおよびされるまで、議論はIETF apps領域で行われています。一致した努力がそれらを復活させるためになされない限り、関連するトピックの前の場（public-iri@w3.org [28]、uri@w3.org [29]）は、重要なコミュニティーの貧しい表現が可能性がある程度に十分に古いものです。
W3Cにおいて、W3C WebApps、TAG、HTMLまたはいくつかの新しい活動のいずれかが変更を管理する必要があるかもしれませんが、レビューに必要なグループの性質は、必要な変更の程度に依存します。
現時点で、この文書についてのフィードバックをする最も確実な方法は、GitHub issue list [30]で問題について提起したりコメントすることです。
種々の時点で、多くはIETF URI標準[RFC3986]を置き換える、または更新することが求められています。これは物議を醸すアプローチですが、次のものが必要とされる最低限となります：
より物議を醸すものは、これが厳密に"need- to"ベースに行うことができるかどうか、または[RFC3986]由来のURIと[RFC3987] 由来のIRIの合併が実装するためのより明確な仕様をもたらすかどうかです。
再始動し、エラーを修正し、そしてエラッタを統合することによって、[RFC3987]を更新する作業を再起動するためにいくつかの意見があります。しかし、このパスは、URLに対する決定論的な処理とブラウザーとオペレーティングシステムの処理に対する参照の両方を設計する、単一の仕様に対する欲求を満足していないようです。
[RFC3987]でカバーされるトピックがW3C URL勧告によってもカバーされることを確認した後、この文書で説明された条件を指摘する短いRFCで廃止（obsolete）として[RFC3987]をマークします。
[CORS]、[URL-LS]および/または[FETCH]で置換されます。
この文書に役立つコメントや改善がAnne van Kesteren, Bjoern Hoehrmann, Graham Klyne, Julian Reschke, Martin Duerstからありました。
更新された[appsawg-uri-scheme-reg]が、スキームがURIスキームだけでなくURLスキームやIRIスキームとして供給するものを明確にするためにIANA URI scheme registry [31]にいくつかの追加要件や情報を追加するかもしれませんが、このメモは現在、IANAへのリクエストを含みません。
URLが異なるシステムで異なる動作をするときに作成されるセキュリティーの露出（exposure）に加えて、[RFC3490]、[RFC3986]、[RFC3987]、および[RFC5895]で定義されたセキュリティーの考慮全てがURLに適用されます。
Sam Ruby (editor) IBM Raleigh, NC USA Email: rubys@intertwingly.net URI: http://intertwingly.net/ Larry Masinter Adobe 345 Park Ave San Jose, CA 95110 USA Email: masinter@adobe.com URI: http://larry.masinter.net/