本備忘錄的狀態(tài)

本文檔為Internet社區(qū)定義Internet標(biāo)準(zhǔn)協(xié)議，同時(shí)征求改進(jìn)意見和建議。關(guān)于本
協(xié)議的現(xiàn)狀和標(biāo)準(zhǔn)化狀態(tài)請(qǐng)參閱“Internet官方協(xié)議標(biāo)準(zhǔn)”(STD1)。本備忘錄的發(fā)布不受
任何限制。

版權(quán)聲明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.

摘要

本文檔描述如何使用HTTP/1.1的升級(jí)機(jī)制在一個(gè)現(xiàn)存的TCP連接上發(fā)起安全傳輸
層(TLS)。這樣就答應(yīng)安全的和不安全的HTTP通信共享同一個(gè)眾所周知的端口（在這
個(gè)例子中，http在80端口而不是在像https在443端口）。這種做法也支持“虛擬主
機(jī)”，因此一個(gè)HTTP+TLS服務(wù)器能區(qū)分發(fā)往在同一個(gè)ip地址上的幾個(gè)主機(jī)的消息。
HTTP/1.1[1]中將升級(jí)定義為逐跳的機(jī)制，本備忘錄也描述了用于跨越HTTP代理
建立端到端隧道的HTTPCONNECT機(jī)制。最后，本備忘錄為公用HTTP狀態(tài)碼和公用或
私有升級(jí)產(chǎn)品符號(hào)建立了新的IANA注冊(cè)。
本備忘錄不影響到當(dāng)前“https”URI方案的定義，該方案已經(jīng)定義了一個(gè)單獨(dú)的
名字空間（http://example.org/和https://example.org/不等價(jià)）。







目錄
1.動(dòng)機(jī) 2
2．介紹 3
2.1.相關(guān)術(shù)語 3
3.客戶請(qǐng)求升級(jí)到TLS之上的HTTP 3
3.1.可選的升級(jí) 3
3.2.強(qiáng)制升級(jí) 4
3.3服務(wù)器對(duì)升級(jí)請(qǐng)求的確認(rèn) 4
4服務(wù)器請(qǐng)求升級(jí)到TLS之上的HTTP 4
4.1選項(xiàng)通知 4
4.1強(qiáng)制通知 4
5通過代理的升級(jí) 5
6使用4xx（客戶錯(cuò)誤）狀態(tài)碼的原理 6
7IANA的考慮 6
7.1HTTP狀態(tài)碼登記 7
安全考慮 7
7.1https:URI方案含義 8
7.2CONNECT的安全考慮 8
參考 8
作者地址 9
附錄A　致謝 10
完整版權(quán)聲明 10
致謝 11


