Network Working Group                                    D. Eastlake 3rd
Request for Comments: 3675                         Motorola Laboratories
Category: Informational                                    February 2004
        
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
        
   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
        
       7.1.  Normative References . . . . . . . . . . . . . . . . . . 18
       7.2.  Informative References . . . . . . . . . . . . . . . . . 19
   8.  Acknowledgement. . . . . . . . . . . . . . . . . . . . . . . . 21
   9.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
   10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22
        
1. Introduction
1. 介绍

Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag "adult" or "unsafe" material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and the technical points of view.

定期有建议要求使用特殊的顶级名称或IP地址位来标记“成人”或“不安全”材料等。本文从法律、哲学和技术角度解释了为什么这是一个考虑不周的想法。

2. Background
2. 出身背景

The concept of a .sex, .xxx, .adult, or similar top-level domain in which it would be mandatory to locate salacious or similar material is periodically suggested by some politicians and commentators. Other proposals have included a domain reserved exclusively for material viewed as appropriate for minors, or using IP address bits or ranges to segregate content.

一些政客和评论员定期提出.sex、.xxx、.成人或类似顶级领域的概念,在这些领域中必须查找色情或类似材料。其他提案包括专门为未成年人观看的材料保留一个域名,或使用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年致美国商务部的一封信中表示,英国电信“强烈支持”这一计划。理由是:“法律可能要求色情服务在本gTLD中使用域名运营,这将使控制此类网站的访问变得更加简单和容易……”[BT]。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年,互联网娱乐集团总裁塞思·沃沙夫斯基(Seth Warshavsky)告诉美国参议院商务委员会,他希望看到一个成人域名。“我们建议创建一个新的顶级域名,名为“.madure”,网络上所有露骨的色情内容都将在这个域名上驻留,”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].

美国民主党副总统候选人、参议员约瑟夫·利伯曼(Joseph Lieberman)在2000年6月的联邦儿童在线保护委员会(federal Commission on Child Online Protection)会议上支持了这一想法。利伯曼在一份事先准备好的声明中说,“我们将要求互联网的仲裁者只需遵守与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月的报告中专门用了一节来讨论这一问题。它得出结论,a.xxx和a.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主席埃丝特·戴森(Esther Dyson)表示,成人行业并不完全同意这样一个域名是合适的。加拿大安大略省ICM注册中心于2000年12月要求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年,美国国会授权为“儿童安全”材料创建一个Childs.us域。这是在确信由于以下部分所述的原因,试图通过.kids域为全世界制定标准是不合适的之后。

3. Legal and Philosophical Problems
3. 法律和哲学问题

When it comes to sexually-explicit material, every person, court, and government has a different view of what's acceptable and what is not. Attitudes change over time, and what is viewed as appropriate in one town or year may spark protests in the next. When faced with the slippery nature of what depictions of sexual activity should be illegal or not, one U.S. Supreme Court justice blithely defined obscenity as: "I know it when I see it".

当涉及到性暴露材料时,每个人、法院和政府对什么是可以接受的,什么是不可以接受的都有不同的看法。随着时间的推移,人们的态度会发生变化,在一个城镇或一年中被视为合适的事情可能会在下一年引发抗议。当面对性行为描述是否违法这一棘手问题时,一位美国最高法院法官愉快地将淫秽定义为:“我看到它就知道它”。

In the U.S.A., obscenity is defined as explicit sexual material that, among other things, violates "contemporary community standards" -- in other words, even at the national level, there is no agreed-upon rule governing what is illegal and what is not. Making matters more knotty is that there are over 200 United Nations country codes, and in most of them, political subdivisions can impose their own restrictions. Even for legal nude modeling, age restrictions differ. They're commonly 18 years of age, but only 17 years of age in one Scandinavian country. A photographer there conducting what's viewed as a legal and proper photo shoot would be branded a felon and child pornographer in the U.S.A. In yet other countries and groups, the entire concept of nude photography or even any photography of a person in any form may be religiously unacceptable.

