この文書は、 D. Eastlake 3rd: .sex Considered Dangerous (RFC 3675), February 2004. を 橋本英彦 が日本語訳した物です。 この文書の取り扱いについては、[Studying HTTP] の RFC 日本語訳を利用するにあたってに従って下さい。
Network Working Group Request for Comments: 3675 Category: Informational
D. Eastlake 3rd
Motorola Laboratories
February 2004
この文書はインターネットコミュニティのための情報を提供する物である。 この文書はいかなる種のインターネットの標準も明述する物ではない。 この文書の配布に制限は無い。
Copyright © The Internet Society (2004). All Rights Reserved.
定期的に、"アダルト" や "安全でない" データ、及びそのような物を示すための特別なトップレベルドメインや IP アドレスのビットの使用を要求するための提案が出る。 この文書は、法的、哲学的、そして特に技術的視点から、何故これが有害とされる考えなのかを示すものである。
定期的に、"アダルト" や "安全でない" データ、及びそのような物を示すための特別なトップレベルドメインや IP アドレスのビットの使用を要求するための提案が出る。 この文書は、法的、哲学的、そして技術的視点から、何故これが有害とされる考えなのかを示すものである。
猥褻なデータ、及びそのようなものの配置を強制するような .sex, .xxx, .adult, あるいは同様のトップレベルドメインの概念が、何人かの政治家及びコメンテータによって定期的に議論される。 その他の提案では、未成年者にとって適切と見られるもののための独占的に予約されたドメインを含んでいたか、あるいは内容を分離するために IP アドレスのビットや範囲を使用していた。
青少年オンライン保護法に伴う 1998 年 10 月の報告書では、下院商業委員会が "アダルトドメインを作成するための技術的障害はなく、またアダルトドメイン内の全てのウェブサイトを遮断する事は非常に容易だろう" と報告された。 また、報告書では、委員会がコンピュータ産業の規制を警戒しており、米国政府によるいかなる決定も "国際的な結論を持つだろう" とも報告された [HOUSEREPORT]。
British Telecom は、その計画を "強く支持" したと、米国商務省へ 1998 年に文書にて、アダルトトップレベルドメインを支持した。 理由: "性的に露骨なサービスがこの gTLD [それ] の中のドメイン名で運用する事を法律的に要求する事は、そのようなサイトへのアクセスを制御する事をはるかに単純でより容易にするだろう..." [BT]。 ICANN の前身の一つである、GTLD-MOU委員会は、1997 年 9 月の RFC で "赤信号ゾーン" トップレベルドメインを提案した [GTLD-MOU]。
アダルト業界の首脳陣の中にはその考えを支持する者もいた。 1998 年、theInternet Entertainment Group の社長である Seth Warshavsky は、.adult ドメインを見たいと米国上院商業委員会に言った。 "我々は、ネット上の全ての性的に露骨な物が存在するような所のための '.adult' と呼ばれる新しいトップレベルドメインの作成を提案する" と、Warshavsky は time 誌のインタビューで語った [WARSHAVSKY]。
更に最近では、この産業の他の企業家は、.com を使い続けるかもしれない限りアダルトドメインの作成に必ずしも反対しないと語った。
米国内の保守的なグループは、彼らはそのようなドメインを切望してはいないと言い、むしろ性的に露骨な物の発行者や供給者に向けられた刑法を要望する。 The National Law Center for Children and Families は、バージニア州フェアファックスにて、2001 年 2 月、そのような提案に賛成しなかったと発表した。 これとは異なる理由で、米国自由人権連合{American CivilLiberties Union} や他の市民自由団体もまたこれに反対している。
米国民主党の副大統領の指名候補者である、Joseph Lieberman 上院議員は、青少年オンライン保護法に関する連邦委員会の 2000 年 6 月の会合でその考えを支持した。 Lieberman は、準備した声明で "我々は、成人向け映画館の経営者や性的に露骨な雑誌を売るコンビニエンスストアの所有者と同じ標準を単に順守してくれるようにインターネットの権威者{arbiters} に依頼するだろう" と述べた [LIEBERMAN]。
1998 年法律作成委員会にて、米国議会は "未成年者に有害な全ての物を割り当てるためのドメイン名の設立" の調査をメンバーに要求し、委員会はその題目にその 2000 年 10 月の報告書の項を充てた。 そこでは、.xxx と .kids ドメインの両方は技術的に可能であるが、しかしそれは ICANN による作業を必要とするであろうと結論づけた。 報告書は、アダルトドメインは単に "適度に有効" であるかもしれないし、またプライバシーや言論の自由の問題を引き起こすかもしれない、と報告した [COPAREPORT]。
委員会はまた、IPv6 下での新しい IP アドレスのセットの割り振りによる内容についてのいわゆるレッドゾーンやグリーンゾーンの作成も調査した。 それら二つのゾーンのどちらにもない任意の、そしてそれらは未成年者に必ずしも適切でないか、あるいは不適当な物が、グレイゾーンの中で見られるであろう。 委員からのコメントの大部分は否定的なものであった: "この有効性は、特定の IP 番号に内容を帰属するという根本的な努力を要求するであろう。 このアプローチは潜在的に柔軟性を減らし、最適なネットワークパフォーマンスを妨げるであろう。 それは、チャットやニュースグループ、あるいはインスタントメッセージへのアクセスの遮断においては有効ではないであろう。"
2000 年 10 月、ICANN は追加トップレベルドメインを承認するためのその最初の会議の間に .xxx ドメインを拒否した。 理由は完全には明らかにされてはいないが、元 ICANN 女性議長 Esther Dyson は、アダルト業界がそのようなドメインが適切であるという事に完全に合意が得られてはいなかったと述べた。 一つの xxx の希望として、カナダ・オンタリオの ICM レジストリは、2000 年 12 月その決定を再考してくれるよう ICANN に依頼した [ICM-REGISTRY]。
2002 年、米国議会は "子供が安全な" 物のための kids.us ドメインの作成を命じた。 これは後に、以下の section にて記述されるようなものを含む理由によって、.kids ドメインを持つ全世界のための基準を立法化しようとする事が不適当であると納得させられていた。
性的に露骨な物の事となれば、全ての人、裁判所、政府が、それぞれ何が受け入れられ、何が受け入れられないかについて異なる視点を持っている。 その態度は時が経てば変わるし、またある街やある年においては適切だと見られている物が、次の街や年では抗議を受けるかもしれない。 どんな性行為描写が不法であるべきかどうかという掴み難い本質に直面した時、ある連邦最高裁の裁判官は陽気に{blithely} 次のように猥褻を定義した: "それを見た時に、それがわかる{I know it when I see it}"。
アメリカ合衆国では、猥褻は、とりわけ "その時代の地域社会の標準" を破るような、性的に露骨な物として定義される -- 言い替えれば、全国的規模でさえ、何が不法で、何がそうでないかを取り締まるような合意の下の規制はない。 更にその問題が難しい事に、国連には 200 以上の国コードがある事で、それらのうちの殆どは、政治的細部は自ら制限を課す事ができる事である。 ヌードモデルについての法律でさえ、年齢制限が異なる。 一般には 18歳だが、あるスカンジナビアの国のみ 17 歳である。 そこでの法を守り、適切な写真撮影として見られる事を行う写真家は、アメリカ合衆国では重罪犯であり子供のポルノグラファという烙印を押されていた。 また他の国々や集団では、ヌードフォトグラフィの全概念、あるいはあらゆる形におけるどんな人間の写真でさえ、宗教上受け入れられないかもしれない。
サウジアラビア、イラン、ナイジェリア北部及び中国は、例えば、オランダやデンマークと同じような自由な見解を持ってはいないだろう。 サウジアラビアや中国は、他のいくつかの国家のように、広くそのインターネット接続を検閲し、公式な見解が猥褻であるとされる web サイトからその社会を保護するために政府系機関を作った。 それらの .sex ドメインに含まれるべきものについての見解は、自由な西側の国々の中のものとは、ほぼ一緒にはならないであろう。
性的な物についてのそれらの激しく異なった意見は、何が .sex あるいは .adult トップレベルドメインについて適切か不適切かの国際的なコンセンサスが常に得られるという事をありえないものにする。 加えて、そのようなドメインの存在は、一部の保守的な法律作成者に、物議をかもす発行物をそのドメインへ移動するように要求し、そうしない物を罰するという事へのこらえられない誘惑を生み出すであろう。
保守的な政治家の中には、ICANN が 2000 年 10 月の会合にて .xxx を承認しなかった事に既に不平をあげていた者もいた。 2001 年 2 月の米下院の公聴会にて、法律作成者は "インターネット上の非常に広範囲にある恐ろしい猥褻物から子供を保護する手段としての二つの特別なトップレベルドメイン名 -- .kids と .xxx -- を承認しない事についての ICANN の理論的根拠を調査したい" と警告した。
.com サイトに基づいてブランドを構築する際に資源を投資していないようないくらかのアダルトサイト発行者が、彼らの現在のドメイン名を自発的に放棄するだろう事はもっともらしく見える。 代わりに、恐らくドメインに .xxx という変形を加えて、それらの元々のアドレスを維持するであろう。 .xxx の存在は、米国や他の国々で法律作成者がアダルトサイト発行者がアダルトドメインからのみ発行する事を要求する事や、インターネットの管理に関する進行中の政治的干渉を招く動きを推進し、また言論の制限や自主規制についての懸念を示すであろう。
実際、一般トップレベルドメイン名の最終決定者は --少なくとも現在は--ICANN ではなく米国政府である。 米国議会の会計検査院は 2000 年 7 月、通商部が権威ある root によって許可されたドメイン名について責任を負うべき位置にあり続けると報告した [GAO]。 GAO の検査役は、通商部が ICANN にその責任を委譲するための現行法下での "必要な権威" を持っているかどうかが不明確であるという結論を下した。
米国自由人権連合 -- そして他の国際的な世界インターネット自由擁護運動{Global Internet Liberty Campaign} のメンバー -- は、産児制限、AIDS予防、同性愛者の性交渉、刑務所における強姦の社会的問題等についてをあからさまに表す発行者をアダルトドメインへ強制的に移動させる事ができる、と警告した。 一度そこへ行けば、それらは非難され、フィルタリングソフトウェアを使って学校、図書館、会社及びその他の団体によって容易に遮断されるであろう。 自身をポルノグラファーとして見ず、既存のアドレスを保持するような情報の発行者は、起訴の対象とされるかもしれない。
アダルトトップレベルドメインの存在は、政策や立法の関連する取り組みのための門戸を開くであろう。 不快な物として定義する事ができる多くの異なる軸がある: すなわち、性交渉、暴力、憎悪、異端信仰、政府転覆、不敬、違法薬物、冒涜、政治的正当性、犯罪の称賛、法則違反の扇動等である。 そのような提案は、それら勧告の技術的な実現可能性や現実性に関係がない特別利益団体によって、ICANN や米国政府及びその他の政策決定母体へ進行中の議案について働きかける事を招く。
アダルトトップレベルドメインは、表現の自由を危険にさらす事により法的に否定的な影響を持つ事ができた。 連邦最高裁裁判官 Sandra Day O'Connorは、インターネット上の "成人ゾーン" の存在が将来の通信品位法 (CDA) をより憲法上のものとして見られるとするであろうという事を示唆した。 1997年の CDA の最高裁判所での却下 [CDA] への彼女の部分的異議において、O'Connor は "インターネットの最終的な区画化の可能性は期待が持てると思う" と述べた。 (最高裁判所は、CDA が "猥褻な"、あるいは "明らかに攻撃的な" 物をオンラインで配布する事を罪とする事によって言論の自由権を侵害すると裁決した。 )
プライバシーはそのような提案によって損害を受けるかもしれない。 弾圧的な政府やその他の組織が、成人向けと分類されたドメイン内のサイトへの訪問を追跡し、訪問者についての個人識別情報を記録する事はより容易になるであろう。 弾圧的な政府は即座に、単純なユーザを監視し、またそれらの活動について彼らを起訴するための力をますます持つであろう。 更に、トップレベルドメインが、チャット、電子メール、ニュースグループ、インスタントメッセージ、及びまだ考案されていないような新しいサービスへのアクセスを制御する事において有効だろうという事もまた信じ難い。
上記にて概説されたような哲学的・法的障害を無視しても、ドメイン名あるいは IP アドレスによる内容分類を課そうとする事には根本的な技術的障害がある。 強制的に内容の分類を行う事は、section 4.1 にて議論されるように、通常トップレベルドメイン名を使用する考えで進められるが、我々は、section 4.2 にて IP アドレスのビットあるいは範囲を使用する可能性についても議論する。
section 4.1.4 にて、いくつかの特定の最上位層のプロトコルにおける障害が議論される。 いくつかの場合で、これらのプロトコルは異なる名前空間を使用する。 特性を名付ける事についていまだ考えてもみないようなプロトコルが将来に考案され追加されるかもしれない、という事を心にとめておくべきである。
更に、我々は section 4.3 にて代替技術として PICS labels [PICS] について議論する。
制限された技術的背景のみが仮定されるので、いくつかの基本的情報は以下に含まれる。 いくつかの場合では、記述は単純化され、詳細は省略される。
この技術的議論は定義の問題を最小限にする。 しかしそれでも、いくつかの技術的考察を評価する事が現実的な世界的検閲システムのために必要な分類の量をいくらか見積もる事は必要である。 この点についての合意の可能性はない。 我々の目的のために、世界の人口はおよそ 90,000 の重なり合う思想的共通性から成り、その各々は異なる分類の興味を持つであろうという事を独断的に仮定するであろう。 加えて、我々は、いくつかの特定はされないが巧妙なエンコーディングスキームが 300 ビットのラベルによって全ての情報の適切な世界的分類を可能にすると独断的に仮定する。 300 ビットのラベルは大きすぎると言う者も、小さすぎると言う者もいる。 それでも、我々はいくつかの技術的な評価のためにそれを使用するであろう。
インターネットのネーミング及びアドレッシングにおける最も目に付くユーザの可視部分はドメイン名システムである [RFC 1034, 1035]。 ドメイン名とは、aol.com, world.std.com, www.rosslynchapel.org.uk, あるいはftp.gnu.lcs.mit.edu のような、分類されるドット文字列である [RFC 1035, 1591, 2606]。 ドメイン名は、多くの World Wide Web アドレスや URL [RFC2396] の重要な部分を形成し、一般に "//" の後ろに現わされる。 ドメイン名システムのためのセキュリティは [RFC 2535] にて標準化されているが、あらゆる重要な範囲には展開されていない。
ドメイン名は、世界的に分散され階層的に委任されたデータベース中のノードを指定する。 ネットワーク上のマシンの IP アドレス (以下 section 4.2 を参照) 、メールの配達情報、及びその他の種類の情報を含む、様々な種類の情報がそれらのノードにて格納されるだろう。 従って、foo.example.comにて格納されるデータは、特定のマシンにデータを送るための数値情報、すなわち、あなたが <http://foo.example.com> を閲覧しようとする時に使用されるであろうデータや、"@foo.example.com" の任意のメールアドレスを扱うための (mailhost.example.com が言う) コンピュータの名前、あるいはその他の情報であろう。
ニュースグループ名やインターネットリレーチャット (IRC) のチャンネル名のように、他のネーミングシステムを使用するものもある。
提示された従来の分類案としては、"成人用" のための .sex や .xxx と "安全な" あるいは同種のもののための .kids のような、トップレベル名を予約しておく事である。 これに関する技術的及び言語の問題は、以下の節にて記述される。
名前による分類を使用する時、第一の問題はそれを課す名前をどの言語からとるか? という事である。 言葉や頭文字は異なる言語では非常に異なる意味を持ちうるし、また音声の衝突が考慮される場合はその混乱の可能性が増加する。
検証可能な問題の例として、数年間トルクメニスタン政府が、登録されたセカンドレベルドメイン名のうちのいくつかが問題をはらんでいるかもしれなかったので、財源であった ".tm" への新しい登録を一時停止したという事に注目する。 特に、<http://www.nic.tm> 上の web ホームページにて以下のように言及した:
今日世界中ではおよそ 6,000 言語が使用されているが、これは 2100 年までに約 3,000 まで減少すると予想されている。
ドメイン名システム (DNS) の設計の重要な側面は、データ管理を階層的に委任{delegation} するものである。 DNS は実際には単体で動いており、この委任によって、最初の配備以来増え続け、その量は五桁以上の増加を見る事ができた。
第一の問題は、ほとんどのコンピュータや web サイトが、それらのうちのいくらかだけが特に分類されるべきであるようなデータの集まりを持つだろうと思う人間がいるという事である。 特別なトップレベルドメイン名 (TLD) の使用は、そのサイトが心配しなければならない DNS ゾーンの数を増加する。 例えば、そのサイトが何らかの方法で既に "kids", "normal", "adult" 各 pile 中にそのデータをソートして持っていると仮定する。 特別な TLD ラベルが無くても、それは例えば、kids.example.net, adult.example.net, other.example.net の下でそれらを格納する事ができる。 これは、単にデータベースエントリの example.net ゾーンのメンテナンスを必要とするだけであろう。 特別な TLD ラベルがあるならば、少なくとも (通常の物のための) example.net, example.net.sex, example.net.kids が保持される必要があり、これらは三つの別個のゾーンにあり、また DNS 木の異なる部分にあり、三つの別個の委任の下にある。
カテゴリの数が増大するにつれて、カテゴリの組み合わせの数は急増し、またこれはすぐに完全に管理できなくなる。 もしラベリングに 300 ビット相当量が要求される場合、システムは、理論上、2**300 の名前カテゴリを必要とし、これは事実上不可能である。 個々のサイトは全てのカテゴリを使用する必要がないだろうし、またカテゴリドメイン名は全てがトップレベルの名前である必要は無い。 しかし、これは未だ管理できない悪夢となるであろう。
インターネット上のデータのプロバイダは、誰かが誤解を招きやすいドメイン名を持つそれらのコンピュータの IP アドレスを指し示している名前を生成する事を止める事はできない。
DNS はデータベースとして働く。 それは、リソースレコード、あるいは RRs と呼ばれる、特定のデータをドメインネームに関連付ける。 例えば、あなたが URL を閲覧する時、ほとんどの場合 URL 中にあるドメイン名は DNS にて lookup される。 その後、その結果のアドレスはあなたの web ブラウザやその他のソフトウェアからサーバや peer へと送られたパケットをアドレスするために使用される。
階層的な委任というシステムに関して我々が section 4.1.1 にて何を言ったかを記憶しているか? その制御は委任され、また DNS ゾーンのデータを制御できる誰もが、example.com について言えば、(それらがより深い名前空間のうちのいくらかをまだ他に委任するというような範囲を除いた) その名前あるいはそれより深い名前にデータを挿入する事ができる。 それ故に、example.com の制御者は、purity.example.com が持つアドレスと同じコンピュータアドレスを、www.obscene.example.sex に関連付けたデータを挿入する事ができる。 これは、www.obscene.example.sex の web サイトと同じ関連付けされた IP アドレスを使用するために purity.example.com へのあらゆる参照に向ける。 この、obscene.example.xxx ゾーンを制御する、仮想 webサイトの管理者は、example.com DNS ゾーン以外の管理は行わない。 これでは、任意の ".sex" 分類法に適合させる事は技術的に不可能である。 この代案では、ある人物が、恐らく分類分けを汚染する目的で、実際には任意の完全にはいかがわしくないサイトを指して、foo.stuff.sex のような、成人向け分類要求に適合する名前を作成する事ができた。 下図を参照せよ。 各 "ゾーン" は、物理的に異なるコンピュータセット上でホストする事ができるだろう。
+-----------------------------------------+
| . (root) zone |
| .com .org .net .us .uk .sex ... |
+---+---------------------------+---------+
| |
V V
+--------------------+ +--------------------+
| .com zone | | .sex zone |
| example.com ... | | example.sex ... |
+---------------+----+ +---------------+----+
| |
V V
+---------------------+ +----------------------+
| example.com zone | | example.sex zone |
| | | |
| purity.example.com -+--+ +---+- obscene.example.sex |
| virtue.example.com | | | | porn.example.sex |
| | | | | | | |
+------+--------------+ | | +--------+-------------+
| +------+------+ |
| +-------------+ | |
V V V V
+-----------------+ +------------------+
| 高潔なデータ | | 卑猥なデータ |
+-----------------+ +------------------+
特定のプロトコルに関連した更なる考察がある。 我々はここではいくつかのみを考える。 最初の二つ、電子メールと World Wide Web は、ドメイン名アドレッシングを使用する。 次の二つ、ネットニュースと IRC は、異なる名前空間を使用し、名前に基づいた分類に関する更なる技術的問題を例証する。
標準のインターネットツールは、ユーザが電子メールヘッダ内に任意のドメイン名を置く事を止めるための方法を提供しない。
標準のインターネット電子メールプロトコルは、内容から "エンベロープ"情報を分離する [RFC 2821, 2822]。 エンベロープ情報は、メッセージがどこから発生したかを述べ、また誰に送られるべきかを示すものである。 内容フィールドには "From:" や "To:" のようなラベルから始まるものがあるが、これらの内容フィールドは実際には効果はなく、メールサーバ上の SMTP ポートへ telnet するような、単純で、普通に利用可能なソフトウェアを使用して、任意に偽造する事ができる。 内容フィールドはエンベロープフィールドと比較されない。 それらが同じであるように要求する事は、郵便ポストに預けられた郵便の手紙が返信用住所としての郵便ポストをリストにする事をを要求し、メールにある住宅あるいはビジネス用返信用住所がその住宅あるいはビジネス用住所から郵便局によって見つけ出す事のみを可能にする事に似ているであろう。
異なるメールクライアントが電子メールの内容からエンベロープ情報とヘッダをそれぞれに表示している一方で、一般に本質的な内容フィールドは目立つように与えられる。 従って、内容へのラベリングと全く同じでないが、From や To 等のヘッダに記されている電子メールアドレス中の任意のドメイン名を持つ誰かへとメールを送る事が重要でない事は注目されるべきである。
電子メールアドレスやメーリングリストへメールを転送するためにホストをセットアップする事もまた容易である。 通常のメールツールからこの転送者へと送られたメールは、自動的に転送者の名前を反映する内容ヘッダを持つだろうが、転送者はエンベロープ情報を変更して、メールを実際に転送目的先メールアドレスに送るであろう。
例えば、(偽名を持つ) innocuous@foo.example.org という無害な社会的メーリングリストがあり、そして誰かが cat-torturers@other.example {猫虐待者} へと転送するようにセットアップする。 転送者に送られたメールは転送され、無害なメーリングリストに現れるが、通常の "To:innocuous@foo.example.org" 内容ヘッダの代わりに、そのボディ中に "To: innocuous@other.example" ヘッダを持っている。 その故、メールリーダソフトウェアは猫虐待者のヘッダを表示する。 同様の事は、インターネットメールの "bcc" あるいは "blind courtesy copy" という機能を使用して行う事ができる。
セキュアな電子メールについての作業が進行中である; しかし、そのような取り組みは現在、特定のエンティティがそのメールの実際の著者のものであるかどうかを確認する事を可能にするのみである。 それらが認証を提供する場合、その時までに "From" アドレスの三番目のタイプにエンベロープや内容の "From" アドレスを加えるが、それらはメールの内容中のドメイン名の制御や認証に関連付けられてはいない。
HTTP 1.1 [RFC 2616] をサポートする最近の web サーバやブラウザは、サイトにアクセスするために使用されるドメイン名が利用可能である。 従って、例え同じ IP アドレスの同じマシン上に異なるドメイン名を持った web サイトがあってもアクセスする事ができる。 これは、同じコンピュータ上の異なるカテゴリの情報が異なるドメイン名を通じてアクセスされるようにセットアップする事ができるので、名前に基づいた分類にとって小さなプラスである。 しかし、あらゆる程度のデータの種類を持つコンピュータにとっては、データの種類が急増した場合、全ての種類のデータにそれぞれ名前をつけるために、管理できないほどの数の名前を必要とするであろう。
初期の HTTP 1.0 [RFC 1945] では、web リクエストがサーバマシンに送られた時、URI 中で使用される元々のドメイン名は含まれていなかった。
一方、web は自動転送機能を持っている。 従って、ある者が特定のドメイン名でデータにアクセスしようとする場合、そのサーバは、一時的あるいは恒久的に、そのブラウザを、名前フィルタリングを迂回するように、異なるドメイン名や、あるいは数値 IP アドレスにリダイレクトする事ができる。
ネットニュース [RFC 977, 2980] は、ドメイン名に見た目は似ているが、最も重要なラベルがドメイン名の反対に、左側と、少なくとも右側にはある以外は、階層的に構造化したニュースグループ名を使用する。 しかし、名前は階層的な構造をしているが、中央による管理はない。 代わりに、ニュースサーバは、他のニュースサーバが持つメッセージを交換させるためにそれに接続し、メッセージを交換したいニュースグループ中のメッセージのみを互いに更新する。
ドメイン名システム中の階層的区域は局地的に管理されるが、ICANN や米国商務省によって多かれ少なかれ制御されているトップレベルルートサーバから順に始めて到達可能である必要がある。 ネットニュースの世界のポイントにはそのような中心となる点はないので、世界中の任意の一組あるいはそれより大きな組のニュースサーバは、任意のニュースグループ名の下のニュースメッセージを交換させる事ができ、またそれがネットのどこか他のところで使用されたもののコピーを含む事もでき、中央による管理やあるいはその影響を与える事さえも事実上不可能にする。 実際、あるサーバのいくつかのニュースグループ名前空間では、誰でも任意の名前を持った新しいニュースグループを作成する事ができる。
たとえニュースグループ名を制御できても、メッセージの内容は投稿者によって決定される。 節度のあるグループもある一方で、殆どはそうではない。 ニュースメッセージのために "取消" メッセージを送る事ができるが、このメカニズムは乱用されやすいので、いくつかのサーバは取消を無視するように構築される。 どんな場合にも、あらゆる取消が送られる前に、そのメッセージが世界中の膨大な数のコンピュータに配達されているかもしれない。
そしてもちろん、ニュースグループ名へのラベリングに 300 ビット相当量を当てる事はそれがドメイン名に当てるのと同じくらい不可能である。
インターネットリレーチャット [RFC 2810-2813] は、異なる名前空間を使用するサービスのもう一つの例である。 これは、特定の IRC サーバのネットワーク内で意味を持つ単一の "チャンネル名" のレベル空間を使用する。 これは階層的ではないので、各サーバは全ての名前について知っていなければならず、これはサーバのネットワークのサイズを制限する。
ニュースグループ名と同様に、IRC チャンネル名は任意の全体的な "ルート" に従属している、あるいはそこに到達可能かどうかではなく、局地的に決定されるという事実は、中央集権化した政治的支配を事実上不可能にする。
インターネットが基づくインターネットプロトコル (IP) の重要な特徴は、データを "パケット" に分解するという事である。 これらのパケットは、出所から目的地へとそれぞれ扱われ発送される。 各パケットは、インターネットがパケットを運ぼうとする目的地点のための数値のアドレスを運ぶ。
(エンドユーザは通常これらの数値アドレスを見る事はなく、代わりに上記 section 4.1 に記述されるような "ドメイン名" を扱う。)
現在より広く使用されている数値のアドレスシステムは IPv4、あるいはインターネットプロトコル・バージョン 4 と呼ばれ、32 ビットのアドレスを備える [RFC 791]。 新しい IPv6 [RFC 2460] への移行が増加しており、それは128 ビットのアドレスを備える [RFC 2373, 2374]。
パケットは通過の際に悪意を持って修正される可能性があるが、その最も一般的な結末はサービスの拒否{denial of service} である。
内容フィルタリングのためにアドレッシングを使用する事の問題の一つは、これが非常に粗い技術であるという事である。 IP アドレスはネットワークインターフェイスを参照するが、これは通常、複数の web ページやファイルのセット等、遮断するか利用可能にするかを望まれた極一部のみを収容できるコンピュータシステム全体に相当する。 単一の IP アドレスは、ますます、その後ろの複数のコンピュータを隠す NAT (Network Address Translation) box [RFC 2663] に相当するかもしれないが、その場合でも、これらのコンピュータは通常サーバではない。
しかし、粒の粗さというの問題を越えてさえ、階層型ルーティングの実際的な制約は、IPv4 アドレスの単一ビットでさえ、あるいは IPv6 アドレスの意味深いビット数への割付けを不可能にする。
IP アドレスの割り当てはネットワークの経路選択や接続形態に密接に結びついているので、IP アドレスは内容フィルタリングのためには技術的に不適当である。
データのパケットがインターネット上を流れる際、それらを転送する方法についての決定はそれらの目的地 "の方向へ" とされなければならない。 これは、目的地アドレスのパケットの最初のビットと "ルーティングテーブル"中のエントリとを比較し、接頭辞の最長マッチを持つテーブルエントリによって示されるようなパケットを転送する事によって完了する。
インターネットが現実に複雑な網状の機構{mesh} である一方、もし単純に、我々はそれが "最上層" で中央のバックボーンを持つ事を考慮すれば、パケットは一般的に以下のように転送される:
ローカルのネットワークのコードは、そのパケットが "ローカル" ネットワーク上の別のコンピュータへ直接送られるべきか、特に近くの別のネットワークへ転送するためのルータに送られるべきか、それともより高いレベルでのサービスプロバイダのネットワークへ転送するような "既定" のルータに "上げる" べきかどうかを決めるために、自身のルーティングテーブルを見る。 パケットの目的地が "十分に遠い" 場合、それは結局バックボーン上のルータまで転送されるであろう。 そのようなルータは、それが最上位にあるか、あるいは "default free" ゾーンにあるので、パケットを "上に"送る事はできないから、パケットを送るための他のトップレベルのルータの完全なテーブルがなければならない。 現在、そのようなトップレベルのルータは非常に巨大でまた高価な装置である。 それらは、何万ものルートのテーブルを維持する事ができるに違いない。 パケットがその目的地が位置するネットワークの一部のトップレベルのルータに到着した時、そのパケットはより詳細でローカルな連続するルータによって、その終点アドレスが位置するローカルネットワーク上のルータに到着するまで "下ろされ" る。 このローカルのルータは、目的地のコンピュータへ直接パケットを送る。
それらのルーティングの決定は全て接頭辞の最長マッチに基づいてなされるので、IP アドレスは一般的な名前やラベルでは無いように見えるが、ネットワークの実際の接続形態やルーティングの構造に決定的にかつ緊密に関係している。 もしそれらが任意に割り当てられていれば、ルータは、現在のルーター設計における技術的能力をはるかに超える程の特定のアドレスのための非常に多くの特定のルートを記憶する事が要求されるであろう。 インターネットは致命的な崩壊を迎え、働かなくなるであろう。
階層の各レベルにて割り当て上いくらか非能率な点があるという事は注目されるべきである [RFC 1715]。 一般に、割り当ては二つのアドレスの力関係をもって決定されたり、その拡大や縮小を必要条件とするが、全てのアドレスを使用する事は実際的ではない。
(上記の単純化された記述はマルチホーミングや他の多くの詳細についてを無視する。)
内容フィルタリングへの使用目的で IPv4 グローバルインターネットアドレスを 1 ビットさえ再分配するための実際的な方法は全くない。 そのようなアドレスは供給不足である。 実際には、そのような割り当ては、利用可能なアドレス数を半分にしてしまうであろう。 これを行うためには、階層的な割り当て [RFC 1715] やルーティングの非能率さを無くしてさえ、十分なアドレスがない。 仮にそうであってさえも、現在の数はインターネット上の全てのホストを持つ組織による再割り当てが要求されるような事を考慮して割り当てられてはいなかったので、数十億ドルもコストがかかる極めて困難な作業となる。
これらの問題が克服されてさえ、アドレスビットのトップ付近の単一のビットの割り当てにも、恐らく default free ゾーンのルートの数を 2 倍にするであろう。 これは、現在のルータの能力を超え、また莫大なコストを要するような未だ存在しない新しいルータへの数千ヶ所もの改良を要求するであろう。 アドレスビットの末端付近のビットの割り当ては、例えそのビットが利用可能でも、要求か強化をするために非実用的なワールドワイドなローカルの再構築を要求するであろう。
また、もし単一ビットのみが内容にラベルを付けるように割り当てられればそれは全てそうだし、一つ以上はいうまでもない。 しかし、実際には 300 ビット、もしくはそれ以上を必要とするだろうと推測される!
基本的に、その考えは成功の見込みがない {non-starter}。
IPv6 は 128 ビットのアドレスフィールドを供給する [RFC 2373, 2374]。 更に、IPv6 アドレスの割り当てはその発達の初期にある。 従って、ラベリングのために IPv6 アドレスの 1 つのビットを割り当てる事が考えられる。
しかし、先 (section 4.2.1) で議論されるように、ラベリングのために割り当てられた全ての最上位ビットルーティングシステムに負わせるコストを倍にする。 1 ビットを割り当てる事は、概してルーティングテーブルのサイズを倍にするであろう。
2 ビットを割り当てた場合、それは更に 4 倍になるであろう。 現実的に世界的にラベルを付けるために必要だと我々が仮定する 300 ビットを割り当てる事は、300 が 128 よりずっと大きいので、IPv6 では理論上不可能であり、また仮にそれが可能だったとしても、ルーティングテーブルのサイズは技術的に不可能なものになるであろう。 割り当てが可能であるとして、例えば 20ビットを割り当てたとしたならば、テーブルサイズを不可能にも 100 万倍にするであろう。
少ないビット数を割り当てる事には更なる問題もある。 後半 64 ビットをラベルのための使用とは両立しないように使用するという技術的な提案がある [RFC 2374]。 そのため、それは恐らく "中央のビット" (実際には前半のわずかなビット) でなければならないであろう。 IPv4 でのように、これを世界的に強制する事は不可能であろう。 もしそれが可能であらば、1 ビットもしくは 2 ビットを割り当てる事ができるだろうが、それでは明らかに (量的・能力的に) 不十分であろう。
PICS ラベル (Platform for Internet Content Selection) は、インターネットアクセス可能なものに "格付け" を提供するための一般化されたシステムである。 詳細については PICS 文書 [PICS] を調べるべきである。 一般的に、PICS は任意の多数な格付けのためのサービスや制度を仮定する。 各サービス及びシステムは URL によって識別される。
全体として、ラベル情報等の 300 ビットを提供する複数の PICS サービスがある事は全く合理的であるだろう。 PICS サービスは全ての興味のあるコミュニティのために存在しうる。 この種の技術は、その分類やラベリングを様々で動的な世界において利用可能にする唯一の合理的な方法である。
そのような PICS ラベルサービスは、例えば、政府が公表した検閲済カテゴリを配布するために利用する事ができる一方で、これが国家的ファイアウォールによる政府検閲に比べてどの程度悪い事なのかは明らかではない。
PICS 格付けシステムは、本質的に一つ以上の要素にて定義され、また格付けされるオブジェクトに各要素で割り当てられる数値の範囲である。 サービスは、ラベルが実際の格付けを含むようなラベルの源である。 格付けには特定的なものと包括的なものがある。 特定的な格付けは特別な URL [RFC 2396] にあるものにのみ適用され、画像ファイル等も含め、それから参照される任意のものには適用されない。 包括的な格付けは、指定されたURL と言明される URL に前方一致するような全ての URL に適用される。
単純化された例示ラベルは、以下のように見られるだろう:
(PICS-1.1 "http://movie-rating-service.example.net"
labels for "ftp://movies.example.sex/raunchy-movie"
ratings (sex 6 violence 1 language 8 drugs 2 Satanism 0))
機械可読格付けシステム解説書は、提供される値の範囲と要素のセットを含む。 妥当性の開始時間と終了時間のような、追加的情報はラベルに組み入れる事ができる。
ラベルは現在三つの方法で利用する事ができる: (1) HTML 中に埋め込む, (2) HTTP レスポンスにてデータと共に提供される, (3) 第三者から別個に。 内容が、上に列挙された最初の二つの方法のように、それに埋め込まれたラベルを持つか、データが返される時にそのソースによって転送される事を必要とする場合、カテゴリの詳細化と言論の強制という問題を引き起こす。 しかし、別の団体が内容についてのラベルを決定し、提供するという第三の方法を使用すれば、ユーザはその調査を望むような第三者を選択する自由があり、無数のカテゴリや作者、及び評価者が同時に存在する事を支持する。
デジタル署名は PICS ラベルをセキュアにするために利用できる [PICS]。
あらゆるラベリングや分類のスキームは、データを不正確にラベリングしたり、あるいは不正確に分類したりするための意図的な試みがあるだろうという事を仮定しなければならない。 これは、特定のラベリングについてのいくつかの既知の利点のためであるかもしれないし、あるいは単にそのシステムを崩壊させるためかもしれない。 結局、ソースが送られた情報を常に正確かつ便利よくラベリングするならば、セキュリティは遥かに容易となるであろう [RFC 3514]。 そのような強制能力についての考察は、この文書中で言及された様々なメカニズムと共に議論される。
.sex のような、単一のトップレベルドメイン名や、単一の IP アドレスビットを、世界中の "成人向け" あるいは "不快な" 内容の強制的ホームとして割り当て、またそうなるであろうという概念は、法的にも技術的にも無意味である。
その区域にどんな種類の内容があるべきかについての国際的な合意を得る事は不可能である。世界中の状況においては、単一あるいは少数のカテゴリの使用では不合理である。 300 ビットのような、世界の多くのコミュニティの基準を包含する事ができるのに妥当なサイズのラベルの実装は、ドメイン名や IP アドレスレベルで技術的に不可能であり、そのように当分の間残るであろう。 技術的不可能性に加えて、そのような強制は、ある管轄下での不法を強制的に話させるであろうし、同様にドメインや他の文字列名についての厳しい言語的問題を引き起こすであろう。
しかし、そこに政府の機関を含むかもしれない、非常に多くの独立した検閲者という概念や、そのような検閲者によって指定された格付けを選択し利用するために情報にアクセスするものの能力は、利用可能である。
この文書の section 2 及び 3 を実質的に全て書いた、Declan McCullagh の貢献と努力に、真に感謝いたします。
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Phone: +1-508-786-7554 (w)
+1-508-634-2066 (h)
EMail: dee3@torque.pothole.com
Copyright © The Internet Society (2004). All Rights Reserved.
この文章とその翻訳は、複製し他人に配布する事ができ、またその実装についてのコメント、その他の方法を用いた説明、その補助となるような派生的作業はそれらの中に上の著作権表示とこの段落を含む事によって、その全て又は一部を、いかなる制約も受けずに、作成、複製、発表、及び配布する事ができる。 しかしながら、インターネット標準化プロセスにて定義されている著作権のための手続きに従わなければならないような場合の中でインターネット標準を開発するという目的に必要である、あるいは英語以外の言語に翻訳する必要があるという場合を除いて、この文章自体を、その著作権表示や、インターネット学会あるいは他のインターネット団体への参照を削除するような、いかなる変更もできない。
上で認めた制限された許諾は永続的なものであり、インターネット学会及びその継承者や譲渡者によって取り消される事は無い。
この文書とここに含まれた情報は、"そのまま {AS IS}" である事を基に提供され、インターネット学会、及び IETF は、この中の情報の使用が、商用利用及び特定用途においていかなる権利もいかなる暗黙的保障も侵害していないという保障への制限を含め、明示的に又は暗黙的に、全ての保障を放棄する。
RFC Editer 機構の資金は、現在インターネット学会から提供されている。