1.動(dòng)機(jī)
過去在SSL3[3]上配置HTTP是用一個(gè)唯一的URI及TCP端口號(hào)，這樣同單獨(dú)的
HTTP相區(qū)分。方案“http”意味著在80端口單獨(dú)的HTTP協(xié)議，而“https”表示在
443端口的SSL之上的HTTP協(xié)議。類似的，其它應(yīng)用協(xié)議（例如：snews，F(xiàn)TPs）為區(qū)
分安全和不安全的使用，要求使用二個(gè)端口號(hào)。這個(gè)方法使得可用的眾所周知的端口
數(shù)減半。
在1997年12月華盛頓特區(qū)IETF會(huì)議上，應(yīng)用區(qū)主管及IESG重申不贊成使用并行
的“安全”端口號(hào)。HTTP/1.1的升級(jí)機(jī)制可以在一個(gè)打開的HTTP連接上建立傳輸層安
全[6]。
自最近兩年來，大家已經(jīng)廣泛接受了這個(gè)建議，但對(duì)實(shí)現(xiàn)一個(gè)取代通常的用于網(wǎng)
絡(luò)瀏覽的443端口沒有多大愛好。實(shí)際上，本備忘錄不影響當(dāng)前對(duì)https:URI的解
釋。但是，在HTTP之上建立的新的應(yīng)用協(xié)議如Internet打印協(xié)議[7]，需要這樣的機(jī)
制使得IETF標(biāo)準(zhǔn)化進(jìn)程前進(jìn)一步。
升級(jí)機(jī)制也解決了“虛擬主機(jī)”問題。HTTP/1.1服務(wù)器不是給一個(gè)主機(jī)分配多個(gè)
IP地址，而是使用主機(jī)：頭來區(qū)分web服務(wù)。由于HTTP/1.1的使用日益流行，越來越
多的ISP提供基于名字的虛擬主機(jī)，使得IP地址空間不會(huì)馬上耗盡。
TLS（及SSL）和HTTP的早期版本一樣受制于：初始化的握手不指定需要的主機(jī)
名，而只依靠于IP地址。使用明文的HTTP/1.1升級(jí)：作為TLS握手的序幕，――基于
初始的主機(jī)：頭選擇證書，――可使得ISP同樣能提供基于名字的安全虛擬主機(jī)。
2．介紹
TLS又名SSL（安全套接字層），建立一個(gè)私有端到端連接，選項(xiàng)包括使用多種密碼系
統(tǒng)的相互之間的強(qiáng)認(rèn)證。開始時(shí)，一次握手過程使用三個(gè)子協(xié)議來設(shè)置一個(gè)記錄層，認(rèn)證
端點(diǎn)，設(shè)置參數(shù)，和報(bào)告錯(cuò)誤。然后，由一個(gè)分層記錄協(xié)議處理加密，壓縮和重組連接的
剩余部分。后者希望做成完全透明。例如，在TLS的記錄標(biāo)記或認(rèn)證和HTTP/1.1的大塊編
碼或認(rèn)證之間沒有關(guān)聯(lián)。
客房和服務(wù)器都能使用HTTP/1.1[1]升級(jí)機(jī)制（14.42節(jié)）來指示TLS安全連接是必要
的。本備忘錄定義了“TLS/1.0”升級(jí)記號(hào)和一個(gè)新的HTTP狀態(tài)碼，“426－需要升級(jí)”。
小節(jié)3和小節(jié)4描述了直接相連的客房和服務(wù)器的操作。如小節(jié)5中闡述的，在實(shí)施任
何操作之前中間代理必須建立端到端的隧道。
2.1.相關(guān)術(shù)語
在本文中的要害字“必須”，“必須不”，“要求”，“應(yīng)該”，“不應(yīng)該”和“可
能”的解釋見[RFC2119]。
3.客戶請(qǐng)求升級(jí)到TLS之上的HTTP
當(dāng)客戶發(fā)送一個(gè)有包含記號(hào)“TLS/1.0”的升級(jí)包頭的HTTP/1.1請(qǐng)求，它表示請(qǐng)
求服務(wù)器在轉(zhuǎn)換到TLS/1.0之后完成當(dāng)前的HTTP/1.1請(qǐng)求。
3.1.可選的升級(jí)
當(dāng)一個(gè)不安全的響應(yīng)可接受時(shí)，一個(gè)客戶在任何明文的HTTP請(qǐng)求期間可以要求轉(zhuǎn)
換到安全的操作流程：

GEThttp://example.bank.com/acct_stat.Html?749394889300HTTP/1.1
Host:example.bank.com
Upgrade:TLS/1.0
Connection:Upgrade

在這個(gè)例子中，服務(wù)器可以對(duì)明文的HTTP請(qǐng)求作正常響應(yīng)或是轉(zhuǎn)換到安全的操作中
（細(xì)節(jié)見下一小節(jié)）。
注重在HTTP/1.1[1]中定義“無論在HTTP/1.1消息中何時(shí)出現(xiàn)升級(jí)關(guān)健字，該關(guān)健字
必須出現(xiàn)在一個(gè)連接頭的域中（14.10小節(jié)）”。
3.2.強(qiáng)制升級(jí)
若無法接受一個(gè)不安全的響應(yīng)，客戶必須首先發(fā)送一個(gè)選項(xiàng)請(qǐng)求來完成到TLS/1.0的
切換（若可能的話）。

OPTIONS*HTTP/1.1
Host:example.bank.com
Upgrade:TLS/1.0
Connection:Upgrade

3.3服務(wù)器對(duì)升級(jí)請(qǐng)求的確認(rèn)
如HTTP/1.1[1]中定義的，假如服務(wù)器預(yù)備初始化TLS握手，必須發(fā)送中間的“101轉(zhuǎn)
換協(xié)議”且必須包括一個(gè)定義它要轉(zhuǎn)換到的協(xié)議棧記號(hào)的升級(jí)響應(yīng)頭：