在美国,淫秽被定义为明确的性材料,除其他外,违反“当代社区标准”——换句话说,即使在国家层面,也没有商定的规则来管理什么是非法的,什么不是。使问题更加棘手的是,联合国有200多个国家代码,在其中大多数代码中,政治分支机构可以施加自己的限制。即使是合法的裸体模特,年龄限制也有所不同。他们通常18岁,但在一个斯堪的纳维亚国家只有17岁。在美国,一名摄影师在那里进行被视为合法和正当的照片拍摄,将被视为重罪和儿童色情作者。在其他国家和团体,裸体摄影的整个概念,甚至任何形式的个人摄影,在宗教上都是不可接受的。

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.

沙特阿拉伯、伊朗、尼日利亚北部和中国不太可能像荷兰或丹麦那样拥有同样的自由主义观点。与其他一些国家一样,沙特阿拉伯和中国广泛过滤其互联网连接,并建立了政府机构,以保护其社会免受官员认为不道德的网站的侵害。他们对性领域应该包含什么的观点与西方自由国家的观点几乎不一样。

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.

这些关于性材料的截然不同的观点使得人们无法想象,对于性或成人的顶级领域,什么是合适的,什么是不合适的,能够达成全球共识。此外,这样一个域名的存在将对保守派立法者产生不可抗拒的诱惑,要求有争议的出版商转移到该域名,并惩罚那些没有转移到该域名的出版商。

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月,在美国众议院的一次听证会上,立法者们警告说,他们“想探究ICANN不批准两个特定的顶级域名--.kids和.xxx的理由,以此作为保护儿童免受互联网上如此普遍的可怕的淫秽行为之害的手段”。

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月报告说,商务部继续负责权威root[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.

美国公民自由联盟(American Civil Liberties Union)和国际全球互联网自由运动(international Global Internet Liberty Campaign)的其他成员警告说,坦率地谈论节育、艾滋病预防、男女同性恋性行为、监狱强奸等社会问题的出版商可能会被迫转移到成人领域。一旦到了那里,他们就会受到学校、图书馆、公司和其他使用过滤软件的团体的污名化和封锁。这些信息的发布者,如果不将自己视为色情作者并保留现有地址,可能会成为起诉的目标。

The existence of an adult top-level domain would likely open the door for related efforts, either policy or legislative. There are many different axes through which offensive material can be defined: Sex, violence, hate, heresy, subversion, blasphemy, illegal drugs, profanity, political correctness, glorification of crime, incitement to break the law, and so on. Such suggestions invite the ongoing lobbying of ICANN, the U.S. government, and other policy-making bodies by special-interest groups that are not concerned with the technical feasibility or practicality of their advice.

成人顶级域名的存在可能会为相关的政策或立法努力打开大门。有许多不同的轴线可以定义攻击性材料:性、暴力、仇恨、异端、颠覆、亵渎、非法毒品、亵渎、政治正确性、美化犯罪、煽动违法等等。这些建议会引起ICANN、美国政府和其他决策机构的持续游说,这些游说由不关心其建议的技术可行性或实用性的特殊利益集团进行。

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.)

