[要約] RFC 3675は、.sexドメインの使用に関する懸念を議論し、その危険性を指摘しています。このRFCの目的は、インターネットの安全性を向上させるために、.sexドメインの適切な使用に関するガイドラインを提供することです。
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）The Internet Society（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月の報告書で、下院商業委員会は、「アダルトドメインを作成する技術的障壁はなく、アダルトドメイン内のすべてのWebサイトをブロックするのは非常に簡単だ」と述べました。報告書はまた、委員会はコンピューター業界の規制に警戒しており、米国政府による決定は「国際的な結果をもたらす」と述べた[Houserport]。
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年の米国商務省への1998年の手紙で、その計画を「強く支持」したと言って、成人のトップレベルのドメインを支援しました。その理由：「性的に露骨なサービスは、このGTLDのドメイン名で動作するために法的に必要である可能性があります[それは、そのようなサイトへのアクセスをより簡単で簡単に制御することができます...」[BT]。ICANNの先駆者の1人である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評価の映画館の所有者または性的に優れた雑誌を販売するコンビニエンスストアの所有者と同じ基準を単純に守るように頼むだろう」と述べた[Lieberman]。
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年の法律でこの委員会を作成した米国議会は、メンバーに「未成年者に有害な資料を投稿するためのドメイン名の確立」を調査することを要求しました。.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アドレスのセットの割り当てにより、コンテンツのいわゆるレッドゾーンまたはグリーンゾーンの作成を調査しました。これらの2つのゾーンのいずれかにない材料は、グレーゾーンで見られるものであり、未成年者にとって必ずしも適切または不適切ではありません。コミッショナーからのコメントは、「有効性は特定の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議長のエスター・ダイソンは、成人産業がそのような領域が適切であることに完全に同意しなかったと述べました。2000年12月に、カナダのオンタリオ州オンタリオ州のICMレジストリの希望に満ちた.xxxの1つの.xxxは、ICANNにその決定を再検討するように依頼しました[ICM-Registry]。
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年、米国議会は、「子供の安全」材料のために子供のドメインの作成を義務付けました。これは、理由の一部であり、次のセクションで説明されている理由があると確信した後でした。
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".
性的に優れた資料に関しては、すべての人、裁判所、政府は、受け入れられるものとそうでないものについて異なる見解を持っています。態度は時間とともに変化し、ある町または年に適切と見なされるものは、次の町や年に抗議を引き起こす可能性があります。性的活動の描写の滑りやすい性質に直面した場合、ある米国最高裁判所判事は、「私はそれを見たときにそれを知っている」と明確に定義しました。
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サイトから社会を保護しています。セックスドメインに含まれるべきものについての彼らの見解は、リベラルな西側諸国のものとはほとんど同じではありません。
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".
一部の保守的な政治家は、2000年10月の会議でICANNが.xxxを承認しなかったとすでに不満を述べています。米国下院での2001年2月の聴聞会で、議員は、「kidsと.xxxの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.
大人のトップレベルのドメインの存在は、おそらく、政策または立法のいずれかの関連する努力のための扉を開くでしょう。攻撃的な素材を定義できる多くの異なる軸があります：性別、暴力、憎しみ、異端、転覆、冒asp、違法薬物、冒とく的な麻薬、政治的正しさ、犯罪の栄光、法律を破るための扇動など。このような提案は、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。では、いくつかの特定の高レベルプロトコルを伴う困難について説明します。場合によっては、これらのプロトコルは異なる名前スペースを使用します。追加の将来のプロトコルは、命名特性をまだ解放されていないことで考案される可能性があることに留意する必要があります。
We also discuss PICS labels [PICS] as an alternative technology in section 4.3.
また、セクション4.3の代替技術としての写真ラベル[写真]についても説明します。
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の重複するコミュニティで構成されているとarbitrarily意的に想定します。さらに、一部の不特定でありながら巧妙なエンコードスキームにより、300ビットラベルによるすべての情報の適切なグローバルな分類が可能になるとarbitrarily意的に想定しています。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などのラベルの点線のシーケンスです。ドメイン名は、ほとんどのワールドワイドウェブアドレスまたはURL [RFC 2396]の重要な部分を形成し、一般に「//」の後に表示されます。ドメイン名システムのセキュリティは標準化されています[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に保存されているデータは、特定のマシンにデータを送信するための数値情報である可能性があります。（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.
ニュースグループ名やインターネットリレーチャット（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.
提示される通常のラベル付けのアイデアは、「大人」の材料および/または「安全」材料などの.kidの.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:
考えられる問題の例として、数年間、トルクメニスタン政府は、登録された第2レベルのドメイン名の一部が問題になっている可能性があるため、以前は収益源であった「.TM」で新しい登録を停止したことに注意してください。特に、<http://www.nic.tm>のWebホームページは次のように述べています。
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レジストリはレビューされています。将来の登録のための命名ポリシー。.TMNICは、新しいポリシーを実装できるまで登録を一時停止しました。すぐに再びライブを行うことを望んでいます。」
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に減少すると予想されています。
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.
最初の問題は、ほとんどのコンピューターやWebサイトに素材が混在することを期待することです。その一部のみが特別に分類されるべきです。特別なトップレベルドメイン名（TLDS）を使用すると、サイトが心配する必要があるDNSゾーンの数が増えます。たとえば、サイトが何らかの形でその素材を「子供」、「通常」、「大人」の山に既にソートしていると仮定します。特別なTLDラベルがなければ、たとえばkids.example.net、adult.example.net、およびその他のexample.netの下に保存できます。これには、データベースエントリの単一のexample.netゾーンのメンテナンスのみが必要です。特別なtldラベル付けでは、少なくともexample.net（通常のものの場合）、example.net.sex、およびexample.net.kidを維持する必要があります。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システムはデータベースとして機能します。リソースレコードまたはRRSと呼ばれる特定のデータをドメイン名に関連付けます。特に、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は、その名前またはより深い名前にデータを挿入できます（より深い名前空間の一部をさらに他の名前に委任する範囲を除きます）。したがって、example.comのコントローラーは、purity.example.comがそれに関連付けられているようにデータを挿入できます。これはwww.obscene.example.sexに関連付けられています。これにより、Purity.example.comへの参照は、www.obscene.example.sex Webサイトと同じ関連するIPアドレスを使用するように指示します。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つの電子メールとWorld Wide Webは、ドメイン名アドレス指定を使用します。2番目の2つのNet Newsと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]から分離します。エンベロープ情報は、メッセージがどこから発生したかを主張し、誰に配信されるべきかを示します。コンテンツには、「from」や「to：」などのラベルから始まるフィールドがありますが、これらのコンテンツフィールドは実際には効果がなく、メールサーバーのSMTPポートへの通信済みなどの単純な通常利用可能なソフトウェアを使用して任意に偽造できます。コンテンツフィールドは、エンベロープフィールドと比較されません。それらを要求することは、メールボックスリストに郵便番号を返品住所として預け入れ、その居住地またはビジネスから郵便局が拾った郵便物の住居またはビジネスの返品アドレスのみを許可することを要求するようなものです。
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.
さまざまなメールクライアントが、電子メールのコンテンツからエンベロープ情報とヘッダーを異なる方法で表示しますが、一般に、原則コンテンツフィールドには顕著になります。したがって、コンテンツのラベル付けとはまったく同じではありませんが、fromとヘッダーなどに表示される電子メールアドレスに任意のドメイン名を持つ人にメールを送信することは些細なことであることに注意する必要があります。
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.
たとえば、（名前が偽装されています）ソーシャルメーリングリストの無害@foo.example.orgがあり、誰かがcat-torturers@other.exampleに転送者を設定しました。転送者に送信されたメールは転送され、無害なメーリングリストに表示されますが、通常の「cat-torturers@other.example」ヘッダーがあります。。Mail Readerソフトウェアは、Cat-Torturersヘッダーを表示します。インターネットメールの「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.
電子メールの保護に関する作業手続きがあります。ただし、現在のそのような努力により、特定のエンティティがメールの実際の著者であるかどうかを確認することができます。認証を提供する場合、「アドレス」の「アドレス」の「アドレス」から「アドレス」から「アドレス」を追加しますが、メールのコンテンツ内のドメイン名の制御または認証に関連していません。
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.
HTTP 1.1 [RFC 2616]をサポートする最新のWebサーバーとブラウザでは、サイトへのアクセスに使用されるドメイン名が利用可能です。したがって、異なるドメイン名を持つ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]では、Web要求がサーバーマシンに送信されたとき、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.
一方、Webには自動転送があります。したがって、特定のドメイン名でデータにアクセスしようとすると、そこにあるサーバーは、ブラウザを一時的または永続的に別の名前に再ダイレクトすることができます。パス名フィルタリング。
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]は、ドメイン名と似ている階層構造化されたニュースグループ名を使用します。ただし、最も重要なラベルは左側にあり、右側はドメイン名の反対です。ただし、名前は階層的に構造化されていますが、中央の制御はありません。代わりに、ニュースサーバーは、メッセージを交換することに同意した他のニュースサーバーに定期的に接続し、メッセージを交換したいニュースグループでのみメッセージでお互いを更新します。
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]は、別の名前スペースを使用するサービスのもう1つの例です。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またはインターネットプロトコルバージョン4と呼ばれ、32ビットアドレスを提供します[RFC 791]。新しいIPv6 [RFC 2460]への移行が増加しており、128ビットアドレス[RFC 2373、2374]を提供します。
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]。一般に、割り当ては2つのアドレスのパワーであり、要件が増加および/または縮小するにつれて、すべてのアドレスを使用することは実用的ではありません。
(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.
コンテンツフィルタリングの使用のために、1つのIPv4グローバルインターネットアドレスを再配置する実用的な方法はありません。このような住所は不足しています。このような割り当ては、実際には、利用可能なアドレスの数を半分に削減します。これを行うには、階層的割り当て[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.
これらの問題が克服されたとしても、アドレスビットの上部近くの1ビットの割り当ては、デフォルトのフリーゾーンのルートの数を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!
そして、これはすべて、1ビットだけがコンテンツのラベル付けに割り当てられている場合、複数のビットに割り当てられている場合です。そして、私たちはあなたが実際に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。）、ラベル付けに割り当てられたすべての高ビットは、ルーティングシステムに課されるコストを2倍にします。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ビットを割り当てると、現実的なワールドワイドラベル付けに必要なと仮定することは、IPv6では300が128よりもはるかに大きい場合は論理的に不可能であり、もしそうなら、技術的に達成できないルーティングテーブルサイズになります。たとえば、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ラベル（インターネットコンテンツ選択のためのプラットフォーム）は、インターネットにアクセス可能な素材に「評価」を提供するための一般化されたシステムです。写真のドキュメント[写真]は詳細について参照する必要があります。一般に、写真は任意に多数の評価サービスと評価システムを想定しています。各サービスとシステムは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ビット以上のラベル情報を提供する複数の写真サービスを持っていることは非常に合理的です。関心のあるすべてのコミュニティのための写真サービスがある可能性があります。この種のテクノロジーは、多様でダイナミックな世界で利用可能な資料の分類またはラベル付けを行うための唯一の合理的な方法です。
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.
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))
（PICS-1.1 "http://movie-lating-service.example.net" ftp://movies.example.sex/raunchy-movie "ratings（sex 6 buirence 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.
マシン読み取り可能な評価システムの説明には、値の範囲と提供される寸法のセットが含まれます。妥当性の開始時間や終了時間などの追加情報は、ラベルに組み込むことができます。
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.
現在、ラベルは3つの方法で利用可能になります：（1）HTMLに埋め込まれ、（2）HTTP応答のデータが提供され、（3）サードパーティとは別に。上記の最初の2つの方法のように、データが返されたときにデータに埋め込まれているか、ソースによってラベルが埋め込まれたり、ソースによって送信されたりする必要がある場合、分類の粒度と強制音声の問題が発生します。ただし、別のパーティがコンテンツにラベルを決定し、提供する3番目の方法で使用され、ユーザーが相談したいサードパーティやパーティーを自由に選択できる場合、無数のカテゴリ、編集者、評価者をサポートできます。並行して。
Digital signatures are available to secure PICS Labels [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-services>、1996年10月。
PICS 1.1 Label Distribution -- Label Syntax and Communication Protocols <http://www.w3.org/TR/REC-PICS-labels>, October 1996.
写真1.1ラベル分布 - ラベルの構文と通信プロトコル<http://www.w3.org/tr/rec-pics-labels>、1996年10月。
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.
写真署名ラベル（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] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC 977] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[RFC 977] Kantor、B。およびP. Lapsley、「Network News Transfer Protocol」、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] Postel、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] Berners-Lee、T.、Fielding、R。and H. Frystyk、「HyperText Transfer Protocol-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. Deering、「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.、O'Dell、M。、およびS. Deering、「IPv6 Aggregatable Global Unicastアドレス形式」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「Hypertext Transfer Protocol-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. Holdrege、「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.、ed。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC 2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC 2822] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[RFC 2980] Barber, S., "Common NNTP Extensions", RFC 2980, October 2000.
[RFC 2980] Barber、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]「リノv。アメリカ市民自由連合」、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]「米国議会へのコパ委員会の最終報告書」、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>
[Gao] "Gao Report OGC-00-33R"、2000年7月7日、<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ポリシー監視委員会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]「U.S. House Commerce Committee Report」、第105回議会、1998年10月5日。
[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-request-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。、「アドレス割り当て効率のH比」、RFC 1715、1994年11月。
[RFC 2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC 2396] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。
[RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC 2460] Deering、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]イーストレイク、3rd、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]イーストレイク、3rd、D。およびA.パニッツ、「予約済みのトップレベル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] Connelly、D。およびL. Masinter、「The "Text/HTML 'Media Type"、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. Deering、「インターネットプロトコルバージョン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/ news/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の実質的にすべてを書いたDeclan McCullaghの貢献と努力は、感謝されていることに感謝しています。
Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレイク第3モトローラ研究所155ビーバーストリートミルフォード、マサチューセッツ州01757 USA
Phone: +1-508-786-7554 (w)
+1-508-634-2066 (h)
EMail: dee3@torque.pothole.com
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。