HTTP/1.1101SwitchingPRotocols
Upgrade:TLS/1.0,HTTP/1.1
Connection:Upgrade

注重在101轉(zhuǎn)換協(xié)議升級(jí)頭中列出的協(xié)議記號(hào)定義了一個(gè)自底向上的棧。
如HTTP/1.1[1]，10.1.2小節(jié)中定義的：“服務(wù)器將在收到終止101響應(yīng)的空行后立
即將協(xié)議轉(zhuǎn)換至響應(yīng)的升級(jí)頭域定義的協(xié)議。
一旦TLS握手成功完成，服務(wù)器必須繼續(xù)對(duì)原來請(qǐng)求的應(yīng)答。任何TLS握手失敗必須
通過TLS錯(cuò)誤告警規(guī)范導(dǎo)致連接中斷，。
4服務(wù)器請(qǐng)求升級(jí)到TLS之上的HTTP
升級(jí)響應(yīng)頭域宣告一個(gè)服務(wù)器可能接受的協(xié)議升級(jí)。和“426升級(jí)請(qǐng)求”狀態(tài)碼相結(jié)
合，服務(wù)器能發(fā)送一個(gè)客戶必須接受的協(xié)議升級(jí)來完成請(qǐng)求。
4.1選項(xiàng)通知
如在HTTP/1.1[1]中定義的，服務(wù)器可以在任何除了101或426的響應(yīng)中包含一個(gè)升級(jí)
頭表示轉(zhuǎn)換到任何列出的協(xié)議（組合）。
4.1強(qiáng)制通知
服務(wù)器可以使用“426需要升級(jí)”表示沒有TLS無法完成客戶請(qǐng)求，這個(gè)響應(yīng)必須包含
一個(gè)定義了需要的TLS版本記號(hào)的升級(jí)頭域。

HTTP/1.1426UpgradeRequired
Upgrade:TLS/1.0,HTTP/1.1
Connection:Upgrade

服務(wù)器應(yīng)該在426響應(yīng)中包含一個(gè)消息體以一種可讀形式指示錯(cuò)誤原因和描述另外對(duì)用
戶可用的路線。
注重，即使客戶愿意使用TLS，它出必須使用在第3節(jié)中的操作來進(jìn)行；在426響應(yīng)之
后TLS握手不能馬上開始。
5通過代理的升級(jí)
作為一個(gè)逐跳的頭部，HTTP的每一對(duì)參加者間要協(xié)商升級(jí)。若一個(gè)用戶代理發(fā)送一個(gè)
帶升級(jí)頭的請(qǐng)求給代理，它要求的是在自己和代理之間的改變而不是端與端之間的改變。
因?yàn)門LS非凡要求端到端的連接提供認(rèn)證并防御中間人攻擊，本備忘錄定義了CONNECT
方法用以建立一個(gè)跨越代理的隧道。
隧道一旦建立，第3節(jié)描述的操作都可用于建立TLS連接。

5.1逐跳升級(jí)的含義
當(dāng)一個(gè)源服務(wù)器從代理收到一個(gè)升級(jí)頭并以101轉(zhuǎn)換協(xié)議響應(yīng)，它只是改變自己和代
理之間連接的協(xié)議。同樣，一個(gè)代理可以返回給客戶101響應(yīng)來改變?cè)撨B接上的協(xié)議，該
協(xié)議獨(dú)立于與源服務(wù)器通信的協(xié)議。
這種情況使得診斷426響應(yīng)變得更加復(fù)雜。由于升級(jí)是一個(gè)逐跳的頭部，一個(gè)不識(shí)別
426響應(yīng)的代理可能會(huì)刪去相隨的升級(jí)頭部，使得客戶無法決定如何進(jìn)行協(xié)議轉(zhuǎn)換。若客戶
端收到一個(gè)沒有相隨的升級(jí)頭部的426狀態(tài)碼，它將如5.2節(jié)中描述的那樣請(qǐng)求一個(gè)端到端
隧道連接并一直請(qǐng)求以獲得需要的升級(jí)信息。
這個(gè)端到端的升級(jí)定義是一個(gè)深思熟慮的選擇。這答應(yīng)代理每端的增量實(shí)施，和在級(jí)
聯(lián)的代理間的優(yōu)化協(xié)議，而無需知道改變之外的部分。