成人顶级域名可能会危及言论自由,从而产生负面的法律影响。美国最高法院大法官桑德拉·戴·奥康纳(Sandra Day O'Connor)表示,互联网上“成人区”的存在将使未来的《通讯礼仪法》(CDA)更有可能被视为符合宪法。奥康纳在1997年对最高法院驳回CDA(CDA)的部分异议中表示,“互联网最终分区的前景似乎很有希望”。(最高法院裁定CDA侵犯了言论自由权,将在网上传播“不雅”或“明显具有攻击性”的材料定为犯罪。)

Privacy could be harmed by such a proposal. It would become easier for repressive governments and other institutions to track visits to sites in a domain labeled as adult and record personally-identifiable information about the visitor. Repressive governments would instantly have more power to monitor naive users and prosecute them for their activities. It's also implausible that a top-level domain would be effective in controlling access to chat, email, newsgroups, instant messaging, and new services as yet to be invented.

这样的提议可能会损害隐私。压制性政府和其他机构将更容易跟踪被标记为成人的网站的访问,并记录访问者的个人身份信息。专制政府将立即拥有更大的权力来监控天真的用户并起诉他们的行为。顶级域名能够有效地控制聊天、电子邮件、新闻组、即时消息和尚未发明的新服务的访问,这也令人难以置信。

4. Technical Difficulties
4. 技术困难

Even ignoring the philosophical and legal difficulties outlined above, there are substantial technical difficulties in attempting to impose content classification by domain names or IP addresses. Mandatory content labeling is usually advanced with the idea of using a top level domain name, discussed in section 4.1., but we also discuss the possibility of using IP address bits or ranges in section 4.2.

即使忽略上述哲学和法律上的困难,在试图按域名或IP地址对内容进行分类时也存在重大的技术困难。强制性内容标签通常与第4.1节中讨论的使用顶级域名的想法一起提出,但我们也在第4.2节中讨论了使用IP地址位或范围的可能性。

In section 4.1.4., difficulties with a few particular higher level protocols are discussed. In some cases, these protocols use different name spaces. It should be kept in mind that additional future protocols may be devised with as yet undreamed of naming characteristics.

在第4.1.4节中,讨论了一些特定的高级协议的困难。在某些情况下,这些协议使用不同的名称空间。应该记住的是,将来可能会设计出更多的协议,但命名特性还未实现。

We also discuss PICS labels [PICS] as an alternative technology in section 4.3.

我们还将在第4.3节中讨论PICS标签[PICS]作为替代技术。

Only a limited technical background is assumed, so some basic information is included below. In some cases, descriptions are simplified and details omitted.

假设只有有限的技术背景,因此下面包含一些基本信息。在某些情况下,描述被简化,细节被省略。

This technical discussion minimizes the definitional problems. However, it is still necessary for evaluating some technical considerations to have some estimate of the amount of categorization that would be necessary for a realistic global censorship system. There is no hope of agreement on this point. For our purposes, we

这种技术性讨论将定义问题最小化。然而,仍有必要评估一些技术考虑因素,以估算现实的全球审查制度所需的分类数量。在这一点上没有达成一致的希望。为了我们的目的,我们

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.

将武断地假设世界人口由大约90000个重叠的社区组成,每个社区都有不同的利益分类。此外,我们任意假设某些未指定但巧妙的编码方案能够通过300位标签对所有信息进行适当的全局分类。有人会说300位标签太大,也有人会说它太小。无论如何,我们将使用它进行一些技术评估。

4.1. Content Filtering Using Names
4.1. 使用名称进行内容过滤

The most prominent user visible part of Internet naming and addressing is the domain name system [RFC 1034, 1035]. Domain Names are dotted sequences of labels, such as aol.com, world.std.com, www.rosslynchapel.org.uk, or ftp.gnu.lcs.mit.edu [RFC 1035, 1591, 2606]. Domain Names form an important part of most World Wide Web addresses or URLs [RFC 2396], commonly appearing after "//". Security for the domain name system is being standardized [RFC 2535], but has not been deployed to any significant extent.

互联网命名和寻址中最突出的用户可见部分是域名系统[RFC10341035]。域名是虚线标签序列,如aol.com、world.std.com、www.rosslynchapel.org.uk或ftp.gnu.lcs.mit.edu[RFC 103515912606]。域名是大多数万维网地址或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上的数据可能是用于向特定机器发送数据的数字信息,如果您尝试浏览,将使用这些信息<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.

通常提出的标签概念是保留顶级名称,例如.sex或.xxx表示“成人”材料和/或.kids表示“安全”材料等。下面的小节描述了与此相关的技术和语言问题。

4.1.1. Linguistic Problems
4.1.1. 语言问题

When using name labeling, the first problem is from whose language do you take the names to impose? Words and acronyms can have very different meanings in different languages and the probability of confusion is multiplied when phonetic collisions are considered.

在使用名称标签时,第一个问题是,您使用的名称来自哪种语言?单词和首字母缩略词在不同的语言中可能有非常不同的含义,当考虑语音冲突时,混淆的概率会成倍增加。

As an example of possible problems, note that for several years the government of Turkmenistan suspended new registrations in ".tm", which had previously been a source of revenue, because some of the

作为可能出现的问题的一个例子,请注意,土库曼斯坦政府几年来暂停了“.tm”的新注册,而“.tm”以前是一个收入来源,因为一些

registered second level domain names may have been problematic. In particular, their web home page at <http://www.nic.tm> said:

注册的二级域名可能有问题。特别是,他们的网页位于<http://www.nic.tm>他说:

Statement from the .TM NIC

.TM NIC的声明

"The response to the .TM registry has been overwhelming. Thousands of names have been registered from all over the world. Some of the names registered, however, may be legally obscene in Turkmenistan, and as a result the .TM NIC registry is reviewing its naming policy for future registrations. The .TM NIC has suspended registrations until a new policy can be implemented. We hope to be live again shortly."

“对.TM注册中心的反应非常热烈。来自世界各地的数千个名字已经注册。但是,在土库曼斯坦注册的一些名字可能在法律上是淫秽的。因此,.TM NIC注册中心正在审查其未来注册的命名政策。在新的po发布之前,.TM NIC已经暂停注册licy可以实施。我们希望很快再次上线。”

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.

目前世界上使用的语言大约有6000种,但预计到2100年将减少到3000种左右。

4.1.2. Explosion of Top Level Domain Names (TLDs)
4.1.2. 顶级域名(TLD)激增

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实际上只起作用,而且由于这种授权,它能够扩展到自最初部署以来增长的五个数量级。

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.

第一个问题是,大多数计算机或网站都会混合使用各种材料,其中只有一些材料需要特别分类。使用特殊顶级域名(TLD)会使站点不得不担心的DNS区域数量成倍增加。例如,假设该站点已经以某种方式将其内容分为“儿童”、“正常”和“成人”三类。例如,如果没有特殊的TLD标签,它可以将它们存储在kids.example.net、成人.example.net和其他.example.net下。这只需要维护数据库条目的单个example.net区域。使用特殊的TLD标签,至少需要维护example.net(对于普通内容)、example.net.sex和example.net.kids,它们位于DNS树不同部分的三个单独区域中,处于三个单独的授权之下。

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个名称类别,这是不可能的。没有一个网站需要使用所有类别,类别域名也不一定都是顶级域名。但这仍然是一场难以驾驭的噩梦。

4.1.3. You Can't Control What Names Point At You!
4.1.3. 你无法控制什么名字指向你!

Providers of data on the Internet cannot stop anyone from creating names pointing to their computer's IP address with misleading domain names.

互联网上的数据提供商无法阻止任何人使用误导性域名创建指向其计算机IP地址的名称。

The DNS system works as a database. It associates certain data, called resource records, or RRs, with domain names. In particular, it can associate IP address resource records with domain names. For example, when you browse a URL, most commonly a domain name within that URL is looked up in the DNS. The resulting address is then used to address the packets sent from your web browser or other software to the server or peer.

DNS系统用作数据库。它将某些数据(称为资源记录或RRs)与域名相关联。特别是,它可以将IP地址资源记录与域名相关联。例如,当您浏览URL时,通常会在DNS中查找该URL中的域名。然后,生成的地址用于对从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网站相同的关联IP地址。该假设网站的经理控制着淫秽的.example.xxx区域,但对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  |
         +-----------------+              +------------------+
        
            +-----------------------------------------+
            |          . (root) zone                  |
            | .com  .org  .net  .us  .uk  .sex  ...   |
            +---+---------------------------+---------+
                |                           |
                V                           V
       +--------------------+         +--------------------+
       |     .com zone      |         |     .sex zone      |
       |  example.com  ...  |         |  example.sex  ...  |
       +---------------+----+         +---------------+----+
                       |                              |
                       V                              V
      +---------------------+             +----------------------+
      |  example.com zone   |             |   example.sex zone   |
      |                     |             |                      |
      | purity.example.com -+--+      +---+- obscene.example.sex |
      | virtue.example.com  |  |      |   |     porn.example.sex |
      |      |              |  |      |   |        |             |
      +------+--------------+  |      |   +--------+-------------+
             |                 +------+------+     |
             |          +-------------+      |     |
             V          V                    V     V
         +-----------------+              +------------------+
         |  Virtuous Data  |              |  Salacious Data  |
         +-----------------+              +------------------+
        
4.1.4. Particular Protocol Difficulties
4.1.4. 议定书的特殊困难

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.

还有与特定协议相关的其他注意事项。我们在这里只考虑了几个。前两种,电子邮件和万维网,使用域名寻址。第二种是网络新闻和IRC,它们使用不同的名称空间,并说明了基于名称的标签的进一步技术问题。

4.1.4.1. Electronic Mail (SMTP)
4.1.4.1. 电子邮件(SMTP)

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

标准的Internet电子邮件协议将“信封”信息与内容分开[RFC 28212822]。信封信息表示消息的来源和应该向谁发送。内容中有以“From:”和“To:”等标签开头的字段,但这些内容字段实际上没有任何效果,可以使用简单的、通常可用的软件(例如邮件服务器上SMTP端口的远程登录)任意伪造。内容字段不与信封字段进行比较。要求它们是相同的,就像要求邮寄信件一样

deposited in a mail box list that mail box as their return address and only allowing residence or business return addresses on mail picked up by the post office from that residence or business.

存放在邮箱列表中,该邮箱作为其回信地址,并且仅允许邮局从该住所或企业收到的邮件中包含住所或企业回信地址。

While different mail clients display envelope information and headers from the content of email differently, generally the principle content fields are given prominence. Thus, while not exactly the same as content labeling, it should be noted that it is trivial to send mail to anyone with arbitrary domain names in the email addresses appearing in the From and To headers, etc.

虽然不同的邮件客户端显示来自电子邮件内容的信封信息和标题的方式不同,但通常会突出主要内容字段。因此,虽然与内容标签不完全相同,但应该注意的是,在发件人和收件人标题等中显示的电子邮件地址中,向任何具有任意域名的人发送邮件是微不足道的。

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. 发送给转发器的邮件被转发并出现在无害邮件列表上,但带有“收件人:cat”-torturers@other.example“标题在其正文中,而不是通常的”以:innocuous@foo.example.org“内容标题。然后,邮件读取器软件显示cat折磨器标题。类似的事情也可以通过互联网邮件的“密件抄送”或“盲抄送”功能来完成。

There is work proceeding on securing email; however, such efforts at present only allow you to verify whether or not a particular entity was the actual author of the mail. When providing authentication, they add yet a third type of "From" address to the envelope and content "From" addresses, but they do not relate to controlling or authenticating domain names in the content of the mail.

正在进行保护电子邮件的工作;然而,目前这种努力只允许您验证某个特定实体是否是邮件的实际作者。在提供身份验证时,他们将第三种类型的“发件人”地址和内容“发件人”地址添加到信封中,但它们与控制或验证邮件内容中的域名无关。

4.1.4.2. Web Access (HTTP)
4.1.4.2. Web访问(HTTP)

With modern web servers and browsers supporting HTTP 1.1 [RFC 2616], the domain name used to access the site is available. Thus, web sites with different domain names can be accessed even if they are on the same machine at the same IP address. This is a small plus for name-based labeling since different categories of information on the same computer can be set up to be accessed via different domain names. But for a computer with any reasonable variety of data, the explosion of trying to differently name all types of data would require an unmanageable number of names.

随着现代网络服务器和浏览器支持HTTP 1.1[RFC 2616],用于访问该网站的域名可用。因此,可以访问具有不同域名的网站,即使它们位于同一台计算机上的同一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具有自动转发功能。因此,当您试图访问特定域名上的数据时,该域名上的服务器可以临时或永久地将您的浏览器重新定向到其他名称,也可以将您重新定向到数字IP地址,以便进行旁路名称过滤。

4.1.4.3. News (NNTP)
4.1.4.3. 新闻(NNTP)

Net news [RFC 977, 2980] uses hierarchically structured newsgroup names that are similar in appearance to domain names, except that the most significant label is on the left and the least on the right, the opposite of domain names. However, while the names are structured hierarchically, there is no central control. Instead, news servers periodically connect to other news servers that have agreed to exchange messages with them and they update each other on messages only in those newsgroups in which they wish to exchange messages.

Net news[RFC 977,2980]使用分层结构的新闻组名称,这些名称在外观上与域名相似,只是最重要的标签位于左侧,最不重要的标签位于右侧,与域名相对。然而,尽管名称是分层结构的,但没有中央控制。相反,新闻服务器定期连接到同意与它们交换消息的其他新闻服务器,并且它们只在希望交换消息的新闻组中更新消息。

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位的标签和在域名中添加标签一样不可能。

4.1.4.4. Internet Relay Chat (IRC)
4.1.4.4. 互联网中继聊天(IRC)

Internet Relay Chat [RFC 2810-2813] is another example of a service which uses a different name space. It uses a single level space of "channel names" that are meaningful within a particular network of IRC servers. Because it is not hierarchical, each server must know about all names, which limits the size of a network of servers.

Internet中继聊天[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频道名称是本地决定,不受任何全球“根”的约束,也不可从任何全球“根”访问,这一事实使得中央政治控制几乎不可能实现。

4.2. Content Filtering Using IP Addressing
4.2. 使用IP地址的内容过滤

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.

Internet所基于的Internet协议(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或Internet协议版本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.

使用寻址进行内容过滤的一个问题是,这是一种非常粗糙的技术。IP地址指的是网络接口,通常对应于整个计算机系统,该系统可以容纳多个网页、多组文件等,其中只有一小部分需要阻止或启用。越来越多地,单个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地址位的分配都不可能。

4.2.1. Hierarchical Routing
4.2.1. 分层路由

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.)

(上面的简化描述忽略了多重归宿和许多其他细节。)

4.2.2. IP Version 4 Addresses
4.2.2. IP版本4地址

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全局互联网地址中的一位用于内容过滤。这样的地址供不应求。这种分配实际上会将可用地址的数量减少一半。即使没有分层分配[RFC1715]和路由的低效性,也没有足够的地址来实现这一点。即使有,目前的数字也没有考虑到这一点,因此每个在互联网上拥有主机的组织都需要重新编号,这是一项耗资数十亿美元的艰巨任务。

Even if these problems were overcome, the allocation of even a single bit near the top of the address bits would likely double the number of routes in the default free zone. This would exceed the capacity of current routers and require the upgrade of thousands of them to new routers that do not exist yet at a gargantuan cost. The allocation of a bit near the bottom of the address bits would require world-wide local reconfiguration which would be impractical to require or enforce, even if the bit were available.

即使克服了这些问题,即使在地址位顶部附近分配一个位,也有可能使默认自由区中的路由数增加一倍。这将超过现有路由器的容量,需要将数千台路由器升级到新的路由器,而新的路由器目前还不存在,成本高昂。接近地址位底部的位的分配将需要全球范围的本地重新配置,这将是不切实际的要求或强制执行,即使该位可用。

And all this is if only a single bit is allocated to content labeling, let alone more than one. And we are assuming you would actually need 300 bits, more than there are!

所有这些都是如果只为内容标签分配了一个位,更不用说多个了。我们假设你实际上需要300位,比现在更多!

Basically, the idea is a non-starter.

基本上,这个想法是不可能实现的。

4.2.3. IP Version 6 Addresses
4.2.3. IP版本6地址

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地址用于标记。

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节),分配给标签的每个高位都会使路由系统的成本增加一倍。分配一位通常会使路由表的大小增加一倍。

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.

分配两个位将使它们乘以四。对于IPv6来说,分配300位我们认为是现实的全球标签所必需的,这在逻辑上是不可能的,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.

分配低位也有问题。有一些技术方案以与标签使用不兼容的方式使用底部64位[RFC 2374]。所以它可能必须是“中间位”(实际上是上半部分的低位)。与IPv4一样,不可能在全球范围内实施这一点。如果可能的话,可以在那里分配一个或两个比特,这显然是不够的。

4.3. PICS Labels
4.3. 图片标签

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.

拥有多个PICS服务是相当合理的,这些服务总共提供300位或更多的标签信息。可以为每个感兴趣的社区提供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评级系统本质上是一个或多个维度的定义,以及可以在每个维度中分配给评级对象的数值范围。服务是标签的来源,其中标签包括实际评级。评级可以是具体的,也可以是一般的。特定评级仅适用于特定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-rating-service.example.net"
         labels for "ftp://movies.example.sex/raunchy-movie"
         ratings (sex 6 violence 1 language 8 drugs 2 Satanism 0))
        

