RFC3675 日本語訳
3675 .sex Considered Dangerous. D. Eastlake 3rd. February 2004. (Format: TXT=53211 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Eastlake 3rd Request for Comments: 3675 Motorola Laboratories Category: Informational February 2004
コメントを求めるワーキンググループのD.イーストレーク第3要求をネットワークでつないでください: 3675年のモトローラ研究所カテゴリ: 情報の2004年2月
.sex Considered Dangerous
危険であると考えられた.sex
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag "adult" or "unsafe" material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and particularly, the technical points of view.
「アダルトである」か「危険な」材料か同様のものに旗を揚げさせるために特別な最高平らな名前かIPアドレスビットの使用を強制するという提案が定期的にあります。 このドキュメントで、これがなぜ法的であるのと、哲学的からの病気の考えられた考えと、特に視点のテクニカルポイントであるかがわかります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Legal and Philosophical Problems . . . . . . . . . . . . . . . 4
4. Technical Difficulties . . . . . . . . . . . . . . . . . . . . 6
4.1. Content Filtering Using Names. . . . . . . . . . . . . . 7
4.1.1. Linguistic Problems. . . . . . . . . . . . . . . 7
4.1.2. Explosion of Top Level Domain Names (TLDs) . . . 8
4.1.3. You Can't Control What Names Point At You! . . . 9
4.1.4. Particular Protocol Difficulties . . . . . . . . 10
4.1.4.1. Electronic Mail (SMTP) . . . . . . . . 10
4.1.4.2. Web Access (HTTP). . . . . . . . . . . 11
4.1.4.3. News (NNTP). . . . . . . . . . . . . . 12
4.1.4.4. Internet Relay Chat (IRC). . . . . . . 13
4.2. Content Filtering Using IP Addressing. . . . . . . . . . 13
4.2.1. Hierarchical Routing . . . . . . . . . . . . . . 14
4.2.2. IP Version 4 Addresses . . . . . . . . . . . . . 15
4.2.3. IP Version 6 Addresses . . . . . . . . . . . . . 15
4.3. PICS Labels. . . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 17
6. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 法的で哲学的な問題. . . . . . . . . . . . . . . 4 4。 技術的困難. . . . . . . . . . . . . . . . . . . . 6 4.1。 名前を使用するコンテントのフィルタリング。 . . . . . . . . . . . . . 7 4.1.1. 言語学の問題… 7 4.1 .2。 トップ・レベル・ドメインの爆発は(TLDs). . . 8 4.1を.3と命名します。 あなたは、どんな名前があなたを指し示すかを制御できません! . . . 9 4.1.4. 特定のプロトコル困難. . . . . . . . 10 4.1.4.1。 電子メール(SMTP). . . . . . . . 10 4.1.4.2。 ウェブアクセス(HTTP)。 . . . . . . . . . . 11 4.1.4.3. ニュース(NNTP)。 . . . . . . . . . . . . . 12 4.1.4.4. インターネットリレーチャット(IRC)。 . . . . . . 13 4.2. IPアドレシングを使用するコンテントのフィルタリング。 . . . . . . . . . 13 4.2.1. 階層型ルーティング. . . . . . . . . . . . . . 14 4.2.2。 IPバージョン4は.3に.154.2を記述します。 IPバージョン6は.154.3を記述します。 映画ラベル。 . . . . . . . . . . . . . . . . . . . . . . 16 5. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 17 6. 結論。 . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 18
Eastlake 3rd Informational [Page 1] RFC 3675 .sex Considered Dangerous February 2004
イーストレーク3番目に情報[1ページ]のRFC3675.sexは、危険な2月が2004であると考えました。
7.1. Normative References . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . 19
8. Acknowledgement. . . . . . . . . . . . . . . . . . . . . . . . 21
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22
7.1. 引用規格. . . . . . . . . . . . . . . . . . 18 7.2。 有益な参照. . . . . . . . . . . . . . . . . 19 8。 承認。 . . . . . . . . . . . . . . . . . . . . . . . 21 9. 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 21 10。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 22
1. Introduction
1. 序論
Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag "adult" or "unsafe" material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and the technical points of view.
「アダルトである」か「危険な」材料か同様のものに旗を揚げさせるために特別な最高平らな名前かIPアドレスビットの使用を強制するという提案が定期的にあります。 このドキュメントで、これがなぜ法的であるのと、哲学的からの病気の考えられた考えと、視点のテクニカルポイントであるかがわかります。
2. Background
2. バックグラウンド
The concept of a .sex, .xxx, .adult, or similar top-level domain in which it would be mandatory to locate salacious or similar material is periodically suggested by some politicians and commentators. Other proposals have included a domain reserved exclusively for material viewed as appropriate for minors, or using IP address bits or ranges to segregate content.
みだらであるか同様の材料の場所を見つけるのが義務的である.sex、.xxx、.adult、または同様の最上位のドメインの概念は定期的に何人かの政治家と解説者によって提案されます。 他の提案は、排他的に未成年者のために適宜見られた材料のために予約されるか、または内容を隔離するのにIPアドレスビットか範囲を使用することでドメインを含んでいました。
In an October 1998 report accompanying the Child Online Protection Act, the House Commerce committee said, "there are no technical barriers to creating an adult domain, and it would be very easy to block all websites within an adult domain". The report also said that the committee was wary of regulating the computer industry and that any decision by the U.S. government "will have international consequences" [HOUSEREPORT].
チャイルドオンライン保護法に伴う1998年10月のレポートでは、「アダルトドメインを作成することへの技術上の障害が全くありません、そして、アダルトドメインの中のすべてのウェブサイトを妨げるのは非常に簡単でしょう。」と、下院Commerce委員会は言いました。 また、レポートには、委員会がコンピュータ産業を規制するのに用心深く、米国政府によるどんな決定も「国際的な結果を持つ」[HOUSEREPORT]と書かれていました。
British Telecom has backed adult top-level domains, saying in a 1998 letter to the U.S. Department of Commerce that it "strongly supported" that plan. The reason: "Sexually explicit services could then be legally required to operate with domain names in this gTLD [that] would make it much simpler and easier to control access to such sites..." [BT]. One of ICANN's progenitors, the GTLD-MOU committee, suggested a "red-light-zone" top-level domain in a September 1997 request for comment [GTLD-MOU].
ブリティッシュ・テレコムはアダルト最上位のドメインを返してもらいます、1998年の手紙でそのプランを「強く、支持した」と米国商務省に言って。 理由: 「そしてときに性的に明白なサービスはドメイン名がこのgTLDにある状態で作動するのが法的に必要であることで、[それ]がはるかに簡単であって、そのようなサイトへのアクセスを制御するのをより簡単にさせるだろうということであるかもしれません」… [BT。] ICANNの先祖のひとり(GTLD-MOU委員会)はコメント[GTLD-MOU]を求める1997年9月の要求における「赤い軽いゾーン」最上位のドメインを示しました。
Some adult industry executives have endorsed the concept. In 1998, Seth Warshavsky, president of the Internet Entertainment Group, told the U.S. Senate Commerce committee that he would like to see a .adult domain. "We're suggesting the creation of a new top-level domain called '.adult' where all sexually explicit material on the Net would reside," Warshavsky said in an interview at the time [WARSHAVSKY].
概念を是認した大人の業界幹部もいました。 1998年に、セスWarshavsky(インターネットEntertainment Groupの社長)は、彼が.adultドメインを見たがっていると米国上院Commerce委員会に言いました。 「私たちはネットのすべての性的に明白な材料がある'.adult'と呼ばれる新しい最上位のドメインの創造を勧めています。」と、Warshavskyは当時インタビュー[WARSHAVSKY]で言いました。
Eastlake 3rd Informational [Page 2] RFC 3675 .sex Considered Dangerous February 2004
イーストレーク3番目に情報[2ページ]のRFC3675.sexは、危険な2月が2004であると考えました。
More recently, other entrepreneurs in the industry have said that they do not necessarily object to the creation of an adult domain as long as they may continue to use .com.
より最近、産業の他の企業家は、.comを使用し続けるかもしれない限り、彼らが必ずアダルトドメインの創造に反対するというわけではないと言いました。
Conservative groups in the U.S. say they are not eager for such a domain, and prefer criminal laws directed at publishers and distributors of sexually-explicit material. The National Law Center for Children and Families in Fairfax, Virginia, said in February 2001 that it did not favor any such proposal. For different reasons, the American Civil Liberties Union and other civil liberties groups also oppose it.
米国の保守的なグループは、彼らがそのようなドメインに切望していないと言って、性的に明白な材料の出版社とディストリビュータに向けられた刑法を好みます。 ChildrenのためのNational法センターとフェアファクス(ヴァージニア)のFamiliesは、2001年2月に少しのそのような提案も支持しなかったと言いました。 また、様々な理由で、米国自由人権協会と他の公民権擁護団体はそれに反対します。
Sen. Joseph Lieberman, the U.S. Democratic Party's vice presidential nominee, endorsed the idea at a June 2000 meeting of the federal Commission on Child Online Protection. Lieberman said in a prepared statement that "we would ask the arbiters of the Internet to simply abide by the same standard as the proprietor of an X-rated movie theater or the owner of a convenience store who sells sexually- explicit magazines" [LIEBERMAN].
ジョセフ・リーバーマン上院議員(米国民主党の副の大統領の指名された人)はChild Online Protectionにおける連邦の委員会の2000年6月のミーティングで考えを是認しました。 リーバーマンは、準備された声明で「私たちは、単に成人映画劇場の所有者か性的に明白な雑誌を販売するコンビニエンスストアの所有者と同じ規格を守るようにインターネットの仲裁者に頼むだろう」[リーバーマン]と言いました。
In the 1998 law creating this commission, the U.S. Congress required the members to investigate "the establishment of a domain name for posting of any material that is harmful to minors", The commission devoted a section of its October 2000 report to that topic. It concluded that both a .xxx and a .kids domain are technically possible, but would require action by ICANN. The report said that an adult domain might be only "moderately effective" and raises privacy and free speech concerns [COPAREPORT].
このコミッションを創設する1998年の法で、米国議会は、メンバーが「未成年者に有害などんな材料の任命のためのドメイン名の確立」を調査するのを必要として、コミッションは2000年10月のレポートのセクションをその話題に注ぎました。 .xxxと.kidsドメインの両方が技術的に可能ですが、ICANNによる動作を必要とするだろうというのは結論を下しました。 レポートは、アダルトドメインが「適度に有効であるだけであるかもしれない」と書いて、プライバシーと言論の自由関心[COPAREPORT]を高めます。
The commission also explored the creation of a so-called red zone or green zone for content by means of allocation of a new set of IP addresses under IPv6. Any material not in one of those two zones would be viewed as in a gray zone and not necessarily appropriate or inappropriate for minors. Comments from commissioners were largely negative: "Effectiveness would require substantial effort to attach content to specific IP numbers. This approach could potentially reduce flexibility and impede optimal network performance. It would not be effective at blocking access to chat, newsgroups, or instant messaging".
また、コミッションは新しいIPアドレスの配分によって内容のためにIPv6の下でいわゆるレッド・ゾーンか緑地帯の創造について調査しました。 少しの材料も未成年者にとってグレーゾーンと必ずない適切であるか不適当であるとしてそれらの2つのゾーンの1つで見なされないでしょう。 コミッショナーからのコメントは主に否定的でした: 「有効性は特定のIP番号に内容を添付するためのかなりの努力を必要とするでしょう。」 このアプローチは、柔軟性を潜在的に減少させて、最適のネットワーク性能を妨害するかもしれません。 「それはチャット、ニュースグループ、またはインスタントメッセージングへのアクセスを妨げるところで有効でないでしょう。」
In October 2000, ICANN rejected a .xxx domain during its initial round of approving additional top-level domains. The reasons are not entirely clear, but former ICANN Chairwoman Esther Dyson said that the adult industry did not entirely agree that such a domain would be appropriate. One .xxx hopeful, ICM Registry of Ontario, Canada, in December 2000 asked ICANN to reconsider its decision [ICM-REGISTRY].
2000年10月に、ICANNは承認している追加最上位のドメインについて丸い間、初期の.xxxドメインを拒絶しました。 理由は完全に明確ではありませんが、元ICANN Chairwomanエスター・ダイソンは、アダルト産業が、そのようなドメインが適切であるのに完全に同意しなかったと言いました。 1人の.xxx前途有望な若者、2000年12月のオンタリオ(カナダ)のICM Registryは、決定[ICM-REGISTRY]を再考するようにICANNに頼みました。
Eastlake 3rd Informational [Page 3] RFC 3675 .sex Considered Dangerous February 2004
イーストレーク3番目に情報[3ページ]のRFC3675.sexは、危険な2月が2004であると考えました。
In 2002, the U.S. Congress mandated the creation of a kids.us domain for "child safe" material. This was after being convinced that for reasons, some of which are described in the following section, trying to legislate standards for the whole world with a .kids domain was inappropriate.
2002年に、米国議会は「子供金庫」の材料のためにkids.usドメインの創造を強制しました。 理由で、.kidsドメインで全世界の規格を制定しようとするのが不適当であると納得させられた後に、これはありました。それの或るものは理由のために以下のセクションで説明されます。
3. Legal and Philosophical Problems
3. 法的で哲学的な問題
When it comes to sexually-explicit material, every person, court, and government has a different view of what's acceptable and what is not. Attitudes change over time, and what is viewed as appropriate in one town or year may spark protests in the next. When faced with the slippery nature of what depictions of sexual activity should be illegal or not, one U.S. Supreme Court justice blithely defined obscenity as: "I know it when I see it".
性的に明白な材料、すべての人、法廷に来て、政府に何が許容できるか、そして、何がないかに関する異なった意見があるとき。 態度は時間がたつにつれて変化します、そして、1町か年間で適宜見られるものは次に抗議を引き起こすかもしれません。 何に関する滑りやすい自然が直面されているかと性的な活動の描写が不法であるべきである、1つの米国最高裁判事が陽気にわいせつを以下と定義しました。 「それを見るとき、私はそれを知っています。」
In the U.S.A., obscenity is defined as explicit sexual material that, among other things, violates "contemporary community standards" -- in other words, even at the national level, there is no agreed-upon rule governing what is illegal and what is not. Making matters more knotty is that there are over 200 United Nations country codes, and in most of them, political subdivisions can impose their own restrictions. Even for legal nude modeling, age restrictions differ. They're commonly 18 years of age, but only 17 years of age in one Scandinavian country. A photographer there conducting what's viewed as a legal and proper photo shoot would be branded a felon and child pornographer in the U.S.A. In yet other countries and groups, the entire concept of nude photography or even any photography of a person in any form may be religiously unacceptable.
米国では、わいせつが「現代の生活環境水準」に特に違反する明白な性的な材料と定義されます--言い換えれば、何が不法であるか、そして、何が不法でないかを治める同意している規則が全く全国レベルにさえありません。 件を作って、よりやっかいであるのが、200以上の国連国名略号があるということであり、それらの大部分では、政治上の区画分譲地はそれら自身の制限を課すことができます。 法的なヌードモデルの仕事のためにさえ、年齢制限は異なります。 それらは一般的に18歳ですが、唯一の17は1つのスカンジナビアの国の歳です。 どんなフォームでも、そこの米国Inにもかかわらず、他国とグループで法的で適切な撮影に重罪犯人と子供ポルノ作家と商標を付けるように見られるものを行う写真家、ヌード写真の全体の概念または人のどんな写真さえも宗教的に容認できないかもしれません。
Saudi Arabia, Iran, Northern Nigeria, and China are not likely to have the same liberal views as, say, the Netherlands or Denmark. Saudi Arabia and China, like some other nations, extensively filter their Internet connection and have created government agencies to protect their society from web sites that officials view as immoral. Their views on what should be included in a .sex domain would hardly be identical to those in liberal western nations.
サウジアラビア、イラン、北ナイジェリア、および中国はたとえば、オランダかデンマークと同じ自由主義視点を持っていそうにはありません。 サウジアラビアと中国は、ある他の国のように手広く彼らのインターネット接続をフィルターにかけて、職員が不道徳であるとして見なすウェブサイトからそれらの社会を保護するために政府機関を創設しました。 .sexドメインに含まれるべきであることに関する彼らの意見は寛容な西国のそれらとほとんど同じでないでしょう。
Those wildly different opinions on sexual material make it inconceivable that a global consensus can ever be reached on what is appropriate or inappropriate for a .sex or .adult top-level domain. Moreover, the existence of such a domain would create an irresistible temptation on the part of conservative legislators to require controversial publishers to move to that domain and punish those who do not.
性的な物質的な造に関するそれらのむやみやたらに異なった意見、それ、思いもよらないaそんなにグローバルなコンセンサスは今までに、.sexか.adult最上位のドメインに、適切であるか、または不適当なことに達することができます。 そのうえ、そのようなドメインの存在は、保守的な立法者側の論議を呼んだ出版社がそのドメインに動いて、そうしないそれらを罰するのが必要であるように抗し難い誘惑を作成するでしょう。
Eastlake 3rd Informational [Page 4] RFC 3675 .sex Considered Dangerous February 2004
イーストレーク3番目に情報[4ページ]のRFC3675.sexは、危険な2月が2004であると考えました。
Some conservative politicians already have complained that ICANN did not approve .xxx in its October 2000 meeting. During a February 2001 hearing in the U.S. House of Representatives, legislators warned that they "want to explore ICANN's rationale for not approving two particular top level domain names -- .kids and .xxx -- as a means to protect kids from the awful smut which is so widespread on the Internet".
保守的な政治家の中にはICANNが2000年10月のミーティングで.xxxを承認しなかったと既に不平を言った人もいました。 米下院の2001年2月の公聴会の間、立法者は、彼らが「インターネットでとても広範囲のひどい猥褻本から子供を保護する手段として2つの特定の最上位ドメイン名(.kidsと.xxx)を承認しないようにICANNの原理を探りたがっている」と警告しました。
It seems plausible that only a few adult publishers, and not those who have invested resources in building a brand around a .com site, would voluntarily abandon their current domain name. Instead, they'd likely add a .xxx variant and keep their original address. The existence of .xxx could propel legislators in the U.S. and other countries to require them to publish exclusively from an adult domain, a move that would invite ongoing political interference with Internet governance, and raise concerns about forced speech and self-labeling.
.comサイトの周りでブランドを築き上げながらリソースを投資した人ではなく、ほんのいくつかのアダルト出版社が自発的にそれらの現在のドメイン名を捨てるだろうというのはもっともらしく思えます。 代わりに、彼らは、おそらく.xxx異形を加えて、自分達のオリジナルのアドレスを保管するでしょう。 .xxxの存在はアダルトドメイン、インターネット支配で進行中の政治的干渉を招待して、無理矢理のスピーチと自己ラベリングに関して関心を高める移動から排他的に発行するのが必要である米国と他国で立法者を推進するかもしれません。
In fact, the ultimate arbiter of generic top-level domain names -- at least currently -- is not ICANN, but the U.S. government. The U.S. Congress' General Accounting Office in July 2000 reported that the Commerce Department continues to be responsible for domain names allowed by the authoritative root [GAO]. The GAO's auditors concluded it was unclear whether the Commerce Department has the "requisite authority" under current law to transfer that responsibility to ICANN.
事実上、ジェネリック・トップ・レベル・ドメイン名の少なくとも現在究極の仲裁者はICANNではなく、米国政府です。 米国議会の会計検査院は、2000年7月に商務省はずっと正式の根[GAO]によって許容されたドメイン名に責任があると報告しました。 GAOの監査役は、商務省にはその責任をICANNに移す現行法の下における「必要な権威」があるかどうかが、不明瞭であると結論づけました。
The American Civil Liberties Union -- and other members of the international Global Internet Liberty Campaign -- caution that publishers speaking frankly about birth control, AIDS prevention, gay and lesbian sex, the social problem of prison rape, etc., could be coerced into moving to an adult domain. Once there, they would be stigmatized and easily blocked by schools, libraries, companies, and other groups using filtering software. Publishers of such information, who do not view themselves as pornographers and retain their existing addresses, could be targeted for prosecution.
国際的なGlobalインターネットリバティCampaignの米国自由人権協会の、そして、他のメンバー--率直に産児制限について話す出版社、エイズ予防、同性愛者の、そして、レスビアンのセックス、刑務所レイプの社会問題などをアダルトドメインに動くのに強制できたと警告してください。 いったんそこであると、それらは、汚名をきせられて、学校、ライブラリ、会社、および他のグループによってフィルタリングソフトウェアを使用することで容易に妨げられるでしょう。 そのような情報の出版社(自分たちをポルノ作家であるとみなして、彼らの既存のアドレスを保有しない)は起訴のために狙うことができました。
The existence of an adult top-level domain would likely open the door for related efforts, either policy or legislative. There are many different axes through which offensive material can be defined: Sex, violence, hate, heresy, subversion, blasphemy, illegal drugs, profanity, political correctness, glorification of crime, incitement to break the law, and so on. Such suggestions invite the ongoing lobbying of ICANN, the U.S. government, and other policy-making bodies by special-interest groups that are not concerned with the technical feasibility or practicality of their advice.
アダルト最上位のドメインの存在はどちらかの方針の、または、立法上の関連する努力のためにおそらくドアを開けるでしょう。 攻撃用の材料を定義できる多くの異なった軸があります: セックス、暴力、憎しみ、異端、転覆、冒とく、違法薬物、冒涜、ポリティカル・コレクトネス、犯罪の称賛、法を犯す煽動など。 そのような提案はICANNの進行中の運動、米国政府、および彼らのアドバイスの技術的な実行可能性か実用性に関しない利益団体による他の政策決定機関を招待します。
Eastlake 3rd Informational [Page 5] RFC 3675 .sex Considered Dangerous February 2004
イーストレーク3番目に情報[5ページ]のRFC3675.sexは、危険な2月が2004であると考えました。
An adult top-level domain could have negative legal repercussions by endangering free expression. U.S. Supreme Court Justice Sandra Day O'Connor has suggested that the presence of "adult zones" on the Internet would make a future Communications Decency Act (CDA) more likely to be viewed as constitutional. In her partial dissent to the Supreme Court's rejection of the CDA in 1997 [CDA], O'Connor said that "the prospects for the eventual zoning of the Internet appear promising". (The Supreme Court ruled that the CDA violated free speech rights by making it a crime to distribute "indecent" or "patently offensive" material online.)
アダルト最上位のドメインには、否定的法的な跳ね返りが、表現の自由を危険にさらすことによって、あるかもしれません。 米国最高裁判所の司法のサンドラ・デー・オコナーは、インターネットの「アダルトゾーン」の存在が将来の通信わいせつ物取り締まり法(CDA)を本質的であるとして、より見なされそうにすると示唆しました。 1997年[CDA]の最高裁判所のCDAの拒絶への彼女の部分的な異議で、「インターネットの最後の帯状になることの見通しは有望に見えます。」と、オコナーは言いました。 (最高裁判所は、オンラインで「無作法である」か「見え透いて不快な」材料を分配するためにそれを犯罪にすることによってCDAが言論の自由の権利に違反したと裁決しました。)
Privacy could be harmed by such a proposal. It would become easier for repressive governments and other institutions to track visits to sites in a domain labeled as adult and record personally-identifiable information about the visitor. Repressive governments would instantly have more power to monitor naive users and prosecute them for their activities. It's also implausible that a top-level domain would be effective in controlling access to chat, email, newsgroups, instant messaging, and new services as yet to be invented.
そのような提案でプライバシーに害を及ぼすことができるでしょう。 圧制的な政府と他の団体がアダルトであるとラベルされたドメインのサイトへの訪問を追跡して、訪問者に関する個人情報を記録するのは、より簡単になるでしょう。 圧制的な政府には、ナイーブなユーザをモニターして、彼らの活動で彼らを起訴するより多くのパワーが即座にあるでしょう。 また、最上位のドメインがまだ発明されるためにチャット、メール、ニュースグループ、インスタントメッセージング、および新種業務へのアクセスを制御しているのにおいて有効であるのも、信じがたいです。
4. Technical Difficulties
4. 技術的困難
Even ignoring the philosophical and legal difficulties outlined above, there are substantial technical difficulties in attempting to impose content classification by domain names or IP addresses. Mandatory content labeling is usually advanced with the idea of using a top level domain name, discussed in section 4.1., but we also discuss the possibility of using IP address bits or ranges in section 4.2.
上に概説された哲学的で法的な困難を無視さえして、ドメイン名かIPアドレスで満足している分類を課すのを試みることにおけるかなりの技術的困難があります。 義務的な満足しているラベリングはセクション4.1.で議論した最上位ドメイン名を使用するという考えで通常進められますが、また、私たちはセクション4.2でIPアドレスビットか範囲を使用する可能性について議論します。
In section 4.1.4., difficulties with a few particular higher level protocols are discussed. In some cases, these protocols use different name spaces. It should be kept in mind that additional future protocols may be devised with as yet undreamed of naming characteristics.
セクション4.1.4では、いくつかの特定の、より高い平らなプロトコルにおける困難について議論します。 いくつかの場合、これらのプロトコルは異なった名前空間を使用します。 追加将来のプロトコルがまだ特性を命名するのについて非夢想されていることで工夫されるかもしれないのが覚えておかれるべきです。
We also discuss PICS labels [PICS] as an alternative technology in section 4.3.
また、私たちは代替の技術としてセクション4.3でPICSラベル[PICS]について議論します。
Only a limited technical background is assumed, so some basic information is included below. In some cases, descriptions are simplified and details omitted.
限られた技術的なバックグラウンドだけが想定されるので、何らかの基本情報が以下に含まれています。 いくつかの場合、記述は簡易型であり、詳細は省略されています。
This technical discussion minimizes the definitional problems. However, it is still necessary for evaluating some technical considerations to have some estimate of the amount of categorization that would be necessary for a realistic global censorship system. There is no hope of agreement on this point. For our purposes, we
この技術面の協議はdefinitional問題を最小にします。しかしながら、現実的なグローバルな検定制度に必要な分類の量の何らかの見積りを持つのがまだいくつかの技術的な問題を評価するのに必要です。 このポイントの上に協定の望みが全くありません。 私たちの目的のために私たち
Eastlake 3rd Informational [Page 6] RFC 3675 .sex Considered Dangerous February 2004
イーストレーク3番目に情報[6ページ]のRFC3675.sexは、危険な2月が2004であると考えました。
will arbitrarily assume that the world's population consists of approximately 90,000 overlapping communities, each of which would have a different categorization of interest. Further, we arbitrarily assume that some unspecified but clever encoding scheme enables a proper global categorization of all information by a 300 bit label. Some would say a 300 bit label is too large, others that it is too small. Regardless, we will use it for some technical evaluations.
任意に、世界の人口がおよそ9万の重なっている共同体から成ると仮定するでしょう。それはそれぞれ興味がある異なった分類を持っているでしょう。 さらに、私たちは、何らかの不特定の、しかし、賢明なコード化計画が300ビットのラベルですべての情報の適切なグローバルな分類を可能にすると任意に思います。 何かが大きいでしょう、たとえば、それは他のものですが、300ビットのラベルはあまりに小さく大き過ぎます。 不注意に、私たちはいくつかの技術的評価にそれを使用するつもりです。
4.1. Content Filtering Using Names
4.1. 名前を使用するコンテントのフィルタリング
The most prominent user visible part of Internet naming and addressing is the domain name system [RFC 1034, 1035]. Domain Names are dotted sequences of labels, such as aol.com, world.std.com, www.rosslynchapel.org.uk, or ftp.gnu.lcs.mit.edu [RFC 1035, 1591, 2606]. Domain Names form an important part of most World Wide Web addresses or URLs [RFC 2396], commonly appearing after "//". Security for the domain name system is being standardized [RFC 2535], but has not been deployed to any significant extent.
インターネット命名とアドレシングの最も際立ったユーザ目に見える部分はドメイン名システム[RFC1034、1035]です。 ドメインNamesはaol.com、world.std.com、www.rosslynchapel.org.uk、またはftp.gnu.lcs.mit.eduなどのラベル[RFC1035、1591、2606]の点を打たされた系列です。 「」 //の後に一般的に現れて、ドメインNamesはほとんどのWWWアドレスかURL[RFC2396]の重要な部分を形成します。」 ドメイン名システムのためのセキュリティは、標準化されていますが[RFC2535]、どんな重要な程度まで配備されていません。
Domain names designate nodes in a globally distributed hierarchically delegated database. A wide variety of information can be stored at these nodes, including IP addresses of machines on the network (see section 4.2. below), mail delivery information, and other types of information. Thus, the data stored at foo.example.com could be the numeric information for sending data to a particular machine, which would be used if you tried to browse <http://foo.example.com>, the name of a computer (say mailhost.example.com) to handle mail addressed to anyone "@foo.example.com", and/or other information.
ドメイン名はグローバルに分配された階層的に代表として派遣されたデータベースのノードを指定します。 これらのノードにさまざまな情報を格納できます、ネットワーク(下のセクション4.2を見ます)(郵便配達情報、および他のタイプの情報)のマシンのIPアドレスを含んでいて 「その結果、foo.example.comに格納されたデータがあなたが<http://foo.example.com>をブラウズしようとするなら使用される特定のマシンにデータを送るための数値情報であるかもしれない、メールを扱うコンピュータ(mailhost.example.comを言う)の名前は」 @foo.example.comをだれにも記述した」、そして/または、他の情報。
There are also other naming systems in use, such as news group names and Internet Relay Chat (IRC) channel names.
また、ニュース・グループ名やインターネットRelay Chat(IRC)チャンネル名のように使用中の他の命名システムがあります。
The usual labeling idea presented is to reserve a top level name, such as .sex or .xxx for "adult" material and/or .kids for "safe" material or the like. The technical and linguistic problems with this are described in the subsections below.
提示された普通のラベリング考えは最高平らな名前を予約することです、「アダルトな」材料のための.sexか.xxx、そして/または、「安全な」材料か同様のもののための.kidsのように。 これに関する技術的で言語学の問題は以下の小区分で説明されます。
4.1.1. Linguistic Problems
4.1.1. 言語学の問題
When using name labeling, the first problem is from whose language do you take the names to impose? Words and acronyms can have very different meanings in different languages and the probability of confusion is multiplied when phonetic collisions are considered.
名前ラベリングを使用して、いつ第1の問題はだれの言語があなたをするかからでしゃばるために名前を取ることですか? ワーズと頭文字語は異なった言語の非常に異なった意味を持つことができます、そして、音声の衝突が考えられるとき、混乱の確率は掛けられます。
As an example of possible problems, note that for several years the government of Turkmenistan suspended new registrations in ".tm", which had previously been a source of revenue, because some of the
起こりうる問題に関する例として、数年間トルクメニスタンの政府が以前に財源であった".tm"で新しい登録証明書を中断させたことに注意してください、いくつか
Eastlake 3rd Informational [Page 7] RFC 3675 .sex Considered Dangerous February 2004
イーストレーク3番目に情報[7ページ]のRFC3675.sexは、危険な2月が2004であると考えました。
registered second level domain names may have been problematic. In particular, their web home page at <http://www.nic.tm> said:
登録されたセカンドレベルドメイン名は問題が多かったかもしれません。 特に、<http://www.nic.tm>のそれらのウェブホームページは言いました:
Statement from the .TM NIC
.TM NICからの声明
"The response to the .TM registry has been overwhelming.
Thousands of names have been registered from all over the
world. Some of the names registered, however, may be legally
obscene in Turkmenistan, and as a result the .TM NIC registry
is reviewing its naming policy for future registrations. The
.TM NIC has suspended registrations until a new policy can be
implemented. We hope to be live again shortly."
「.TM登録への応答は圧倒的です。」 世界中から何千もの名前を登録してあります。 しかしながら、登録された名前のいくつかがトルクメニスタンで法的にみだらであるかもしれません、そして、その結果、.TM NIC登録は将来の登録証明書のための命名方針を見直しています。 .TM NICは登録証明書を新しい政策を実行できるまで中断させました。 「私たちは、まもなく再びライブであることを望んでいます。」
There are approximately 6,000 languages in use in the world today, although this is expected to decline to around 3,000 by the year 2100.
今日、使用中のおよそ6,000の言語が世界にあります、これが2100年までにおよそ3,000に減退すると予想されますが。
4.1.2. Explosion of Top Level Domain Names (TLDs)
4.1.2. 最上位ドメイン名の爆発(TLDs)
An important aspect of the design of the Domain Name System (DNS) is the hierarchical delegation of data maintenance. The DNS really only works, and has been able to scale over the five orders of magnitude it has grown since its initial deployment, due to this delegation.
ドメインネームシステム(DNS)のデザインの重要な一面はデータ保守の階層的な代表団です。 DNSは本当に働くだけであり、初期の展開以来それが育てている5桁の上比例できました、この代表団のため。
The first problem is that one would expect most computers or web sites to have a mix of material, only some of which should be specially classified. Using special top level domain names (TLDs) multiplies the number of DNS zones the site has to worry about. For example, assume the site has somehow already sorted its material into "kids", "normal", and "adult" piles. Without special TLD labels, it can store them under kids.example.net, adult.example.net, and other.example.net, for instance. This would require only the maintenance of the single example.net zone of database entries. With special TLD labeling, at least example.net (for normal stuff), example.net.sex, and example.net.kids would need to be maintained, which are in three separate zones, in different parts of the DNS tree, under three separate delegations.
第1の問題は人が、ほとんどのコンピュータかウェブサイトには材料のミックスがあると予想するだろうということです。特に、それの或るものだけが材料のために分類されるべきです。 特別な最上位ドメイン名(TLDs)を使用すると、サイトが心配しなければならないDNSゾーンの数は掛け算をします。 例えば、サイトがどうにか既に材料を「子供」、「正常で」、「アダルトな」山に分類したと仮定してください。 特別なTLDラベルがなければ、それは例えば、kids.example.net、adult.example.net、およびother.example.netの下にそれらを格納できます。 これはデータベースエントリーのただ一つのexample.netゾーンの維持だけを必要とするでしょう。 特別なTLDラベリングで、少なくともexample.net(通常のもののための)、example.net.sex、およびexample.net.kidsは、維持される必要があるでしょう(3つの別々のゾーンにあります)、DNS木の異なった部分で、3つ未満の別々の代表団。
As the number of categories expands, the number of category combinations explodes, and this quickly becomes completely unmanageable. If 300 bits worth of labeling is required, the system could, in theory, need 2**300 name categories, an impossibility. No individual site would need to use all categories and the category domain names would not all have to be top level names. But it would still be an unmanageable nightmare.
カテゴリの数が広がるのに従って、カテゴリ組み合わせの数は爆発します、そして、これは急速に完全に「非-処理しやす」になります。 ラベリングの価値が300ビット必要であるなら、システムは理論上2**300名前カテゴリ、不可能を必要としたかもしれません。 どんな個々のサイトも、カテゴリとカテゴリドメイン名がすべて、最高平らな名前になるように持っていないすべてを使用する必要がないでしょう。 しかし、それはまだ「非-処理しやす」悪夢でしょう。
Eastlake 3rd Informational [Page 8] RFC 3675 .sex Considered Dangerous February 2004
イーストレーク3番目に情報[8ページ]のRFC3675.sexは、危険な2月が2004であると考えました。
4.1.3. You Can't Control What Names Point At You!
4.1.3. あなたは、どんな名前があなたを指し示すかを制御できません!
Providers of data on the Internet cannot stop anyone from creating names pointing to their computer's IP address with misleading domain names.
インターネットに関するデータのプロバイダーによって、だれも紛らわしいドメイン名でそれらのコンピュータのIPアドレスを示す名前を作成できません。
The DNS system works as a database. It associates certain data, called resource records, or RRs, with domain names. In particular, it can associate IP address resource records with domain names. For example, when you browse a URL, most commonly a domain name within that URL is looked up in the DNS. The resulting address is then used to address the packets sent from your web browser or other software to the server or peer.
DNSシステムはデータベースとして動作します。 それはリソース記録、またはRRsと呼ばれるあるデータをドメイン名に関連づけます。 特に、それはIPアドレスリソース記録をドメイン名に関連づけることができます。 例えば、あなたがURLをブラウズすると、最も一般的に、そのURLの中のドメイン名はDNSで調べられます。 そして、結果として起こるアドレスは、あなたのウェブブラウザか他のソフトウェアからサーバか同輩に送られたパケットを記述するのに使用されます。
Remember what we said in Section 4.1.1. about hierarchical delegation? Control is delegated and anyone controlling a DNS zone of data, say example.com, can insert data at that name or any deeper name (except to the extent that they delegate some of the deeper namespace to yet others). So the controller of example.com can insert data so that purity.example.com has, associated with it, the same computer address, which is associated with www.obscene.example.sex. This directs any reference to purity.example.com to use the associated IP address which is the same as the www.obscene.example.sex web site. The manager of that hypothetical web site, who controls the obscene.example.xxx zone, has no control over the example.com DNS zone. They are technically incapable of causing it to conform to any ".sex" labeling law. In the alternative, someone could create a name conforming to an adult labeling requirement, such as foo.stuff.sex, that actually pointed to someone else's entirely unobjectionable site, perhaps for the purpose of polluting the labeling. See diagram below. Each "zone" could be hosted on a different set of physical computers.
私たちがセクション4.1で階層的な代表団に関して.1に言ったことを覚えていますか? コントロールは代表として派遣して、だれでもデータのDNSゾーンを制御して、example.comを言ってください、その名前かどんなより深い名前(より深い名前空間のいくつかをしかし、他のものへ代表として派遣するという範囲を除いた)でもデータを挿入できるということです。 それで、example.comのコントローラは、purity.example.comにはwww.obscene.example.sexに関連しているのと同じコンピュータアドレスがそれに関連づけられて、あるように、データを挿入できます。 これはwww.obscene.example.sexウェブサイトと同じ関連IPアドレスを使用するpurity.example.comのどんな参照も指示します。 その仮定しているウェブサイトのマネージャ(obscene.example.xxxゾーンを制御する)はexample.com DNSゾーンを管理しません。 彼らは、法をラベルしながら、それがどんな".sex"にも従うことを技術的に引き起こすことができません。 代替手段で、だれかが実際に他の誰かの完全に「非-好ましくな」なサイトを示したfoo.stuff.sexなどのアダルトラベリング要件に従う名前を作成できるでしょう、恐らくラベリングを汚染する目的のために。 以下のダイヤグラムを見てください。 異なったセットの物理的なコンピュータで各「ゾーン」を接待できました。
Eastlake 3rd Informational [Page 9] RFC 3675 .sex Considered Dangerous February 2004
イーストレーク3番目に情報[9ページ]のRFC3675.sexは、危険な2月が2004であると考えました。
+-----------------------------------------+
| . (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
+-----------------+ +------------------+
| Virtuous Data | | Salacious Data |
+-----------------+ +------------------+
+-----------------------------------------+ | . (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 +-----------------+ +------------------+ | Virtuous Data | | Salacious Data | +-----------------+ +------------------+
4.1.4. Particular Protocol Difficulties
4.1.4. Particular Protocol Difficulties
There are additional considerations related to particular protocols. We consider only a few here. The first two, electronic mail and the World Wide Web, use domain name addressing. The second two, net news and IRC, use different name spaces and illustrate further technical problems with name based labeling.
There are additional considerations related to particular protocols. We consider only a few here. The first two, electronic mail and the World Wide Web, use domain name addressing. The second two, net news and IRC, use different name spaces and illustrate further technical problems with name based labeling.
4.1.4.1. Electronic Mail (SMTP)
4.1.4.1. Electronic Mail (SMTP)
Standard Internet tools provide no way to stop users from putting arbitrary domain names inside email headers.
Standard Internet tools provide no way to stop users from putting arbitrary domain names inside email headers.
The standard Internet electronic mail protocol separates "envelope" information from content [RFC 2821, 2822]. The envelope information indicates where a message claims to have originated and to whom it should be delivered. The content has fields starting with labels like "From:" and "To:", but these content fields actually have no effect and can be arbitrarily forged using simple, normally available software, such a telnetting to the SMTP port on a mail server. Content fields are not compared with envelope fields. To require them to be the same would be like requiring that postal letters
The standard Internet electronic mail protocol separates "envelope" information from content [RFC 2821, 2822]. The envelope information indicates where a message claims to have originated and to whom it should be delivered. The content has fields starting with labels like "From:" and "To:", but these content fields actually have no effect and can be arbitrarily forged using simple, normally available software, such a telnetting to the SMTP port on a mail server. Content fields are not compared with envelope fields. To require them to be the same would be like requiring that postal letters
Eastlake 3rd Informational [Page 10] RFC 3675 .sex Considered Dangerous February 2004
Eastlake 3rd Informational [Page 10] RFC 3675 .sex Considered Dangerous February 2004
deposited in a mail box list that mail box as their return address and only allowing residence or business return addresses on mail picked up by the post office from that residence or business.
deposited in a mail box list that mail box as their return address and only allowing residence or business return addresses on mail picked up by the post office from that residence or business.
While different mail clients display envelope information and headers from the content of email differently, generally the principle content fields are given prominence. Thus, while not exactly the same as content labeling, it should be noted that it is trivial to send mail to anyone with arbitrary domain names in the email addresses appearing in the From and To headers, etc.
While different mail clients display envelope information and headers from the content of email differently, generally the principle content fields are given prominence. Thus, while not exactly the same as content labeling, it should be noted that it is trivial to send mail to anyone with arbitrary domain names in the email addresses appearing in the From and To headers, etc.
It is also easy up set up a host to forward mail to an email address or mailing list. Mail sent with normal mail tools to this forwarder will automatically have content headers reflecting the forwarder's name, but the forwarder will change the envelope information and cause the mail to be actually sent to the forwarding destination mail address.
It is also easy up set up a host to forward mail to an email address or mailing list. Mail sent with normal mail tools to this forwarder will automatically have content headers reflecting the forwarder's name, but the forwarder will change the envelope information and cause the mail to be actually sent to the forwarding destination mail address.
For example, (with names disguised) there is a social mailing list innocuous@foo.example.org, and someone set up a forwarder at cat-torturers@other.example. Mail sent to the forwarder is forwarded and appears on the innocuous mailing list but with a "To: cat- torturers@other.example" header in its body, instead of the usual "To: innocuous@foo.example.org" content header. Mail reader software then displays the cat-torturers header. Similar things can be done using the "bcc" or "blind courtesy copy" feature of Internet mail.
For example, (with names disguised) there is a social mailing list innocuous@foo.example.org, and someone set up a forwarder at cat-torturers@other.example. Mail sent to the forwarder is forwarded and appears on the innocuous mailing list but with a "To: cat- torturers@other.example" header in its body, instead of the usual "To: innocuous@foo.example.org" content header. Mail reader software then displays the cat-torturers header. Similar things can be done using the "bcc" or "blind courtesy copy" feature of Internet mail.
There is work proceeding on securing email; however, such efforts at present only allow you to verify whether or not a particular entity was the actual author of the mail. When providing authentication, they add yet a third type of "From" address to the envelope and content "From" addresses, but they do not relate to controlling or authenticating domain names in the content of the mail.
There is work proceeding on securing email; however, such efforts at present only allow you to verify whether or not a particular entity was the actual author of the mail. When providing authentication, they add yet a third type of "From" address to the envelope and content "From" addresses, but they do not relate to controlling or authenticating domain names in the content of the mail.
4.1.4.2. Web Access (HTTP)
4.1.4.2. Web Access (HTTP)
With modern web servers and browsers supporting HTTP 1.1 [RFC 2616], the domain name used to access the site is available. Thus, web sites with different domain names can be accessed even if they are on the same machine at the same IP address. This is a small plus for name-based labeling since different categories of information on the same computer can be set up to be accessed via different domain names. But for a computer with any reasonable variety of data, the explosion of trying to differently name all types of data would require an unmanageable number of names.
With modern web servers and browsers supporting HTTP 1.1 [RFC 2616], the domain name used to access the site is available. Thus, web sites with different domain names can be accessed even if they are on the same machine at the same IP address. This is a small plus for name-based labeling since different categories of information on the same computer can be set up to be accessed via different domain names. But for a computer with any reasonable variety of data, the explosion of trying to differently name all types of data would require an unmanageable number of names.
Eastlake 3rd Informational [Page 11] RFC 3675 .sex Considered Dangerous February 2004
Eastlake 3rd Informational [Page 11] RFC 3675 .sex Considered Dangerous February 2004
With earlier HTTP 1.0 [RFC 1945], when a web request was sent to a server machine, the original domain name used in the URI was not included.
With earlier HTTP 1.0 [RFC 1945], when a web request was sent to a server machine, the original domain name used in the URI was not included.
On the other hand, the web has automatic forwarding. Thus, when one tries to access data at a particular domain name, the server there can re-direct your browser, temporarily or permanently, to a different name, or it can re-direct you to a numeric IP address so as to by-pass name filtering.
On the other hand, the web has automatic forwarding. Thus, when one tries to access data at a particular domain name, the server there can re-direct your browser, temporarily or permanently, to a different name, or it can re-direct you to a numeric IP address so as to by-pass name filtering.
4.1.4.3. News (NNTP)
4.1.4.3. News (NNTP)
Net news [RFC 977, 2980] uses hierarchically structured newsgroup names that are similar in appearance to domain names, except that the most significant label is on the left and the least on the right, the opposite of domain names. However, while the names are structured hierarchically, there is no central control. Instead, news servers periodically connect to other news servers that have agreed to exchange messages with them and they update each other on messages only in those newsgroups in which they wish to exchange messages.
Net news [RFC 977, 2980] uses hierarchically structured newsgroup names that are similar in appearance to domain names, except that the most significant label is on the left and the least on the right, the opposite of domain names. However, while the names are structured hierarchically, there is no central control. Instead, news servers periodically connect to other news servers that have agreed to exchange messages with them and they update each other on messages only in those newsgroups in which they wish to exchange messages.
Although hierarchical zones in the domain name system are locally managed, they need to be reachable starting at the top level root servers which are in turn more or less controlled by ICANN and the US Department of Commerce. With no such central point or points in the net news world, any pair or larger set of news servers anywhere in the world can agree to exchange news messages under any news group names they like, including duplicates of those used elsewhere in the net, making central control or even influence virtually impossible. In fact, within some parts of the news group namespace on some servers, anyone can create new newsgroups with arbitrary names.
Although hierarchical zones in the domain name system are locally managed, they need to be reachable starting at the top level root servers which are in turn more or less controlled by ICANN and the US Department of Commerce. With no such central point or points in the net news world, any pair or larger set of news servers anywhere in the world can agree to exchange news messages under any news group names they like, including duplicates of those used elsewhere in the net, making central control or even influence virtually impossible. In fact, within some parts of the news group namespace on some servers, anyone can create new newsgroups with arbitrary names.
Even if news group names could be controlled, the contents of the messages are determined by posters. While some groups are moderated, most are not. "Cancel" messages can be sent out for news messages, but that mechanism is subject to abuse, so some servers are configured to ignore cancels. In any case, the message may have been distributed to a huge number of computers world wide before any cancel is sent out.
Even if news group names could be controlled, the contents of the messages are determined by posters. While some groups are moderated, most are not. "Cancel" messages can be sent out for news messages, but that mechanism is subject to abuse, so some servers are configured to ignore cancels. In any case, the message may have been distributed to a huge number of computers world wide before any cancel is sent out.
And of course, fitting 300 bits worth of labeling into news group names is just as impossible as it is to fit into domain names.
And of course, fitting 300 bits worth of labeling into news group names is just as impossible as it is to fit into domain names.
Eastlake 3rd Informational [Page 12] RFC 3675 .sex Considered Dangerous February 2004
Eastlake 3rd Informational [Page 12] RFC 3675 .sex Considered Dangerous February 2004
4.1.4.4. Internet Relay Chat (IRC)
4.1.4.4. Internet Relay Chat (IRC)
Internet Relay Chat [RFC 2810-2813] is another example of a service which uses a different name space. It uses a single level space of "channel names" that are meaningful within a particular network of IRC servers. Because it is not hierarchical, each server must know about all names, which limits the size of a network of servers.
Internet Relay Chat [RFC 2810-2813] is another example of a service which uses a different name space. It uses a single level space of "channel names" that are meaningful within a particular network of IRC servers. Because it is not hierarchical, each server must know about all names, which limits the size of a network of servers.
As with newsgroup names, the fact that IRC channel names are local decisions, not subject to or reachable from any global "root", makes centralized political control virtually impossible.
As with newsgroup names, the fact that IRC channel names are local decisions, not subject to or reachable from any global "root", makes centralized political control virtually impossible.
4.2. Content Filtering Using IP Addressing
4.2. Content Filtering Using IP Addressing
A key characteristic of the Internet Protocol (IP) on which the Internet is based is that it breaks data up into "packets". These packets are individually handled and routed from source to destination. Each packet carries a numeric address for the destination point to which the Internet will try to deliver the packet.
A key characteristic of the Internet Protocol (IP) on which the Internet is based is that it breaks data up into "packets". These packets are individually handled and routed from source to destination. Each packet carries a numeric address for the destination point to which the Internet will try to deliver the packet.
(End users do not normally see these numeric addresses but instead deal with "domain names" as described in section 4.1. above.)
(End users do not normally see these numeric addresses but instead deal with "domain names" as described in section 4.1. above.)
The predominant numeric address system now in use is called IPv4, or Internet Protocol Version 4, which provides for 32 bit addresses [RFC 791]. There is increasing migration to the newer IPv6 [RFC 2460], which provides for 128 bit addresses [RFC 2373, 2374].
The predominant numeric address system now in use is called IPv4, or Internet Protocol Version 4, which provides for 32 bit addresses [RFC 791]. There is increasing migration to the newer IPv6 [RFC 2460], which provides for 128 bit addresses [RFC 2373, 2374].
Packets can be modified maliciously in transit but the most common result of this is denial of service.
Packets can be modified maliciously in transit but the most common result of this is denial of service.
One problem in using addressing for content filtering is that this is a very coarse technique. IP addresses refer to network interfaces, which usually correspond to entire computer systems which could house multiple web pages, sets of files, etc., only a small part of which it was desired to block or enable. Increasingly, a single IP address may correspond to a NAT (Network Address Translation) box [RFC 2663] which hides multiple computers behind it, although in that case, these computers are usually not servers.
One problem in using addressing for content filtering is that this is a very coarse technique. IP addresses refer to network interfaces, which usually correspond to entire computer systems which could house multiple web pages, sets of files, etc., only a small part of which it was desired to block or enable. Increasingly, a single IP address may correspond to a NAT (Network Address Translation) box [RFC 2663] which hides multiple computers behind it, although in that case, these computers are usually not servers.
However, even beyond this problem of coarse granularity, the practical constraints of hierarchical routing make the allocation of even a single IPv4 address bit or a significant number of IPv6 address bits impossible.
However, even beyond this problem of coarse granularity, the practical constraints of hierarchical routing make the allocation of even a single IPv4 address bit or a significant number of IPv6 address bits impossible.
Eastlake 3rd Informational [Page 13] RFC 3675 .sex Considered Dangerous February 2004
Eastlake 3rd Informational [Page 13] RFC 3675 .sex Considered Dangerous February 2004
4.2.1. Hierarchical Routing
4.2.1. Hierarchical Routing
IP addresses are technically inappropriate for content filtering because their assignment is intimately tied to network routing and topology.
IP addresses are technically inappropriate for content filtering because their assignment is intimately tied to network routing and topology.
As packets of data flow through the Internet, decisions must be made as to how to forward them "towards" their destination. This is done by comparing the initial bits of the packet destination address to entries in a "routing table" and forwarding the packets as indicated by the table entry with the longest prefix match.
As packets of data flow through the Internet, decisions must be made as to how to forward them "towards" their destination. This is done by comparing the initial bits of the packet destination address to entries in a "routing table" and forwarding the packets as indicated by the table entry with the longest prefix match.
While the Internet is actually a mesh, if, for simplicity, we consider it to have a central backbone at the "top", a packet is typically routed as follows:
While the Internet is actually a mesh, if, for simplicity, we consider it to have a central backbone at the "top", a packet is typically routed as follows:
The local networking code looks at its routing table to determine if the packet should be sent directly to another computer on the "local" network, to a router to specially forward it to another nearby network, or routed "up" to a "default" router to forward it to a higher level service provider's network. If the packet's destination is "far enough away", it will eventually get forwarded up to a router on the backbone. Such a router cannot send the packet "up" since it is at the top, or "default free" zone, and must have a complete table of other top level routers in which to send the packet. Currently, such top level routers are very large and expensive devices. They must be able to maintain tables of tens of thousands of routes. When the packet gets to the top level router of the part of the network within which its destination lies, it gets forwarded "down" to successive routers which are more and more specific and local until eventually it gets to a router on the local network where its destination address lies. This local router sends the packet directly to the destination computer.
The local networking code looks at its routing table to determine if the packet should be sent directly to another computer on the "local" network, to a router to specially forward it to another nearby network, or routed "up" to a "default" router to forward it to a higher level service provider's network. If the packet's destination is "far enough away", it will eventually get forwarded up to a router on the backbone. Such a router cannot send the packet "up" since it is at the top, or "default free" zone, and must have a complete table of other top level routers in which to send the packet. Currently, such top level routers are very large and expensive devices. They must be able to maintain tables of tens of thousands of routes. When the packet gets to the top level router of the part of the network within which its destination lies, it gets forwarded "down" to successive routers which are more and more specific and local until eventually it gets to a router on the local network where its destination address lies. This local router sends the packet directly to the destination computer.
Because all of these routing decisions are made on a longest prefix match basis, it can be seen that IP addresses are not general names or labels, but are critically and intimately associated with the actual topology and routing structure of the network. If they were assigned at random, routers would be required to remember so many specific routes for specific addresses that it would far exceed the current technical capabilities for router design. The Internet would be fatally disrupted and would not work.
Because all of these routing decisions are made on a longest prefix match basis, it can be seen that IP addresses are not general names or labels, but are critically and intimately associated with the actual topology and routing structure of the network. If they were assigned at random, routers would be required to remember so many specific routes for specific addresses that it would far exceed the current technical capabilities for router design. The Internet would be fatally disrupted and would not work.
It should also be noted that there is some inefficiency in allocation at each level of hierarchy [RFC 1715]. Generally, allocations are of a power of two addresses and as requirements grow and/or shrink, it is not practical to use every address.
It should also be noted that there is some inefficiency in allocation at each level of hierarchy [RFC 1715]. Generally, allocations are of a power of two addresses and as requirements grow and/or shrink, it is not practical to use every address.
Eastlake 3rd Informational [Page 14] RFC 3675 .sex Considered Dangerous February 2004
Eastlake 3rd Informational [Page 14] RFC 3675 .sex Considered Dangerous February 2004
(The above simplified description ignores multi-homing and many other details.)
(The above simplified description ignores multi-homing and many other details.)
4.2.2. IP Version 4 Addresses
4.2.2. IP Version 4 Addresses
There just isn't any practical way to reallocate even one bit of IPv4 global Internet Addresses for content filtering use. Such addresses are in short supply. Such an allocation would, in effect, cut the number of available addresses in half. There just aren't enough addresses, even without the inefficiency of hierarchical allocation [RFC 1715] and routing, to do this. Even if there were, current numbers have not been allocated with this in mind so that renumbering by every organization with hosts on the Internet would be required, a Herculean task costing in the billions of dollars.
There just isn't any practical way to reallocate even one bit of IPv4 global Internet Addresses for content filtering use. Such addresses are in short supply. Such an allocation would, in effect, cut the number of available addresses in half. There just aren't enough addresses, even without the inefficiency of hierarchical allocation [RFC 1715] and routing, to do this. Even if there were, current numbers have not been allocated with this in mind so that renumbering by every organization with hosts on the Internet would be required, a Herculean task costing in the billions of dollars.
Even if these problems were overcome, the allocation of even a single bit near the top of the address bits would likely double the number of routes in the default free zone. This would exceed the capacity of current routers and require the upgrade of thousands of them to new routers that do not exist yet at a gargantuan cost. The allocation of a bit near the bottom of the address bits would require world-wide local reconfiguration which would be impractical to require or enforce, even if the bit were available.
Even if these problems were overcome, the allocation of even a single bit near the top of the address bits would likely double the number of routes in the default free zone. This would exceed the capacity of current routers and require the upgrade of thousands of them to new routers that do not exist yet at a gargantuan cost. The allocation of a bit near the bottom of the address bits would require world-wide local reconfiguration which would be impractical to require or enforce, even if the bit were available.
And all this is if only a single bit is allocated to content labeling, let alone more than one. And we are assuming you would actually need 300 bits, more than there are!
And all this is if only a single bit is allocated to content labeling, let alone more than one. And we are assuming you would actually need 300 bits, more than there are!
Basically, the idea is a non-starter.
Basically, the idea is a non-starter.
4.2.3. IP Version 6 Addresses
4.2.3. IP Version 6 Addresses
IPv6 provides 128 bit address fields [RFC 2373, 2374]. Furthermore, allocation of IPv6 addresses is in its infancy. Thus, the allocation of say, one bit of IPv6 address for labeling is conceivable.
IPv6 provides 128 bit address fields [RFC 2373, 2374]. Furthermore, allocation of IPv6 addresses is in its infancy. Thus, the allocation of say, one bit of IPv6 address for labeling is conceivable.
However, as discussed above (section 4.2.1.), every high bit allocated for labeling doubles the cost imposed on the routing system. Allocating one bit would generally double the size of routing tables.
However, as discussed above (section 4.2.1.), every high bit allocated for labeling doubles the cost imposed on the routing system. Allocating one bit would generally double the size of routing tables.
Allocating two bits would multiply them by four. Allocating the 300 bits we assume necessary for realistic world wide labeling is logically impossible for IPv6, 300 being a lot larger than 128, and if it were, would result in technically unachievable routing table sizes. Even allocating, say, 20 bits, if that were possible, would impossibly multiply table sizes by a million.
Allocating two bits would multiply them by four. Allocating the 300 bits we assume necessary for realistic world wide labeling is logically impossible for IPv6, 300 being a lot larger than 128, and if it were, would result in technically unachievable routing table sizes. Even allocating, say, 20 bits, if that were possible, would impossibly multiply table sizes by a million.
Eastlake 3rd Informational [Page 15] RFC 3675 .sex Considered Dangerous February 2004
Eastlake 3rd Informational [Page 15] RFC 3675 .sex Considered Dangerous February 2004
Allocating low bits also has problems. There are technical proposals that use the bottom 64 bits in a manner incompatible with their use for labels [RFC 2374]. So it would probably have to be "middle bits" (actually low bits of the upper half). As with IPv4, it would be impossible to enforce this world wide. If it were possible, one or two bits could be allocated there, which would be clearly inadequate.
Allocating low bits also has problems. There are technical proposals that use the bottom 64 bits in a manner incompatible with their use for labels [RFC 2374]. So it would probably have to be "middle bits" (actually low bits of the upper half). As with IPv4, it would be impossible to enforce this world wide. If it were possible, one or two bits could be allocated there, which would be clearly inadequate.
4.3. PICS Labels
4.3. PICS Labels
PICS Labels (Platform for Internet Content Selection) is a generalized system for providing "ratings" for Internet accessible material. The PICS documents [PICS] should be consulted for details. In general, PICS assumes an arbitrarily large number of rating services and rating systems. Each service and system is identified by a URL.
PICS Labels (Platform for Internet Content Selection) is a generalized system for providing "ratings" for Internet accessible material. The PICS documents [PICS] should be consulted for details. In general, PICS assumes an arbitrarily large number of rating services and rating systems. Each service and system is identified by a URL.
It would be quite reasonable to have multiple PICS services that, in the aggregate, provided 300 bits of label information or more. There could be a PICS service for every community of interest. This sort of technology is really the only reasonable way to make categorizations or labelings of material available in a diverse and dynamic world.
It would be quite reasonable to have multiple PICS services that, in the aggregate, provided 300 bits of label information or more. There could be a PICS service for every community of interest. This sort of technology is really the only reasonable way to make categorizations or labelings of material available in a diverse and dynamic world.
While such PICS label services could be used to distribute government promulgated censorship categories, for example, it is not clear how this is any worse than government censorship via national firewalls.
While such PICS label services could be used to distribute government promulgated censorship categories, for example, it is not clear how this is any worse than government censorship via national firewalls.
A PICS rating system is essentially a definition of one or more dimensions and the numeric range of the values that can be assigned in each dimension to a rated object. A service is a source of labels where a label includes actual ratings. Ratings are either specific or generic. A specific rating applies only to the material at a particular URL [RFC 2396] and does not cover anything referenced from it, even included image files. A generic rating applies to the specified URL and to all URLs for which the stated URL is a prefix.
A PICS rating system is essentially a definition of one or more dimensions and the numeric range of the values that can be assigned in each dimension to a rated object. A service is a source of labels where a label includes actual ratings. Ratings are either specific or generic. A specific rating applies only to the material at a particular URL [RFC 2396] and does not cover anything referenced from it, even included image files. A generic rating applies to the specified URL and to all URLs for which the stated URL is a prefix.
A simplified example label might look like the following:
A simplified example label might look like the following:
(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))
(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))
Machine readable rating system descriptions include the range of values and set of dimensions provided. Additional information, such as beginning and ending time of validity, can be incorporated into labels.
Machine readable rating system descriptions include the range of values and set of dimensions provided. Additional information, such as beginning and ending time of validity, can be incorporated into labels.
Eastlake 3rd Informational [Page 16] RFC 3675 .sex Considered Dangerous February 2004
Eastlake 3rd Informational [Page 16] RFC 3675 .sex Considered Dangerous February 2004
Labels can currently be made available in three ways: (1) embedded in HTML, (2) provided with data in an HTTP response, and (3) separately from a third party. If content is required to have labels embedded in it or transmitted by the source when data is returned, as in the first two ways listed above, it raises the problems of categorization granularity and forced speech. However, if used in the third way whereby a separate party determines and provides labels for content, and users are free to select whatever such third party or parties they wish to consult, it can support a myriad of categories, editors, and evaluators to exist in parallel.
Labels can currently be made available in three ways: (1) embedded in HTML, (2) provided with data in an HTTP response, and (3) separately from a third party. If content is required to have labels embedded in it or transmitted by the source when data is returned, as in the first two ways listed above, it raises the problems of categorization granularity and forced speech. However, if used in the third way whereby a separate party determines and provides labels for content, and users are free to select whatever such third party or parties they wish to consult, it can support a myriad of categories, editors, and evaluators to exist in parallel.
Digital signatures are available to secure PICS Labels [PICS].
Digital signatures are available to secure PICS Labels [PICS].
5. Security Considerations
5. Security Considerations
Any labeling or categorization scheme must assume that there will be deliberate attempts to cause data to be incorrectly labeled and incorrectly categorized. This might be due to some perceived advantage of particular labeling or merely to disrupt the system. After all, if sources would always accurately and conveniently label sent information, security would be much easier [RFC 3514]. Such enforceability considerations are discussed in conjunction with the various mechanisms mentioned in this document.
Any labeling or categorization scheme must assume that there will be deliberate attempts to cause data to be incorrectly labeled and incorrectly categorized. This might be due to some perceived advantage of particular labeling or merely to disrupt the system. After all, if sources would always accurately and conveniently label sent information, security would be much easier [RFC 3514]. Such enforceability considerations are discussed in conjunction with the various mechanisms mentioned in this document.
6. Conclusions
6. Conclusions
The concept that a single top level domain name, such as .sex, or a single IP address bit, could be allocated and become the mandatory home of "adult" or "offensive" material world wide is legal and technical nonsense.
The concept that a single top level domain name, such as .sex, or a single IP address bit, could be allocated and become the mandatory home of "adult" or "offensive" material world wide is legal and technical nonsense.
Global agreement on what sort of material should be in such a ghetto is impossible. In the world wide context, the use of a single category or small number of categories is absurd. The implementation of a reasonable size label that could encompass the criterion of the many communities of the world, such as 300 bits, is technically impossible at the domain name or IP address level and will remain so for the foreseeable future. Besides technical impossibility, such a mandate would be an illegal forcing of speech in some jurisdictions, as well as cause severe linguistic problems for domain or other character string names.
Global agreement on what sort of material should be in such a ghetto is impossible. In the world wide context, the use of a single category or small number of categories is absurd. The implementation of a reasonable size label that could encompass the criterion of the many communities of the world, such as 300 bits, is technically impossible at the domain name or IP address level and will remain so for the foreseeable future. Besides technical impossibility, such a mandate would be an illegal forcing of speech in some jurisdictions, as well as cause severe linguistic problems for domain or other character string names.
However, the concept of a plethora of independent reviewers, some of which might be governmental agencies, and the ability of those accessing information to select and utilize ratings assigned by such reviewers, is possible.
However, the concept of a plethora of independent reviewers, some of which might be governmental agencies, and the ability of those accessing information to select and utilize ratings assigned by such reviewers, is possible.
Eastlake 3rd Informational [Page 17] RFC 3675 .sex Considered Dangerous February 2004
Eastlake 3rd Informational [Page 17] RFC 3675 .sex Considered Dangerous February 2004
7. References
7. References
7.1. Normative References
7.1. Normative References
[PICS] Platform for Internet Content Selection PICS 1.1
Rating Services and Rating Systems -- and Their
Machine Readable Descriptions <http://www.w3.org/TR/
REC-PICS-services>, October 1996.
[PICS] Platform for Internet Content Selection PICS 1.1 Rating Services and Rating Systems -- and Their Machine Readable Descriptions <http://www.w3.org/TR/ REC-PICS-services>, October 1996.
PICS 1.1 Label Distribution -- Label Syntax and
Communication Protocols <http://www.w3.org/TR/REC-
PICS-labels>, October 1996.
PICS 1.1 Label Distribution -- Label Syntax and Communication Protocols <http://www.w3.org/TR/REC- PICS-labels>, October 1996.
PICSRules 1.1 Specification
<http://www.w3.org/TR/REC-PICSRules>, December 1997.
PICSRules 1.1 Specification <http://www.w3.org/TR/REC-PICSRules>, December 1997.
PICS Signed Labels (DSIG) 1.0 Specification
<http://www.w3.org/TR/REC-DSig-label/>, May 1998.
PICS Signed Labels (DSIG) 1.0 Specification <http://www.w3.org/TR/REC-DSig-label/>, May 1998.
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC 977] Kantor, B. and P. Lapsley, "Network News Transfer
Protocol", RFC 977, February 1986.
[RFC 977] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
[RFC 1591] Postel, J., "Domain Name System Structure and
Delegation", RFC 1591, March 1994.
[RFC 1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
[RFC 1945] Berners-Lee, T., Fielding, R. and H. Frystyk,
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
May 1996.
[RFC 1945] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC 2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC 2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[RFC 2374] Hinden, R., O'Dell, M. and S. Deering, "An IPv6
Aggregatable Global Unicast Address Format", RFC 2374,
July 1998.
[RFC 2374] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998.
[RFC 2616] 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.
[RFC 2616] 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.
Eastlake 3rd Informational [Page 18] RFC 3675 .sex Considered Dangerous February 2004
Eastlake 3rd Informational [Page 18] RFC 3675 .sex Considered Dangerous February 2004
[RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC 2810] Kalt, C., "Internet Relay Chat: Architecture", RFC
2810, April 2000.
[RFC 2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000.
[RFC 2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
2821, April 2001.
[RFC 2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC 2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
April 2001.
[RFC 2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC 2980] Barber, S., "Common NNTP Extensions", RFC 2980,
October 2000.
[RFC 2980] Barber, S., "Common NNTP Extensions", RFC 2980, October 2000.
7.2. Informative References
7.2. Informative References
[BT] "British Telecom comments to U.S. Commerce
Department", February 20, 1998,
<http://www.ntia.doc.gov/ntiahome/domainname/
130dftmail/BT.htm>
[BT] "British Telecom comments to U.S. Commerce Department", February 20, 1998, <http://www.ntia.doc.gov/ntiahome/domainname/ 130dftmail/BT.htm>
[CDA] "Reno v. American Civil Liberties Union", 117 S.Ct.
2329, June 26, 1997,
[CDA] "Reno v. American Civil Liberties Union", 117 S.Ct. 2329, June 26, 1997,
[COPAREPORT] "Final Report of the COPA Commission to the U.S.
Congress", October 20, 2000,
<http://www.copacommission.org/report/
newtopleveldomain.shtml>
[COPAREPORT] "Final Report of the COPA Commission to the U.S. Congress", October 20, 2000, <http://www.copacommission.org/report/ newtopleveldomain.shtml>
[GAO] "GAO Report OGC-00-33R", July 7, 2000,
<http://www.gao.gov/new.items/og00033r.pdf>
[GAO] "GAO Report OGC-00-33R", July 7, 2000, <http://www.gao.gov/new.items/og00033r.pdf>
[GTLD-MOU] "GTLD-MOU Policy Oversight committee RFC 97-02",
September 13, 1997,
<http://www.gtld-mou.org/docs/notice-97-02.html>
[GTLD-MOU] "GTLD-MOU Policy Oversight committee RFC 97-02", September 13, 1997, <http://www.gtld-mou.org/docs/notice-97-02.html>
[HOUSEREPORT] "U.S. House Commerce Committee report", 105th
Congress, October 5, 1998.
<http://www.epic.org/free_speech/censorship/
hr3783-report.html>
[HOUSEREPORT]「米国下院通商委員会のレポート」、第105会期、1998年10月5日。 <http://www.epic.org/自由な_スピーチ/検閲/hr3783-report.html>。
[ICM-REGISTRY] "Request for reconsideration from ICM Registry to
ICANN", December 15, 2000,
<http://www.icann.org/committees/reconsideration/
icm-request-16dec00.htm>
[ICM-REGISTRY]は2000年12月15日に<icm-要求http://www.icann.org/委員会/再考/16dec00.htm>を「再考のために、ICM RegistryからICANNまで要求します」。
Eastlake 3rd Informational [Page 19] RFC 3675 .sex Considered Dangerous February 2004
イーストレーク3番目に情報[19ページ]のRFC3675.sexは、危険な2月が2004であると考えました。
[LIEBERMAN] "Testimony of Senator Joe Lieberman before Children's
Online Protection Act Commission", June 8, 2000,
<http://www.senate.gov/~lieberman/press/00/06/
2000608958.html>
[リーバーマン] 「子供のオンライン保護条例委員会の前の上院議員のジョー・リーバーマンの証言」、2000年6月8日、<http://www.senate.gov/~lieberman/プレス/00/06/ 2000608958.html>。
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
Mockapetris、[RFC1034]P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC 1715] Huitema, C., "The H Ratio for Address Assignment
Efficiency", RFC 1715, November 1994.
[RFC1715] Huitema、C.、「アドレス課題効率のためのH比」、RFC1715、1994年11月。
[RFC 2396] Berners-Lee, T., Fielding, R. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic Syntax",
RFC 2396, August 1998.
[RFC2396] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、1998年8月。
[RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]のデアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC 2535] Eastlake, 3rd, D., "Domain Name System Security
Extensions", RFC 2535, March 1999.
[RFC2535] イーストレーク、3番目、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。
[RFC 2606] Eastlake, 3rd, D. and A. Panitz, "Reserved Top Level
DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606] イーストレークと3番目とD.とA.パニツ、「予約された最高平らなDNS名」、BCP32、RFC2606、1999年6月。
[RFC 2811] Kalt, C., "Internet Relay Chat: Channel Management",
RFC 2811, April 2000.
Kalt、[RFC2811]C.、「インターネットリレーチャット:」 「チャンネル管理」、RFC2811、2000年4月。
[RFC 2812] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
2812, April 2000.
Kalt、[RFC2812]C.、「インターネットリレーチャット:」 「クライアントプロトコル」、RFC2812、2000年4月。
[RFC 2813] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
2813, April 2000.
Kalt、[RFC2813]C.、「インターネットリレーチャット:」 「サーバプロトコル」、RFC2813、2000年4月。
[RFC 2854] Connelly, D. and L. Masinter, "The 'text/html' Media
Type", RFC 2854, June 2000.
[RFC2854] コネリーとD.とL.Masinter、htmlテキスト/'メディアタイプ」、RFC2854、2000年6月。
[RFC 3513] Hinden, R. and S. Deering, "Internet Protocol Version
6 (IPv6) Addressing Architecture", RFC 3513, April
2003.
[RFC3513] HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[RFC 3514] Bellovin, S., "The Security Flag in the IPv4 Header",
1 April 2003.
[RFC3514] Bellovin、S.、「IPv4ヘッダーのセキュリティ旗」、2003年4月1日。
[WARSHAVSKY] Congress weighs Net porn bills," CNET article,
February 10, 1998, <http://news.cnet.com/
news/0-1005-200-326435.html>
「[WARSHAVSKY]議会はネットポルノ請求書を熟慮する」CNET記事、1998年2月10日、<http://news.cnet.com/ニュース/0-1005-200-326435.html>。
Eastlake 3rd Informational [Page 20] RFC 3675 .sex Considered Dangerous February 2004
イーストレーク3番目に情報[20ページ]のRFC3675.sexは、危険な2月が2004であると考えました。
8. Acknowledgement
8. 承認
The contribution and efforts of Declan McCullagh, who wrote substantially all of sections 2 and 3 of this document, are gratefully acknowledged.
Declan McCullaghの貢献と努力は感謝して承諾されます。(Declan McCullaghは実質的にこのドキュメントのセクション2と3のすべてを書きました)。
9. Authors' Addresses
9. 作者のアドレス
Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレーク第3モトローラ研究所155ビーバー通りMA01757ミルフォード(米国)
Phone: +1-508-786-7554 (w)
+1-508-634-2066 (h)
EMail: dee3@torque.pothole.com
以下に電話をしてください。 +1-508-786-7554 (w) +1-508-634-2066 (h) メールしてください: dee3@torque.pothole.com
Eastlake 3rd Informational [Page 21] RFC 3675 .sex Considered Dangerous February 2004
イーストレーク3番目に情報[21ページ]のRFC3675.sexは、危険な2月が2004であると考えました。
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Eastlake 3rd Informational [Page 22]
イーストレーク、3番目に情報[22ページ]
一覧
スポンサーリンク