5.2用CONNECT請(qǐng)求一隧道

CONNECT方法請(qǐng)求代理代表它建立一個(gè)連接通道。請(qǐng)求命令行的請(qǐng)求URI部分總是如URI通
用語法[2]定義的一個(gè)‘a(chǎn)uthority'，該定義指明請(qǐng)求連接的目的主機(jī)名和端口號(hào)，由冒
號(hào)分隔：

CONNECTserver.example.com:80HTTP/1.1
Host:server.example.com:80

其它HTTP機(jī)制能和CONNECT方法一起正常使用――除了端到端的協(xié)議升級(jí)請(qǐng)求――由于必
須先建立隧道這是當(dāng)然的。
例如，proxyauthentication可被用來建立創(chuàng)建隧道的機(jī)構(gòu)：

CONNECTserver.example.com:80HTTP/1.1
Host:server.example.com:80
Proxy-Authorization:basicaGVsbG86d29ybGQ=

如同任何其它的管道HTTP/1.1請(qǐng)求，由隧道通過的數(shù)據(jù)可以在空行后立即發(fā)送。通常的警
告是：若最終的響應(yīng)是拒絕的話，數(shù)據(jù)可以被丟棄，若有超過一個(gè)TCP數(shù)據(jù)段未完成，則
連接可以不做任何響應(yīng)而被復(fù)位。

5.3使用CONNECT建立一個(gè)隧道
對(duì)CONNECT請(qǐng)求的任何成功（2xx）的響應(yīng)都表示代理已經(jīng)和被請(qǐng)求的主機(jī)及相應(yīng)端口
建立了連接，并且已經(jīng)切換到在同該服務(wù)器的連接上開通隧道。
代理本身可能必須通過另一個(gè)代理才能到達(dá)請(qǐng)求的源服務(wù)器。在這種情況下，第一個(gè)
代理應(yīng)該生成同下一個(gè)代理建立連接的請(qǐng)求，請(qǐng)求一個(gè)同authority的通道。代理絕不能
對(duì)2xx狀態(tài)碼響應(yīng)，除非它已經(jīng)有一個(gè)到authority直接的或隧道的連接。
一個(gè)源服務(wù)器接收到對(duì)自己的連接請(qǐng)求可以用2xx狀態(tài)碼響應(yīng)，表示連接已經(jīng)建立。
假如在任何時(shí)候任何一方斷連，任何來自于該端的數(shù)據(jù)將傳送到另一方，之后另一方
的連接也被代理終止。若有到先斷連一端的數(shù)據(jù)未傳送，這些數(shù)據(jù)都將被丟棄。


6使用4xx（客戶錯(cuò)誤）狀態(tài)碼的原理
可靠的，共同協(xié)商的升級(jí)特性需要一個(gè)明確的失敗信號(hào)。426升級(jí)請(qǐng)求狀態(tài)碼答應(yīng)服務(wù)
器明確地聲明必須提供一個(gè)給定資源想要的協(xié)議擴(kuò)展。
起先看起來，響應(yīng)應(yīng)具有重定向的某種形式(3xx碼)，類似到一個(gè)https:URI的舊式重
定向。但不理解升級(jí)機(jī)制的用戶代理使得不能這樣做。
設(shè)想某個(gè)3xx代碼已被賦與“需要升級(jí)”的含義；一個(gè)不能識(shí)別它的用戶代理將把它
當(dāng)做300。它可能在響應(yīng)中尋找一個(gè)“Location”頭并試圖重復(fù)對(duì)頭部域中的URL的請(qǐng)求。
由于它不知道升級(jí)以合并TLS層，它最終在新的URL上會(huì)再次失敗。

7.IANA的考慮
如BCP26[10]中描述的，IANA將為二種名字空間登記：
HTTP狀態(tài)碼
HTTP升級(jí)記號(hào)

7.1HTTP狀態(tài)碼登記
HTTP狀態(tài)碼的登記定義了在HTTP響應(yīng)的狀態(tài)行中的狀態(tài)碼記號(hào)。這個(gè)名字空間的初始
值是由這些定義的：
1. HTTP/1.1標(biāo)準(zhǔn)草案
2. Web分布式創(chuàng)作及版本[4][定義420-424]
3. WebDAV高級(jí)集合[5]（正在制訂）[定義425]
4. 第6節(jié)[定義426]
要加入到該名字空間的值應(yīng)該以標(biāo)準(zhǔn)記錄文檔格式提交IETF應(yīng)用組。任何這種文檔應(yīng)該通
過HTTP/1.1[1]草案的狀態(tài)詞“過時(shí)”或“更新”使得可追蹤來源。