Machine readable rating system descriptions include the range of values and set of dimensions provided. Additional information, such as beginning and ending time of validity, can be incorporated into labels.

机器可读评级系统描述包括提供的值范围和尺寸集。附加信息,如有效期的开始和结束时间,可纳入标签中。

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.

标签目前可以通过三种方式提供:(1)嵌入到HTML中,(2)在HTTP响应中提供数据,以及(3)与第三方分开。如果像上面列出的前两种方式一样,要求内容中嵌入标签或在返回数据时由源传输,则会产生分类粒度和强制语音问题。但是,如果以第三种方式使用,即独立的一方确定并提供内容标签,并且用户可以自由选择他们希望咨询的任何第三方或第三方,那么它可以支持大量类别、编辑和评估者并行存在。

Digital signatures are available to secure PICS Labels [PICS].

数字签名可用于保护PICS标签[PICS]。

5. Security Considerations
5. 安全考虑

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.

任何标记或分类方案都必须假设有人故意试图导致数据被错误标记和分类。这可能是由于特定标签的某些感知优势,或者仅仅是为了破坏系统。毕竟,如果信息源总是准确方便地标记发送的信息,那么安全性就会容易得多[RFC3514]。此类可执行性考虑将结合本文件中提到的各种机制进行讨论。

6. Conclusions
6. 结论

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.

