Network Working Group D. Eastlake 3rd
Request for Comments: 3675 Motorola Laboratories
Category: Informational February 2004
.sex Considered Dangerous
Status of this 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.
著作権（C）インターネット協会（2004）。全著作権所有。
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
7.1. Normative References . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . 19
8. Acknowledgement. . . . . . . . . . . . . . . . . . . . . . . . 21
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22
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アドレスビットの使用を強制するために提案されています。これは、法的な哲学的、およびビューの技術的なポイントから病気と認めてアイデアですなぜこの文書では説明しています。
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月のレポートでは、ハウス商業委員会は、「大人のドメインを作成するための技術的な障壁が存在しない、大人のドメイン内のすべてのウェブサイトをブロックすることは非常に簡単だろう」と述べました。報告書はまた、委員会は、コンピュータ業界を規制するのを警戒したと米政府によるいかなる決定は[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年の手紙の中で言って、成人のトップレベルドメインを裏付けています。理由：[BT]を「性的に明示的なサービスは、合法的なサイトへのアクセスを制御するために、それははるかに簡単かつ容易になるだろう[こと]が...これのgTLDのドメイン名で動作するように要求される可能性があります」。 ICANNの前駆細胞の一つ、のgTLD-MOU委員会は、コメントのために1997年9月のリクエスト[のgTLD-MOU]に「赤信号ゾーン」トップレベルドメインを示唆しました。
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年には、セス・ワーシャスキー、インターネット・エンターテインメント・グループの社長は、彼が.adultドメインを見たいのですが、米国上院商務委員会に語りました。 「私たちは、ネット上のすべての性的に露骨な材料が存在するだろう 『.adult』と呼ばれる新しいトップレベルドメインの作成を示唆している、」Warshavskyは時間[WARSHAVSKY]のインタビューで語りました。
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.
米国での保守党グループは、彼らがそのようなドメインのために熱望していない、と性的 - 明示的な材料の出版社や代理店に向け刑法を好むと言います。フェアファックス、バージニア州の子どもと家族のための国内法センターは、それがどのような提案を支持しなかったことを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].
上院議員ジョセフ・リーバーマン、米国民主党の副大統領候補は、児童オンライン保護に関する連邦委員会の2000年6月の会議でアイデアを支持しました。リーバーマンは、[リーバーマン]「我々は単にX-定格映画館や性的-明示的な雑誌を販売しているコンビニエンスストアの所有者の所有者と同じ標準を遵守するために、インターネットのアービタを求めるだろう」というプリペアドステートメントの中で述べて。
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".
委員会はまた、IPv6の下で、IPアドレスの新しいセットの割り当てによってコンテンツのためのいわゆるレッドゾーンまたはグリーンゾーンの作成を検討しました。これら二つのゾーンのいずれかの任意の材料ではないがグレーゾーンと見、必ずしも適切な又は未成年者には不適切ではないであろう。 「それは、チャットへのアクセスを遮断するのに効果的ではないであろう。このアプローチは、潜在的な柔軟性を削減し、最適なネットワークパフォーマンスを妨げる可能性があり有効性は、特定の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会長エスター・ダイソンは、アダルト業界は完全なドメインが適切であろうことに同意しなかったことを言いました。一つ.XXX希望に満ちた、オンタリオ州、カナダのICMレジストリは、2000年12月にその決定[ICM-REGISTRY]を再考するICANNを尋ねました。
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ドメインが不適切だったと全世界の標準を制定しようとし、理由のために、そのうちのいくつかは、次のセクションで説明されていると確信された後でした。
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歳だが、1つのスカンジナビアの国における年齢のわずか17年。そこに法的および適切な写真撮影と見何行っカメラマンが宗教的であってもよいし、さらに他の国やグループではいかなる形でのヌード写真の全体のコンセプトや人のさえどんな撮影を米国の重罪と子のポルノグラファーをブランド化されるだろう容認できません。
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.
サウジアラビア、イラン、ナイジェリア北部、中国はオランダやデンマーク、たとえば、同じリベラルな見解を持っている可能性はありません。サウジアラビアと中国は、いくつかの他の国と同様に、広くそのインターネット接続をフィルタリングし、当局は不道徳として表示するには、Webサイトから自分たちの社会を守るために政府機関が作成されました。 .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.
性的な材料のものを乱暴に異なった意見は、グローバルなコンセンサスが今まで.sexまたは.adultトップレベルドメインのために適切か不適切であるものに到達することができるということが想像させます。また、そのようなドメインの存在は、そのドメインに移動し、そうでない人を罰するために論争の発行者を必要とする保守的な議員の一部に魅力的な誘惑を作成します。
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承認しなかったことを訴えています。ひどいスマットから子供を守るための手段として - .kidsと.XXX - 米下院で2001年2月審理中に、議員は、彼らが「2つの特定のトップレベルドメイン名を承認していないため、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.
アメリカ自由人権協会 - 及び国際グローバルインターネットリバティキャンペーンの他のメンバー - 出版社は避妊、エイズ予防、ゲイやレズビアンのセックスについて率直に話すことを注意、刑務所レイプなどの社会的な問題は、に強制することができ大人のドメインに移動します。一度そこに、彼らが汚名を着せられる、簡単フィルタリングソフトウェアを使用して、学校、図書館、企業、および他のグループによってブロックされています。ポルノとして自分自身を表示し、既存のアドレスを保持しないような情報の出版社は、起訴のために標的化され得ます。
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、米政府、およびその他の政策決定機関の継続的なロビー活動を招待します。
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.
プライバシーは、そのような提案によって悪影響を受ける可能性があります。それは大人と訪問者に関する記録個人を特定できる情報としてラベル付けされたドメイン内のサイトへの訪問を追跡するために、抑圧的な政府や他の機関のために容易になるでしょう。抑圧的な政府は即座にナイーブユーザーを監視し、その活動のためにそれらを起訴するより多くの電力を持っているでしょう。それはまだ発明されるようなトップレベルドメインは、チャットへのアクセスを制御し、電子メール、ニュースグループ、インスタントメッセージング、および新たなサービスに有効であろうということも信じ難いのです。
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において、いくつかの特定のより高いレベルのプロトコルに問題が議論されています。いくつかのケースでは、これらのプロトコルは、異なる名前空間を使用します。将来の追加のプロトコルが特性を命名するなど、まだundreamedを考案することができることを心に留めておくべきです。
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 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.
この技術的な議論には、定義上の問題を最小限に抑えることができます。しかし、それはまだ現実的な世界的な検閲システムのために必要となる分類の量のいくつかの見積もりを持っているいくつかの技術的配慮を評価するために必要です。この点について合意の見込みはありません。我々の目的のために、我々は、任意に、世界の人口は、関心の異なる分類を持つことになり、それぞれが約90,000重複コミュニティ、で構成されていると仮定します。さらに、我々は、任意にいくつかの不特定が、巧妙な符号化方式は、300ビットのラベルによって、すべての情報の適切なグローバルな分類を可能にすることを前提としています。いくつかは、それが小さすぎる他人ことを、300ビットのラベルが大きすぎると言うでしょう。かかわらず、我々はいくつかの技術的な評価のためにそれを使用します。
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.
インターネットのネーミングとアドレッシングの最も顕著なユーザー見える部分は、ドメインネームシステム[RFC 1034、1035]です。ドメイン名は、aol.com、world.std.com、www.rosslynchapel.org.uk、又はftp.gnu.lcs.mit.eduとしてラベル、[RFC 1035、1591、2606]の点線の配列です。ドメイン名は、一般に「//」の後に表示される、[RFC 2396]ほとんどのWorld Wide WebアドレスやURLの重要な部分を形成します。ドメインネームシステムのセキュリティは、[RFC 2535]標準化されているが、任意の有意な程度に展開されていません。
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.
ドメイン名はグローバルに分散階層的に委任したデータベース内のノードを指定します。情報の多種多様なネットワーク上のマシンのIPアドレス（セクション4.2を参照。以下）、メール配信情報、および他のタイプの情報を含め、これらのノードに格納することができます。このように、foo.example.comに格納されたデータは、あなたが閲覧しようとした場合に使用される特定のマシンにデータを送信するための数値情報である可能性があり、<http://foo.example.com>、コンピューターの名前、メールは「@ foo.example.com」誰宛および/または他の情報を処理するために（mailhost.example.com言います）。
There are also other naming systems in use, such as news group names and Internet Relay Chat (IRC) channel names.
そのようなニュースグループ名とインターネットリレーチャット（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.
提示通常のラベリングアイデアは、このような「安全な」材料等のための「大人」材料および/または.kidsため.sexまたは.XXXとして、トップレベルの名前を予約することです。これで技術的および言語的な問題は、以下のサブセクションで説明されています。
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.
名前のラベルを使用する場合は、最初の問題は、その言語あなたが課す名前を取るかからでしょうか？言葉と頭字語は、異なる言語では非常に異なる意味を持つことができ、発音の衝突を考慮した場合の混乱の確率が乗算されます。
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 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>で、自分のWebのホームページは言いました：
Statement from the .TM NIC
（商標）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."
「（商標）レジストリへの応答は、登録された名前のいくつかは、しかし、トルクメニスタンで合法的にわいせつなことがあります。名前の何千人もが世界中から登録されている。圧倒的であったが、結果として（商標）NICレジストリを検討しています将来の登録のためにその名前付けポリシー新しいポリシーを実装することが可能になるまで。（商標）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.
これは2100年で約3,000に減少すると予想されるが、およそ6,000の言語は、今日の世界での使用にあります。
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つが特別に分類されるべき唯一のいくつかは材料のミックスを、持っているほとんどのコンピュータやWebサイトを期待するだろうということです。特別なトップレベルドメイン名（TLDの）を使用すると、サイトが心配しているDNSゾーンの数を乗算します。たとえば、サイトが何らかの形で既に「子供」、「ノーマル」、および「大人」の山の中にその材料をソートしていると仮定します。特別なTLDラベルがなければ、それはkids.example.net、adult.example.netの下でそれらを保存することができ、そして例えば、other.example.net。これは、データベースエントリの単一example.netゾーンの唯一のメンテナンスを必要とします。特別なTLD標識、（通常のもののための）少なくともexample.net、example.net.sex、及びexample.net.kidsと下に、DNSツリーの異なる部分で、3つの別個のゾーン内である、維持する必要があります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名のカテゴリ、不可能を必要とすることができます。いいえ、個々のサイトでは、すべてがトップレベルの名前である必要はありませんすべてのカテゴリおよびカテゴリのドメイン名を使用する必要がないだろう。しかし、それはまだ手に負えない悪夢だろう。
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システムは、データベースとして機能します。これは、ドメイン名と、特定のリソースレコードと呼ばれるデータ、またはRRを関連付けます。特に、それは、ドメイン名とIPアドレスリソースレコードを関連付けることができます。あなたはURLを参照するときたとえば、最も一般的にそのURL内のドメイン名がDNSで検索されます。結果のアドレスは、サーバまたはピアにWebブラウザまたは他のソフトウェアから送信されるパケットに対処するために使用されます。
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と言います。 、それに関連付けられた、同じコンピュータアドレス、www.obscene.example.sexに関連付けられたpurity.example.comようので、example.comのコントローラは、データを挿入することができます。これは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
+-----------------+ +------------------+
| Virtuous Data | | Salacious Data |
+-----------------+ +------------------+
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.
特定のプロトコルに関連する追加の考慮事項があります。ここではほんの数を考慮してください。最初の2、電子メール、ワールド・ワイド・ウェブは、アドレス指定のドメイン名を使用します。第二の二、ネットニュースやIRCは、異なる名前空間を使用し、名前ベースのラベルとのさらなる技術的な問題を説明します。
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 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.
標準のインターネット電子メールプロトコルは、コンテンツ[RFC 2821、2822]から「封筒」の情報を分離します。メッセージを発しているように、誰それが配信されなければならないと主張しているエンベロープ情報を示します。そして「へ：」：内容は、「から」のようなラベルで始まるフィールドがありますが、これらのコンテンツフィールドは、メールサーバー上のSMTPポートに、このようなTelnet接続を実際には効果がないと任意に簡単な、通常は利用可能なソフトウェアを使用して偽造することができます。コンテンツフィールドは、エンベロープフィールドと比較されていません。同じように、それらを必要とするには、郵便の手紙が彼らのリターンアドレスとしてメールボックスの一覧のメールボックス内に堆積することを要求し、メールのみに居住または事業リターンアドレスを許可するようになるという居住地または事業から郵便局でピックアップ。
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.
また、簡単なアップメールアドレスやメーリングリストにメールを転送するホストを設定されています。このフォワーダに通常のメールツールを使用して送信されたメールが自動的にフォワーダの名前を反映したコンテンツのヘッダーを持っていますが、フォワーダは、エンベロープ情報を変更すると、メールが実際に転送先のメールアドレスに送信されます。
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.
（名前は変装して）例えば、社会的メーリングリストinnocuous@foo.example.orgがあり、誰かがcat-torturers@other.exampleでフォワーダを設定します。代わりに、通常のそのボディにヘッダ、「へ：innocuous@foo.example.org」コンテンツヘッダ：メールが転送され、無害なメーリングリストではなく「cat-torturers@other.exampleへ」と表示されているフォワーダに送信しました。メールリーダソフトウェアは、CAT-拷問のヘッダを表示します。同様のことは、インターネットメールの「BCC」または「ブラインド礼儀コピー」機能を使用して行うことができます。
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.
電子メールの確保に関する作業手続があります。しかし、現時点ではそのような努力は、あなたが特定のエンティティがメールの実際の作者だったかどうかを確認することができます。認証を提供する場合、彼らはアドレス「から」封筒と内容にまだアドレスの「From」の三種類を追加し、彼らはメールの内容にドメイン名を制御するか、または認証とは関係ありません。
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.
最新のWebサーバとブラウザがHTTP 1.1 [RFC 2616]をサポートして、サイトにアクセスするために使用されるドメイン名が利用可能です。このように、異なるドメイン名を持つWebサイトでは、同じIPアドレスで同じマシン上にある場合でもアクセスすることができます。これは、同じコンピュータ上の情報の異なるカテゴリが異なるドメイン名を介してアクセスするように設定することができますので、名前ベースの標識のための小さなプラスです。しかし、データの任意の合理的な様々なコンピュータのために、異なる方法でデータのすべてのタイプを命名しようとしているの爆発は、名前の手に負えない数を必要とします。
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.
ウェブ要求がサーバマシンに送信された以前のHTTP 1.0 [RFC 1945]と、URIに使用される元のドメイン名が含まれていませんでした。
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.
一方、ウェブが自動転送されています。したがって、1が特定のドメイン名でデータにアクセスしようとすると、サーバーは、別の名前に、一時的または恒久的に、お使いのブラウザが再指示することができ、またはバイように、数字のIPアドレスにあなたを再指示することができます名前フィルタリングを渡します。
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.
ネットニュース[RFC 977、2980]は、最も重要なラベルは右に左と少なくとも、ドメイン名の反対側にあることを除いて、ドメイン名に外観が似ている階層的に構造化ニュースグループ名を使用しています。名前が階層的に構造化されながら、しかし、何の中央制御がありません。代わりに、ニュース・サーバは定期的に彼らとメッセージを交換し、彼らは彼らだけがメッセージを交換したいでこれらのニュースグループ内のメッセージにお互いを更新することに同意したその他のニュースサーバに接続します。
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.
ドメインネームシステムの階層ゾーンはローカルで管理されているが、それらは順番に多かれ少なかれICANNと米商務省によって制御されているトップレベルのルートサーバから始まる到達する必要があります。ネットニュースの世界ではそのような中心点やポイントを使用すると、任意のペアやニュースサーバの大規模なセットは、世界のどこに作る、ネットで他の場所で使用されるものの重複を含む、彼らが好きなニュースグループ名、下のニュースメッセージを交換することに同意することができます中央制御あるいは影響力は事実上不可能。実際には、いくつかのサーバー上のニュースグループの名前空間の一部の中に、誰もが任意の名前を持つ新しいニュースグループを作成することができます。
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.
そしてもちろん、ニュースグループ名にラベルの価値は300ビットをフィッティングすることは、ドメイン名に適合していると同じようには不可能です。
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.
インターネットリレーチャット[RFC 2810-2813]は別の名前空間を使用するサービスの別の例です。これは、IRCサーバの特定のネットワーク内で意味のある「チャンネル名」の単一レベルのスペースを使用しています。それは階層的ではないので、各サーバは、サーバのネットワークのサイズを制限するすべての名前、知っている必要があります。
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.
ニュースグループ名と同じように、IRCチャンネル名は任意のグローバル「根」から対象または到達可能なローカルの決定、ではないという事実は、中央集権政治的支配を事実上不可能になります。
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.
インターネットをベースとしているインターネットプロトコル（IP）の主要な特徴は、それが「パケット」にアップしたデータを破壊することです。これらのパケットは個別に扱われ、元から宛先にルーティングされています。各パケットは、インターネットがパケットを供給しようとします先の先のポイントの数値アドレスを運びます。
(End users do not normally see these numeric addresses but instead deal with "domain names" as described in section 4.1. above.)
（エンドユーザは、通常、これらの数値アドレスを参照してくださいではなく、4.1節で説明したように「ドメイン名」に対処しません。上記の。）
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].
今使用中の優勢な数値アドレスシステムは、IPv4、または32ビットアドレス[RFC 791]を提供するインターネットプロトコルバージョン4と呼ばれます。 128ビットのアドレス[RFC 2373、2374]を提供する新しいIPv6の[RFC 2460]の増加の移行があります。
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.
コンテンツフィルタリングのためのアドレス指定を使用する際の1つの問題は、これは非常に粗い技術であるということです。 IPアドレスは通常、など複数のWebページを収容することができ、全体のコンピュータシステム、ファイルのセットに対応したネットワーク・インタフェース、それはブロックまたは有効にするために希望されたのほんの一部を参照してください。ますます、単一のIPアドレスは、その場合には、これらのコンピュータは、サーバは通常はありませんが、その背後にある複数のコンピュータを隠しNAT（ネットワークアドレス変換）ボックス[RFC 2663]に対応してもよいです。
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.
しかし、粗い粒度の問題を超えて、階層ルーティングの実用的な制約があっても、単一のIPv4アドレスビットまたは不可能IPv6アドレスビットのかなりの数の割り当てを行います。
IP addresses are technically inappropriate for content filtering because their assignment is intimately tied to network routing and topology.
その割り当ては密接ネットワークルーティングおよびトポロジに結びついているため、IPアドレスは、コンテンツフィルタリングのための技術的に不適切です。
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:
インターネットは、実際にメッシュであるが、簡単にするために、我々はそれが「上」にある中央のバックボーンを持つように考えるならば、次のように、パケットは、一般的にルーティングされます。
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.
これらのルーティングの決定の全てが最長前方一致に基づいて行われているので、IPアドレスは、一般的な名前やラベルではなく、批判的かつ緊密ネットワークの実際のトポロジとルーティング構造に関連していることがわかります。それらがランダムに割り当てられた場合、ルータはそれがはるかにルータ設計のための現在の技術的能力を超えてしまう特定のアドレスのために非常に多くの特定のルートを覚えておくことが必要とされるであろう。インターネットは、致命的な中断されるだろうと動作しないでしょう。
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.
また、階層[RFC 1715]の各レベルの割り当ての一部の非効率性があることに留意すべきです。一般的に、割り当ては二つのアドレスの電源のものであり、要件が成長および/または縮小と、すべてのアドレスを使用するのは実用的ではありません。
(The above simplified description ignores multi-homing and many other details.)
（上記の簡略説明はマルチホーミングおよび他の多くの細部を無視します）。
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.
ただ、コンテンツフィルタリング用のIPv4グローバルインターネットアドレスの1ビットでも再配分する実用的な方法はありません。このようなアドレスが不足しています。そのような割り当ては、実際には、半分に利用可能なアドレスの数を削減します。ただ、これを行うにしても、階層配分[RFC 1715]とルーティングの非効率性のない十分なアドレスは、ありません。あったとしても、現在の数字のインターネット上のホストとすべての組織によってリナンバリングようにこれを念頭において割り当てられていないが、数十億ドルに原価計算の超人作業を必要とされるであろう。
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.
これらの問題は克服された場合であっても、アドレスビットの最上部付近にも、単一ビットの割り当てはおそらくデフォルトフリーゾーン内のルートの数を2倍となります。これは、現在のルータのキャパシティを超え、巨大なコストで、まだ存在しない新しいルータにそれらの何千ものアップグレードを必要とします。アドレスビットの底部付近のビットの割り当てビットが利用可能であったとしても、必要または強制することは非現実的であろう世界中のローカルな再構成を必要とするであろう。
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!
単一ビットのみがおろかつ以上、コンテンツラベルに割り当てられている場合は、すべてこれです。そして、我々はあなたが実際よりも多くの300ビットを、必要になると想定されます！
Basically, the idea is a non-starter.
基本的には、アイデアは非スターターです。
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は128ビットのアドレスフィールド[RFC 2373、2374]を提供します。さらに、IPv6アドレスの割り当てはまだ揺籃期にあります。このように、と言うの割り当ては、標識のためのIPv6アドレスの1ビットが考えられます。
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.
（セクション4.2.1。）しかしながら、上述したように、標識のために割り当てられたすべての高いビットは、ルーティングシステムに課されるコストが倍になります。 1ビットを割り当てると、一般的に、ルーティングテーブルのサイズを2倍となります。
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.
2つのビットを割り当てると、4によってそれらを掛けます。私たちは、現実的な世界的な標識のために必要な前提と300ビットを割り当てると、300は128よりも多くの大きいこと、そしてそれがなかった場合には、技術的に実現不可能ルーティングテーブルのサイズにつながる、IPv6のために論理的に不可能です。でも、たとえば、20ビットを割り当てる、それが可能であったならば、百万乗算テーブルサイズを信じられないでしょう。
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.
低ビットを割り当てることも、問題を抱えています。ラベル[RFC 2374]のためにそれらを使用して互換性のない方法で、下64ビットを使用する技術的な提案があります。だから、それはおそらく、「中位ビット」（上半分の実際に低いビット）でなければならないであろう。 IPv4の場合と同様に、広いこの世界を強制することは不可能であろう。それが可能であった場合は、1ビットまたは2ビットは、明らかに不十分であろう、そこに割り当てることができました。
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ラベル（インターネットコンテンツ選択のためのプラットフォーム）は、インターネットにアクセス可能材料のための「評価」を提供するための一般的なシステムです。 PICS文書は[PICS]詳細については、相談する必要があります。一般的には、PICSは、レーティングサービスとレーティング・システムの任意の多数を前提としています。各サービスおよびシステムは、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.
合計で、300ラベル情報のビット以上を提供し、複数のPICSサービスを持っていることは非常に合理的です。興味のあるすべてのコミュニティのためのPICSサービスがあるかもしれません。技術のこの種のは本当に多様かつダイナミックな世界での材料の分類やラベリングを利用できるようにする唯一の合理的な方法です。
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.
このようPICSラベルサービスは政府公布検閲カテゴリを配布するために使用することもできるが、例えば、国家のファイアウォールを経由して、政府の検閲よりも任意の悪化しているかは明らかではありません。
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.
PICSの評価システムは、本質的に1つ以上のディメンションの定義及び評価オブジェクトに各次元に割り当て可能な値の数値範囲です。サービスは、ラベルは、実際の評価を含んでいるラベルの源です。評価は、特定または汎用のいずれかです。具体的な評価は、特定のURL [RFC 2396]で材料のみに適用され、それから参照何も含まれている画像ファイルをカバーしていません。一般的な評価は、指定されたURLに、記載されたURLが接頭辞であるすべてのURLに適用されます。
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))
（ "ftp://movies.example.sex/raunchy-movie" 評価（性別6つの暴力1つの言語8つの薬2悪魔0）のためのPICS-1.1 "http://movie-rating-service.example.net" のラベル）
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.
機械読み取り可能な評価システムの説明は、値の範囲を含め、提供ディメンションのセット。追加情報、妥当性の始まりなどと終了時間は、ラベルに組み込むことができます。
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.
（2）HTTP応答のデータを備え、（1）HTMLに埋め込まれ、そして（3）別途第三者から：ラベルは、3つの方法で利用可能にすることができます。コンテンツは、ラベル、それに埋め込まれた、またはデータが、上記の最初の2つの方法でのように、返されたソースによって送信が要求される場合、それは分類粒状強制音声の問題を提起します。別の当事者が決定し、コンテンツのラベルを提供し、ユーザーは相談したいものは何でも、このようなサードパーティやパーティーを自由に選択することができますせる第三の方法で使用される場合は、それが存在するカテゴリ、編集者、及び評価者の無数をサポートすることができます並行して。
Digital signatures are available to secure PICS Labels [PICS].
デジタル署名は、PICSラベル[PICS]を確保するために用意されています。
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.
任意のラベルや分類方式は、データが誤って標識し、誤って分類されるようにするには、意図的な試みがあることを前提としなければなりません。いくつかは、特定のラベルを利用して、知覚または単にシステムを混乱させることにこれが原因である可能性があります。ソースは常に正確かつ便利なラベルが情報を送ったならば結局のところ、セキュリティは[RFC 3514]ずっと容易になるだろう。そのような強制力の考慮事項は、この文書に記載された種々の機構に関連して説明されています。
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.
単一のトップレベルドメイン名は、そのよう.sex、または単一のIPアドレスのビットとして、割り当てられ、「大人」または「攻撃的」材料の世界の義務家になることができたという概念は、幅広い法的および技術的なナンセンスです。
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.
このようゲットーであるべき材料のどのような種類のグローバル契約は不可能です。世界的な文脈では、単一または複数のカテゴリの少数の使用が不合理です。世界の多くの地域社会など、300ビットの基準を包含することができ、合理的なサイズのラベルの実装では、ドメイン名またはIPアドレスレベルでは技術的に不可能であると予見可能な将来のためにそう残ります。技術的に不可能に加えて、そのような任務は、いくつかの法域では、だけでなく、ドメインまたは他の文字列名の厳しい言語的な問題原因スピーチの強制は違法になります。
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.
しかし、政府機関、および、そのような審査によって割り当てられた評価を選択して利用するためのそれらのアクセス情報の能力であるかもしれないそのうちのいくつかの独立した審査の茄多の概念は、可能です。
[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]インターネットコンテンツ選択PICS 1.1評価サービスと評価システムのためのプラットフォーム - とその機械可読説明<http://www.w3.org/TR/ REC-PICS-サービス>、1996年10月。
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仕様<http://www.w3.org/TR/REC-PICSRules>、1997年12月。
PICS Signed Labels (DSIG) 1.0 Specification <http://www.w3.org/TR/REC-DSig-label/>, May 1998.
PICSラベル署名（DSIG）1.0仕様<http://www.w3.org/TR/REC-DSig-label/>、1998年5月。
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC 791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC 977] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[RFC 977]カンター、B.およびP.ラプスリー、 "ネットワークニュース転送プロトコル"、RFC 977、1986年2月。
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
[RFC 1035] Mockapetris、P.、 "ドメイン名 - 実装と仕様"、STD 13、RFC 1035、1987年11月。
[RFC 1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
[RFC 1591]ポステル、J.、 "ドメインネームシステムの構造と委任"、RFC 1591、1994年3月。
[RFC 1945] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC 1945]バーナーズ=リー、T.、フィールディング、R.、およびH. Frystyk、 "ハイパーテキスト転送プロトコル - HTTP / 1.0"、RFC 1945、1996年5月。
[RFC 2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[RFC 2373] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[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.、オデル、M.とS.デアリング、 "IPv6の集約可能グローバルユニキャストアドレス形式"、RFC 2374、1998年7月。
[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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC 2663] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[RFC 2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000.
[RFC 2810] Kalt、C.、 "インターネットリレーチャット：アーキテクチャ"、RFC 2810、2000年4月。
[RFC 2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC 2821] Klensin、J.、エド。、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[RFC 2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC 2822]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[RFC 2980] Barber, S., "Common NNTP Extensions", RFC 2980, October 2000.
[RFC 2980]バーバー、S.、 "共通NNTP拡張機能"、RFC 2980、2000年10月。
[BT] "British Telecom comments to U.S. Commerce Department", February 20, 1998, <http://www.ntia.doc.gov/ntiahome/domainname/ 130dftmail/BT.htm>
[BT] "米国商務省へのブリティッシュテレコムのコメント"、1998年2月20日、<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]「リノ対アメリカ自由人権協会」、117 S.Ct. 2329年、1997年6月26日、
[COPAREPORT] "Final Report of the COPA Commission to the U.S. Congress", October 20, 2000, <http://www.copacommission.org/report/ newtopleveldomain.shtml>
[COPAREPORT] "米国議会へのCOPA委員会の最終報告書"、2000年10月20日、<http://www.copacommission.org/report/ newtopleveldomain.shtml>
[GAO] "GAO Report OGC-00-33R", July 7, 2000, <http://www.gao.gov/new.items/og00033r.pdf>
[GA O] "GA 0レポートOG C-00-33R"、2000年7月7日、<HTTP :. // OOO高い.GOV / new.items /OG00033日.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ポリシー監督委員会のRFC 97-02"、1997年9月13日、<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議会、10月5日、1998年<http://www.epic.org/free_speech/censorship/ 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] "ICMレジストリからICANNへの再考の要請"、2000年12月15日、<http://www.icann.org/committees/reconsideration/ ICM-要求16dec00.htm>
[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/press/00/06/ 2000608958.html>
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC 1034] Mockapetris、P.、 "ドメイン名 - 概念および機能"、STD 13、RFC 1034、1987年11月。
[RFC 1715] Huitema, C., "The H Ratio for Address Assignment Efficiency", RFC 1715, November 1994.
[RFC 1715]のHuitema、C.、RFC 1715 "アドレス割り当ての効率化のためのH比"、1994年11月。
[RFC 2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC 2396]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC 2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC 2535] Eastlake, 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC 2535]イーストレイク、第三、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。
[RFC 2606] Eastlake, 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC 2606]イーストレイク、第三、D.とA. Panitz、 "予約トップレベルDNS名"、BCP 32、RFC 2606、1999年6月。
[RFC 2811] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000.
[RFC 2811] Kalt、C.、 "インターネットリレーチャット：チャンネル管理"、RFC 2811、2000年4月。
[RFC 2812] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.
[RFC 2812] Kalt、C.、 "インターネットリレーチャット：クライアントプロトコル"、RFC 2812、2000年4月。
[RFC 2813] Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000.
[RFC 2813] Kalt、C.、 "インターネットリレーチャット：サーバプロトコル"、RFC 2813、2000年4月。
[RFC 2854] Connelly, D. and L. Masinter, "The 'text/html' Media Type", RFC 2854, June 2000.
[RFC 2854]コネリー、D.およびL. Masinter、 " 'text / htmlの' メディアの種類"、RFC 2854、2000年6月。
[RFC 3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC 3513] HindenとR.とS.デアリング、 "インターネットプロトコルバージョン6（IPv6）のアドレス指定アーキテクチャ"、RFC 3513、2003年4月。
[RFC 3514] Bellovin, S., "The Security Flag in the IPv4 Header", 1 April 2003.
[RFC 3514] 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>
The contribution and efforts of Declan McCullagh, who wrote substantially all of sections 2 and 3 of this document, are gratefully acknowledged.
実質上のセクション2と、このドキュメントの3のすべてを書いたデクラン・マカラの貢献と努力が、深く感謝しています。
Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレーク第3モトローラ研究所155ビーバー通りミルフォード、MA 01757 USA
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
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。