7.2HTTP升級(jí)記號(hào)登記

HTTP升級(jí)記號(hào)登記為產(chǎn)品記號(hào)定義了名字空間，該名字空間用于在升級(jí)HTTP頭部域中
分辯協(xié)議。每一個(gè)登記的記號(hào)應(yīng)該同一個(gè)或一組規(guī)范相聯(lián)系并有相聯(lián)系的信息。
HTTP/1.1[1]標(biāo)準(zhǔn)草案定義了這些遵從產(chǎn)品生產(chǎn)的記號(hào)：
產(chǎn)品（prodUCt）=記號(hào)["/"產(chǎn)品版本]
產(chǎn)品版本=記號(hào)

如BCP26[10]中描述的，登記應(yīng)該基于先來先服務(wù)的原則。這些定義不需要是IETF文
檔或是IESG關(guān)注的課題，但應(yīng)該遵守下列原則：
1. 一個(gè)記號(hào)一旦登記，就永遠(yuǎn)是登記了的。
2. 登記必須指定一個(gè)負(fù)責(zé)登記的團(tuán)體。
3. 登記必須指定一個(gè)聯(lián)系辦法。
4. 登記必須指定記號(hào)需要的文檔。
5. 負(fù)責(zé)的團(tuán)體可以隨時(shí)改變登記項(xiàng)。IANA將記錄下所有這種改變，并使它對(duì)需要的人可
用。
6. 對(duì)一個(gè)“產(chǎn)品”記號(hào)第一次登記負(fù)責(zé)的團(tuán)體在他們能夠登記前必須同意同“產(chǎn)品”記號(hào)
一起的“版本”記號(hào)的晚些時(shí)候的登記。
7. 若確實(shí)需要，IESG可以重新指定一個(gè)記號(hào)的負(fù)責(zé)團(tuán)體。通常這只是在負(fù)責(zé)團(tuán)體無法聯(lián)
系到時(shí)才會(huì)這樣。

本規(guī)范定義協(xié)議記號(hào)“TLS/1.0”作為TLS協(xié)議[6]定義的協(xié)議的標(biāo)識(shí)符號(hào)。
并不要求升級(jí)記號(hào)的定義是公眾可用的，但登記的聯(lián)系信息應(yīng)該是。

8.安全考慮
潛在的中間人攻擊（刪除升級(jí)頭部）和目前http/https混用一樣：
.移去升級(jí)頭與重寫網(wǎng)頁來將https://links改變?yōu)閔ttp://links類似。
.只有在服務(wù)器首先通過安全或不安全的通道公開這類信息才會(huì)造成這種風(fēng)險(xiǎn)。
.若客戶知道服務(wù)器可處理TLS，它就會(huì)堅(jiān)持發(fā)送不帶選項(xiàng)如OPTIONS的升級(jí)請(qǐng)求。
.最后如https:定義警告的，“用戶應(yīng)該仔細(xì)檢查服務(wù)器提供的證書以確定是否符合他
們的期望。

此外，對(duì)于未明確激活TLS的客戶，服務(wù)器可在響應(yīng)中使用除了101或426的升級(jí)頭來
通告TLS能力。既然TLS能力應(yīng)該作為服務(wù)器的特性而不是就在手邊的資源，它應(yīng)一次發(fā)送
就足夠，讓客戶知道這個(gè)事實(shí)以在需要時(shí)使用。

8.1https:URI方案含義

本備忘錄沒有影響‘https’的含義，廣泛采用的超文本內(nèi)容可以使用‘http’來區(qū)分
安全和不安全的資源。
連接時(shí)安全特性的選擇留給客戶和服務(wù)器。這答應(yīng)每一方用任何可用的信息作出決
定。例如，用戶代理可以依靠有關(guān)網(wǎng)絡(luò)安全方面的用戶設(shè)置，如“對(duì)不在我的本地網(wǎng)絡(luò)上
的所有POST操作都要求使用TLS”，或服務(wù)器可應(yīng)用如‘本頁面的FORM的提交和處理必須
用TLS’等資源存取規(guī)則。