在这样一个贫民区应该有什么样的材料是不可能达成全球协议的。在全世界范围内,使用单一类别或少数类别是荒谬的。在域名或IP地址级别上,实现一个合理大小的标签(可以包含世界上许多社区的标准,例如300位)在技术上是不可能的,并且在可预见的未来仍将如此。除了技术上的不可能之外,这种授权在某些司法管辖区将是一种非法的语音强制,并且会对域名或其他字符串名称造成严重的语言问题。

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.

然而,有可能出现过多独立审查员的概念,其中一些可能是政府机构,以及那些获取信息的人选择和利用这些审查员分配的评级的能力。

7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

[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.

PICS 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.

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]Postel,J.,“互联网协议”,STD 5,RFC 7911981年9月。

[RFC 977] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.

[RFC 977]Kantor,B.和P.Lapsley,“网络新闻传输协议”,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 15911994年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.和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.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可聚合全球单播地址格式”,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.,弗莱斯蒂克,H.,马斯特,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.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.,“简单邮件传输协议”,RFC 28212001年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 29802000年10月。

7.2. Informative References
7.2. 资料性引用
   [BT]           "British Telecom comments to U.S. Commerce
                  Department", February 20, 1998,
                  <http://www.ntia.doc.gov/ntiahome/domainname/
                  130dftmail/BT.htm>
        
   [BT]           "British Telecom comments to U.S. Commerce
                  Department", February 20, 1998,
                  <http://www.ntia.doc.gov/ntiahome/domainname/
                  130dftmail/BT.htm>
        

[CDA] "Reno v. American Civil Liberties Union", 117 S.Ct. 2329, June 26, 1997,

[CDA]“雷诺诉美国公民自由联盟”,华盛顿特区117号。1997年6月26日,2329,

   [COPAREPORT]   "Final Report of the COPA Commission to the U.S.
                  Congress", October 20, 2000,
                  <http://www.copacommission.org/report/
                  newtopleveldomain.shtml>
        
   [COPAREPORT]   "Final Report of the COPA Commission to the U.S.
                  Congress", October 20, 2000,
                  <http://www.copacommission.org/report/
                  newtopleveldomain.shtml>
        
   [GAO]          "GAO Report OGC-00-33R", July 7, 2000,
                  <http://www.gao.gov/new.items/og00033r.pdf>
        
   [GAO]          "GAO Report OGC-00-33R", July 7, 2000,
                  <http://www.gao.gov/new.items/og00033r.pdf>
        
   [GTLD-MOU]     "GTLD-MOU Policy Oversight committee RFC 97-02",
                  September 13, 1997,
                  <http://www.gtld-mou.org/docs/notice-97-02.html>
        
   [GTLD-MOU]     "GTLD-MOU Policy Oversight committee RFC 97-02",
                  September 13, 1997,
                  <http://www.gtld-mou.org/docs/notice-97-02.html>
        
   [HOUSEREPORT]  "U.S. House Commerce Committee report", 105th
                  Congress, October 5, 1998.
                  <http://www.epic.org/free_speech/censorship/
                  hr3783-report.html>
        
   [HOUSEREPORT]  "U.S. House Commerce Committee report", 105th
                  Congress, October 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] "Request for reconsideration from ICM Registry to
                  ICANN", December 15, 2000,
                  <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>
        
   [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>
        

[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 17151994年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.和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]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]Eastlake,第三届,D.,“域名系统安全扩展”,RFC 25351999年3月。

[RFC 2606] Eastlake, 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.

[RFC 2606]Eastlake,3rd,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]Connelly,D.和L.Masinter,“文本/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.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]   Congress weighs Net porn bills," CNET article,
                  February 10, 1998, <http://news.cnet.com/
                  news/0-1005-200-326435.html>
        
8. Acknowledgement
8. 确认

The contribution and efforts of Declan McCullagh, who wrote substantially all of sections 2 and 3 of this document, are gratefully acknowledged.

感谢Declan McCullagh的贡献和努力,他编写了本文件第2节和第3节的大部分内容。

9. Authors' Addresses
9. 作者地址

Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA

Donald E.Eastlake 3rd Motorola Laboratories美国马萨诸塞州米尔福德市海狸街155号,邮编01757

   Phone: +1-508-786-7554 (w)
          +1-508-634-2066 (h)
   EMail: dee3@torque.pothole.com
        
   Phone: +1-508-786-7554 (w)
          +1-508-634-2066 (h)
   EMail: dee3@torque.pothole.com
        
10. Full Copyright Statement
10. 完整版权声明

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编辑功能的资金目前由互联网协会提供。