8.2CONNECT的安全考慮

一個(gè)類屬的TCP通道是布滿安全風(fēng)險(xiǎn)的。首先，這種授權(quán)應(yīng)該被限制在一小部分端
口。這里定義的升級(jí)機(jī)制只是在80端口的隧道上需要。第二，既然隧道數(shù)據(jù)對(duì)代理不透
明，對(duì)其它眾所周知和保留端口的隧道有額外的風(fēng)險(xiǎn)。例如，假定一個(gè)HTTP客戶連接到25
端口，他可以通過SMTP傳播垃圾郵件。

參考
[1]Fielding,R.,Gettys,J.,Mogul,J.,Frystyk,H.,Masinter,L.,
Leach,P.andT.Berners-Lee,"HypertextTransferProtocol--
HTTP/1.1",RFC2616,June1999.

[2]Berners-Lee,T.,Fielding,R.andL.Masinter,"URIGeneric
Syntax",RFC2396,August1998.

[3]Rescorla,E.,"HTTPOverTLS",RFC2818,May2000.

[4]Goland,Y.,Whitehead,E.,Faizi,A.,Carter,S.andD.Jensen,
"WebDistributedAuthoringandVersioning",RFC2518,February
1999.

[5]Slein,J.,Whitehead,E.J.,etal.,"WebDAVAdvancedCollections
Protocol",WorkInProgress.

[6]Dierks,T.andC.Allen,"TheTLSProtocol",RFC2246,January
1999.

[7]Herriot,R.,Butler,S.,Moore,P.andR.Turner,"Internet
PrintingProtocol/1.0:EncodingandTransport",RFC2565,April
1999.

[8]Luotonen,A.,"TunnelingTCPbasedprotocolsthroughWebproxy
servers",WorkInProgress.(Alsoavailablein:Luotonen,Ari.
WebProxyServers,Prentice-Hall,1997ISBN:0136806120.)

[9]Rose,M.,"WritingI-DsandRFCsusingxml",RFC2629,June
1999.

[10]Narten,T.andH.Alvestrand,"GuidelinesforWritinganIANA
ConsiderationsSectioninRFCs",BCP26,RFC2434,October1998.

[11]Bradner,S.,"KeyWordsforuseinRFCstoIndicateRequirement
Levels",BCP14,RFC2119,March1997.

作者地址
RohitKhare
4KAssociates/UCIrvine
3207PaloVerde
Irvine,CA92612
US

Phone:+16268067574
EMail:rohit@4K-associates.com
URI:http://www.4K-associates.com/

ScottLawrence
AgranatSystems,Inc.
5ClocktowerPlace
Suite400
Maynard,MA01754
US

Phone:+197846100
EMail:lawrence@agranat.com
URI:http://www.agranat.com/

附錄A　致謝
TheCONNECTmethodwasoriginallydescribedinaWorkinProgress
titled,"TunnelingTCPbasedprotocolsthroughWebproxyservers",
[8]byAriLuotonenofNetscapeCommunicationsCorporation.Itwas
widelyimplementedbyHTTPproxies,butwasnevermadeapartofany
IETFStandardsTrackdocument.ThemethodnameCONNECTwasreserved,
butnotdefinedin[1].

Thedefinitionprovidedhereisderiveddirectlyfromthatearlier
memo,withsomeeditorialchangesandconformancetothestylistic
conventionssinceestablishedinotherHTTPspecifications.

AdditionalThanksto:

oPaulHoffmanforhisworkontheSTARTTLScommandextensionfor
ESMTP.
oRoyFieldingforassistancewiththerationalebehindUpgrade:
anditsinteractionwithOPTIONS.
oEricRescorlaforhisworkonstandardizingtheexistinghttps:
practicetocomparewith.
oMarshallRose,forthexml2rfcdocumenttypedescriptionandtools
[9].
oJimWhitehead,forsortingoutthecurrentrangeofavailableHTTP
statuscodes.
oHenrikFrystykNielsen,whoseworkontheMandatoryextension
mechanismpointedoutahop-by-hopUpgradestillrequires
tunneling.
oHaraldAlvestrandforimprovementstothetokenregistration
rules.

完整版權(quán)聲明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseeXPlainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurpoSEOf
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.