RFC3920_XMPP核心

1、RFC3920 Created by admin. Last edited by yizhonglee, 148 days ago. Viewed 14,053 times. #92 diff history edit rdf labels Category:已 翻譯attachments 本文的英文原文來自RFC 3920網(wǎng)絡工作組P. Saint-Andre, Ed.申請討論: 3920Jabber 軟件基金會類別: 標準跟蹤2004年10月可擴展的消息和出席信息協(xié)議 (XMPP): 核心協(xié)議關(guān)于本文的說明本文為互聯(lián)網(wǎng)社區(qū)定義了一個互聯(lián)網(wǎng)標準跟蹤協(xié)議，并且申請討論協(xié)議和提出了改進的建議。請

2、參照“互聯(lián)網(wǎng)官方協(xié)議標準”的最新版本（STD 1）獲得這個協(xié)議的標準化進程和狀態(tài)。本文可以不受限制的分發(fā)。版 權(quán)聲明本文版權(quán)屬于互聯(lián)網(wǎng)社區(qū) (C) The Internet Society (2004).摘要本文定義了可擴展消息和出席信息協(xié)議（XMPP）的核心功能，這個協(xié)議采用XML流實現(xiàn)在任意兩個網(wǎng)絡終端接近 實時的交換結(jié)構(gòu)化信息。XMPP提供一個通用的可擴展的框架來交換XML數(shù)據(jù)，它主要用來建立即時消息和出席信息應用以實現(xiàn) RFC 2779 的需求。目錄 1. 緒 論2. 通 用的架構(gòu)3. 地 址空間4. XML 流5. TLS 的使用6. SASL 的使用7. 資 源綁定8. 服 務器回

3、撥9. XML 節(jié)10. 服 務器處理XML節(jié)的規(guī)則11. XMPP中的 XML用法12. 核心的兼容性要 求13. 國 際化事項14. 安 全性事項15. IANA 事項16. 參 考1. Nodeprep2. Resourceprep3. XML 規(guī)劃4. 核心Jabber 協(xié)議和XMPP的 不同貢 獻者致 謝作 者地址完 整的版權(quán)聲明1. 緒論1.1. 概覽XMPP是一個開放式的XML協(xié)議，設計用于準 實時消息和出席信息以及請求-響應服務。其基本的語法和語義最初主要是由Jabber開放源代碼社區(qū)于1999年開發(fā)的。2002年，XMPP工作組被 授權(quán)接手開發(fā)和改編Jabber協(xié)議以適應IE

4、TF的即時消息和出席信息技術(shù)。作為XMPP工作組的成果，本文定義了 XMPP 1.0 的核心功 能；在 RFC 2779 IMP-REQS 中指定的提供即時消息和出席信息功能的擴展，定義在 XMPP-IM 協(xié)議 the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence 中。 1.2. 術(shù)語本文中大寫的關(guān)鍵字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "S

5、HALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和 "OPTIONAL" 的確切含義符合 BCP 14, RFC 2119 TERMS. 2. 通用的架構(gòu) 2.1. 概覽盡管XMPP沒有指定任何特定的網(wǎng)絡結(jié)構(gòu)，但它通常 是采用客戶-服務器 架構(gòu)進行實現(xiàn)，其中客戶端通過TCP方式使用XMPP訪問服務器，服務器之間也采用TCP方式進行通信。以下是這一架構(gòu)的抽象的示意圖 (這里 "-" 表示使用 XMPP

6、通訊， "=" 表示可使用任 何協(xié)議通訊)。C1-S1-S2-C3          |C2-+-G1=FN1=FC1符號的含義如下: · C1, C2, C3 = XMPP 客戶端· S1, S2 = XMPP 服務器· G1 = 一個XMPP和外部（非XMPP）消息網(wǎng)絡之間進行“翻譯”的網(wǎng)關(guān)· FN1 = 一個外部消息網(wǎng)絡· FC1 = 外部消息網(wǎng)絡上的一個客戶端2.2. 服務器服務器充當XMPP通信的一 個智能抽象層，它

7、主要負責： · 對受驗證的客戶端，服務器以及其他實體之間以XML流形式的連接和會話進行管理。· 在這些實體間使用XML流對合理編址的XML節(jié)（第九章）進行路由大部分 XMPP 兼容的服務器也負責存儲客戶端使用的數(shù)據(jù) (比如基于XMPP協(xié)議的及時消息應用中的聯(lián)系人名單); 在這種情況下， XML 數(shù)據(jù)直接服務器來處理，而不需要轉(zhuǎn)發(fā)到其他實體。 2.3. 客戶端大部分客戶端通過 TCP 連接直接連到服務器，并通過XMPP獲得由服務器以及聯(lián)合服務器所提供的全部功能。多個不同資源（比如不同的設備和地點）的客戶端_可以_同時登陸并且并 發(fā)的連接到一個服務器，每個不同資源的客戶端通過X

8、MPP地址的資源標識符來區(qū)分（比如<nodedomain/ home> 和 <nodedomain/work>），參見地址空間（第三章）。_建議_的客戶端和服務器連接的端口是 5222 ，這個端口已經(jīng)在 IANA（在第十五章第九節(jié)查閱端口號碼） 注冊了。. 2.4. 網(wǎng)關(guān)網(wǎng)關(guān)是一個特殊用途的服務器端的服務，主要功能是把 XMPP 翻譯成外部(非XMPP)消息系統(tǒng)，并把返回的消息翻譯成 XMPP 。例如到 email（參見 SMTP ），IRC（參見 IRC ），SIMPLE（參見 SIMPLE ），SMS 的網(wǎng)關(guān)；還有和別的消息服務的網(wǎng)關(guān)，比如AIM，ICQ，MSN M

9、essenger，Yahoo! Instant Messenger。網(wǎng)關(guān)和服務器之間的通信，網(wǎng)關(guān)和外部消息系統(tǒng)的通信，不在本文描述范圍之內(nèi)。 2.5. 網(wǎng)絡因為每個服務器都是由一個網(wǎng)絡地址來標識的并且服務器之間的通信是 客戶-服務器 協(xié)議的直接擴展，實際上整個系統(tǒng)是由很多互通的服務器構(gòu)成的。例如， <juliet> 可以和 <romeo> 交換消息,出席信息和其他信息。這種模式常見于那些需要使網(wǎng)絡地址標準化的協(xié)議（比如 SMTP ）。任意兩個服務器之間的通信是可選（OPTIONAL）的。如果被激活，那么這種通信應該（SHOULD）通過 XML 流綁定到 TCP 連接上進

10、行。建議的（RECOMMENDED）服務器之間的連接端口為 5269 ，這個端口號已經(jīng)在 IANA （在第十五章第九節(jié)查閱端口號碼）注冊了。3. 地址空間3.1. 概覽一個實體可以是任何一個被認為是一個網(wǎng)絡端點的東西(例如網(wǎng)絡上的一個 ID )，而且它是通過XMPP進行通信的。所有這些實體都有一個具有唯一性的地址， 并符合 RFC 2396 URI規(guī)范要求的格式。由于歷史原因，一個 XMPP 實體的地址被稱為 Jabber Identifier 或 JID 。一個合法的 JID 包括一組排列好的元素，包括域名（domain identifier），節(jié)點名（node identifier），和資

11、源名（resource identifier）。JID的語法定義，使用 ABNF 中的 Augmented Backus-Naur 格式。（IPv4 地址和 IPv6地址規(guī)則在 附錄B 中的 IPv6 中定義；確定節(jié)點規(guī)則的合法字符順序由 附錄A 的 STRINGPREP 的 Nodeprep 部分來定義；確定資源規(guī)則的合法字符順序由 附錄B 的 STRINGPREP 的Resourceprep 部分來定義；子域名規(guī)則參考 IDNA 中關(guān)于國際域名標簽的描述。）。jid = node "" domain "/" resource domain = fqd

12、n / address-literalfqdn = (sub-domain 1*("." sub-domain)sub-domain = (internationalized domain label)address-literal = IPv4address / IPv6address所有 JID 都是基于上述的結(jié)構(gòu)。類似 <userhost/resource> 這種結(jié)構(gòu)，最常用來標識一個即時消息用戶，這個用戶所連接的服務器，以及這個用戶用于連接的資源（比如特定類型的客戶端軟件）。不過,節(jié)點類型不是客戶端 也是有可能的，比如一個用來提供多用戶聊天服務的特定的聊

13、天室，地址可以是 <roomservice> （這里 “room“ 是聊天室的名字而 ”service“ 是多用戶聊天服務的主機名），而加入了這個聊天室的某個特定的用戶的地址則是 <roomservice/nick> （這里 ”nick“ 是用戶在聊天室的昵稱）。許多其他的 JID 類型都是可能的（例如 <domain/resource> 可能是一個服務器端的腳本或服務）。一個 JID 的每個合法部分（節(jié)點名，域名，資源名）的長度不能（MUST NOT）超過 1023 字節(jié)。也就是整體長度（包括 '' 和 '/' ）不能超過

14、3071 字節(jié)。3.2. 域名域名是一個主要的ID并且是 JID 中唯一必需（REQUIRED）的元素（一個純粹的域名也是一個合法的 JID）。它通常代表網(wǎng)絡的網(wǎng)關(guān)或者“主”服務器，其他實體通過連接它來實現(xiàn) XML 轉(zhuǎn)發(fā)和數(shù)據(jù)管理功能。然而，由一個域名標識引用的實體，并非總是一個服務器，它也可能是一個服務器的子域地址，提供額外的功能（比如多用戶聊天服務，用戶 目錄，或一個到外部消息系統(tǒng)的網(wǎng)關(guān)）。每個服務器或者服務的域名，可以（MAY）是一個 IP 地址，但應該（SHOULD）是一個完全合法的域名(參見 DNS).一個域名ID必須(MUST)是 IANA 里定義的“國際化域名”，并且按 STRI

15、NGPREP中的 NAMEPREP profile進行成功的字符轉(zhuǎn)換。在比較兩個域名ID之前，服務器必須(MUST),客戶端應該(SHOULD)首先按照 Nameprep profile(定義在IANA中) 來轉(zhuǎn)換每個域名的字符。 3.3. 節(jié)點名節(jié)點名是一個可選（OPTIONAL）的第二 ID，放在域名之前并用符號""分開.它通常表示一個向服務器或網(wǎng)關(guān)請求和使用網(wǎng)絡服務的實體(比如一個客戶端),當然它也能夠表示其他的實體(比如在 多用戶聊天系統(tǒng)中的一個房間). 節(jié)點名所代表的實體，它的地址依賴于一個特定的域名;在 XMPP 的即時消息和出席信息應用系統(tǒng)中，這個地址是“純

16、JID” <nodedomain> 中的一部分。一個節(jié)點名必須按 STRINGPREP 中的 Nodeprep profile 進行成功的字符轉(zhuǎn)換。在比較兩個節(jié)點ID之前，服務器必須（MUST）,客戶端應該(SHOULD)首先按 Nodeprep profile 轉(zhuǎn)換每個ID的字符。 3.4. 資源名資源名是一個可選的第三 ID,它放在域名的后面并由符號"/"分開。資源名可以跟在 <nodedomain>后面也可以跟在 <domain> 后面。它通常表示一個特定的會話，連接（比如設備或者所在位置），或者一個附屬于某個節(jié)點ID實體相關(guān)實體的

17、對象（比如多用戶聊天室中的一個參加者）。對 于服務器和和其他客戶端來說，資源名是不透明的。當它提供必需的信息以完成資源綁定（參見第七章）的時候，通常是由客戶端來實現(xiàn)的（盡管可以由客戶端向服 務器請求完成），然后顯示為“已連接的資源”。一個實體可以(MAY)并發(fā)維護多個已連接的資源。每個已連接的資源由不同的資源ID來區(qū)分。一個資源名必須（MUST）按 STRINGPREP 中的 Resourceprep profile 進行成功的格式化。在比較兩個資源ID之前，服務器必須（MUST）,客戶端應該(SHOULD)首先按 Resourceprep profile 轉(zhuǎn)換每個ID的字符。 3.5. 地址

18、的確認在 SASL （見第六章）握手之后（如果必要的話，也在資源綁定（見第七章）之后），正在接收流信息的實體必須（MUST）確認初始實體的 ID 。對于服務器間的通信，在 SASL 握手時，如果沒有指明授權(quán)的ID，這個初始的實體應該（SHOULD）是經(jīng)過認證實體（參見 簡單認證和安全層協(xié)議 SASL 中的定義）授權(quán)的ID（見第六章）。對于客戶端和服務器的通信，在 SASL 握手時，如果沒有指明授權(quán)的ID，“純 JID” (<nodedomain>)應該（SHOULD）是經(jīng)過認證實體（參見 SASL 中的定義）授權(quán)的ID，“全 JID” (<nodedomain/resourc

19、e>)的資源ID部分應該（SHOULD）是由客戶端和服務器在資源綁定的時候商定的（參見第七 章）。接收的實體必須（MUST）確保結(jié)果JID（包括節(jié)點名，域名，資源名以及分隔符）與本章前面部分描述的規(guī)則和格式相一致；為了滿足這些約束條件，接收實 體可能（MAY）需要把初始實體的發(fā)送方 JID 替換成接收實體認可的規(guī)范 JID。4. XML流4.1. 概覽兩個基本概念，XML流和XML節(jié)，使得在出席信息已知的實體之間，異步交換低負載的結(jié)構(gòu)化信息成為可能。這兩個術(shù)語定義如下：XML流的定義：一個XML流是一個容器，包含了兩個實體之間通過網(wǎng)絡交換的XML元素。一個XML流是由一個XML打開標簽

20、<stream> (包含適當?shù)膶傩院兔挚臻g聲明)開始的,流的結(jié)尾則是一個XML關(guān)閉L標簽 </stream> 。在流的整個生命周期，初始化它的實體可以通過流發(fā)送大量的XML元素，用于流的握手(例如 TLS 握手(第五章) 或 SASL 握手(第六章)或XML節(jié)（在這里指符合缺省名字空間的元素,包括<message/>,<presence/>, 或 <iq/> 元素）?！俺跏嫉牧鳌庇沙跏蓟瘜嶓w（通常是一個客戶端或服務器）和接收實體（通常是一個服務器）握手，從接收實體來看，它就是那個初始實體的"會話".初 始化流允許

21、從初始化實體到接收實體的單向通信;為了使接收實體能夠和初始實體交換信息,接收實體必須發(fā)起一個反向的握手(應答流).XML節(jié)的定義: 一個XML節(jié)是一個實體通過 XML 流向另一個實體發(fā)送的結(jié)構(gòu)化信息中的一個離散的語義單位。一個XML直接存在于根元素<stream/>的下一級，并且如果這樣就能夠滿足 XML內(nèi)容的production 43,那么它被認為是均衡的.任何XML節(jié)都是從一個XML流的下一級的某個打開標簽（如 <presence>）開始，到相應的關(guān)閉標簽（如 </presence>）。一個XML節(jié)可以（MAY）包含子元素(相關(guān)的屬性,元素, 和 XML

22、 字符數(shù)據(jù)等) 以表達完整的信息.在這里定義的XML節(jié)僅限于<message/>, <presence/>, 和 <iq/> 元素，具體描述間見 XML Stanzas（第九章）；為TLS握手（第五章）、SASL握手（第六章）、服務器回撥（第八章）的需要而發(fā)送的XML元素，不被認為是一個XML節(jié)。設想一個客戶端和服務器會話的例子。為了連接一個服務器，一個客戶端必須（MUST）發(fā)送一個打開標簽<stream>給服務器，初始化一個 XML流，也可選擇（OPTIONAL）在這之前發(fā)送一段文本聲明XML版本和支持的字符集（參見文本聲明的內(nèi)容(第十一章第四

23、節(jié)); 也可看字符編碼(第十一章第五節(jié))）。視本地化策略和提供的服務而定，服務器應該（SHOULD）回復一個XML流給客戶端，同樣的，也可選擇在這之前發(fā) 送一段文本聲明。一旦客戶端完成了SASL握手（第六章），客戶端可以（MAY）通過流發(fā)送不限量的XML節(jié)給網(wǎng)絡中的任何接收者。當客戶端想關(guān)閉這個 流，它只需要簡單的發(fā)送一個關(guān)閉標簽</stream>給服務器（或者作為另一個選擇，可能由服務器關(guān)閉這個流）。然后，客戶端和服務器都應 該（SHOULD）徹底地終止這個連接（通常是一個TCP連接）。那些習慣認為XML是一個以文本為中心風格的人可能希望看看一個與服務器連接的客戶端會話，包含兩個

24、 打開-關(guān)閉 XML文檔：一個是從客戶端到服務器，一個是從服務器到客戶端。下圖中，根元素<stream/> 可以被認為是每個“文檔”的文檔實體，這兩個“文檔”通過累積那些在XML上傳輸?shù)腦ML節(jié)來搭建的。無論如何，下圖只是方便理解；實際上XMPP并不處理 文檔而是處理XML流和XML節(jié)。基本上，一個XML流相當于一個會話期間所有XML節(jié)的一個信封。我們可以簡單的把它描述成下圖：|-| <stream> |-| <presence> | <show/> | </presence> |-| <message to='foo&

25、#39;> | <body/> | </message> |-| <iq to='bar'> | <query/> | </iq> |-| |-| </stream> |-4.2. 綁定到TCP雖然有很多非必需的連接使用XML流來綁定TCP連接（兩個實體可以通過別的機制來互聯(lián)，比如通過HTPP連接輪詢），本規(guī)范只定義了 XMPP 到 TCP 的綁定。在客戶和服務器通信的過程中，服務器必須（MUST）允許客戶端共享一個TCP連接來傳輸XML節(jié)，包括從客戶端傳到服務器和從服務器傳到客戶 端。在服務器之間的

26、通信過程中，服務器必須（MUST）用一個 TCP連接 向?qū)Ψ桨l(fā)送 XML節(jié)，另一個 TCP連接（由對方初始化）接收對方的XML節(jié)，一共兩個 TCP連接。 4.3. 流的安全在XMPP 1.0中，當XML流開始握手時，TLS應該（SHOULD）按 第五章：TLS的使用 中的規(guī)定來使用，SASL必須（MUST）按 第六章：SASL的使用 中的規(guī)定來使用。盡管可能（MAY）存在某種共有的機制能夠保證雙向安全，但是“初始化流”（比如從初始化實體發(fā)給接收實體的流）和“應答流”（比如從接 收實體發(fā)給初始化實體的流）還是必須（MUST）安全的分開。在流被驗證之間，實體不應該（SHOULD NOT） 嘗試通過

27、流發(fā)送XML節(jié)（第九章）；就算它這樣做了，對方的實體也不能（MUST NOT）接受這些XML節(jié)，并且應該（SHOULD）返回一個 <not-authorized/> 的流錯誤信息并且終止當前TCP連接上雙方的XML流；注意，這僅僅是針對XML節(jié)（包含在缺省命名空間中的 <message/>, <presence/>, 和 <iq/> 元素），而不是指那些用于 TLS握手（第五章）、SASL握手（第六章）握手的流。 4.4. 流屬性流元素的屬性如下: · to - 'to'屬性應該（SHOULD）僅用于從初始化實體到接收實

28、體的 XML流的頭，并且必須（MUST）設成為接收實體提供服務的主機名。注意，不應該（SHOULD NOT）有 'to'屬性出現(xiàn)在接收實體應答初始實體的 XML流的頭中；無論如何，如果'to'屬性出現(xiàn)在應答流中，初始化實體應該（SHOULD）忽略它。· from - 'from'屬性應該（SHOULD）僅用于接收實體應答初始化實體的 XML流的頭，并且必須（MUST）設成為接收實體（正在給初始實體授權(quán)）提供服務的主機名。注意，不應該（SHOULD NOT）有 'from'屬性出現(xiàn)在初始實體發(fā)送給接收實體的 XML流的頭中

29、；無論如何，如果'from'屬性出現(xiàn)在初始化流中，接收實體應該（SHOULD）忽略它。· id - 'id'屬性應該（SHOULD）僅用于接收實體發(fā)送給初始化實體 XML流的頭。這個屬性是一個由接收實體創(chuàng)建的具有唯一性的ID,一個初始實體和接收實體之間的會話ID，并且它在接收方的應用程序中（通常是一個服務 器）必須（MUST）是唯一的。注意，這個流 ID 必須是足夠安全的，所以它必須是不可預知的和不可重復的（參見 RANDOM 了解如何獲得隨機性以保證安全性）。不應該（SHOULD NOT）有 'id'屬性出現(xiàn)在初始實體發(fā)送給接收實體的

30、 XML流的頭中；無論如何，如果'id'屬性出現(xiàn)在初始化流中，接收實體應該（SHOULD）忽略它。· xml:lang - 'xml:lang'屬性（定義在XML中的第二章第十二節(jié)）應該（SHOULD）包含在初始化實體發(fā)給接收實體的 XML流的頭中，以指定在流中傳輸?shù)目勺xXML字符所使用的缺省語言。如果這個屬性出現(xiàn)了，接收實體應該（SHOULD）記住它的值，作為初始化流和應答 流的缺省屬性；如果這個屬性沒有出現(xiàn)，接收實體應該（SHOULD）用一個可配置的缺省值用于雙方的流，這個屬性值必須（MUST）在應答流的頭中傳達。 對于所有初始化流中傳輸?shù)墓?jié)，如果

31、初始實體沒有提供'xml:lang'屬性，接收實體應該（SHOULD）應用缺省值；如果初始實體提供了 'xml:lang'屬性，接收實體不能（MUST NOT）修改或刪除它（參見第九章第一節(jié)第五小節(jié) xml:lang）。'xml:lang'屬性的值必須（MUST）是一個 NMTOKEN (定義在XML的第二章第三節(jié)) 并且必須（MUST）遵守 RFC 3066 LANGTAGS 規(guī)定的格式。· version - version屬性（最少需要"1.0"）為本規(guī)范中和流相關(guān)的協(xié)議提供了支持。關(guān)于這個屬性的生成和處理的詳

32、細規(guī)則將在下文中定義。我們現(xiàn)在可以總結(jié)如下: 初始化方 發(fā)給接收方接收方發(fā)給初始化方to接收 方的主機名忽略from忽略接 收方的主機名id忽略會話鍵值xml:lang缺省語言缺省語言version支持XMPP 1.0支持XMPP 1.04.4.1. 版本支持在這里XMPP的版本 是"1.0"；準確地說，這里囊括了和流相關(guān)的所有協(xié)議(TLS的使用 (第五章),SASL的使用(第六章), 和流錯誤(第四章第七節(jié))，以及三個定義好的XML節(jié)類型(<message/>,<presence/>,和 <iq/>)。XMPP版本號的編號順序

33、是“<主版本號>.<副版本號>”。主版本和副版本號必須（MUST）是獨立的 整數(shù)并且每個號碼可以（MAY）單獨以阿拉伯數(shù)字增長。這樣，"XMPP 2.4"的版本將比"XMPP 2.13"更低。號碼前面 的“0”(比如XMPP 6.01)必須(MUST)被接收方忽略并且不能(MUST NOT)被發(fā)送出去.如果流和節(jié)的格式或者必需的處理方式有了顯著的改變，以至于老版本的實體如果只是簡單的忽略它不理解的節(jié)和屬性并且繼續(xù)像老版本一樣的處理方式，會使得老 版本的實體不能夠和新版本的實體交互，只有在這時候主版本號才應該（SHOULD）增加。副

34、版本號顯示新的性能，它必須（MUST）被副版本號更低的實體 忽略，但被高（副）版本號的實體用于了解信息。例如，一個副版本號顯示處理某種新定義的"type"屬性的值（用于message,presence或 IQ節(jié)）的能力；副版本號高的實體將會了解到與之通信的對方不能夠理解這個"type"屬性的值，所以將不會發(fā)送它。以下規(guī)則是用于'版本'屬性在實現(xiàn)流的頭信息時如何生成和處理: 1. 初始化實體必須（MUST）在初始化流的頭信息中把'版本'的值設置成它所支持的最高版本。（比如，如果最高版本支持就是本規(guī)范，那么它必須(MUST)

35、設置成"1.0"）.2. 接收實體必須（MUST）在應答流的頭信息中把'版本'的值設置成初始化實體所提供的版本或它所支持的最高版本,取其中版本號較低的那一個。接收實體必須 (MUST)把主版本號和副版本號作為數(shù)字來比較,而不是對"主版本號.副版本號"這個字符串進行比較.3. 如果在應答流的頭信息的版本號中至少有一個主版本號低于初始化流的頭信息的版本號,并且如前所述,新版本的實體不能夠和舊版本實體交互,初始化實體應該 (SHUOULD)生成一個<unsupported-version/>的流錯誤信息并終止XML流和它的TCP連接

36、。4. 如果一個實體收到一個頭信息中沒有'version'屬性的流，這個實體必須（MUST）把對方實體的'version'當成'0.0'并且在它發(fā)送的應 答流的頭中也不應該(SHOULD NOT)包含'version'屬性.4.5. 名字空間聲明流的元素必須(MUST)同時滿足一個流名字空間聲明和一個缺省名字空間聲明("名字空間聲明"定義在 XML 名字空間定義 XML-NAMES中).關(guān)于流名字空間和缺省名字空間的詳細信息,參考 名字空間的名字和前綴(第十一章第二節(jié)). 4.6. 流的特性如果初始化的實體在初

37、始化流的頭信息中設置'version'屬性的信息為"1.0",接收實體必須(MUST)向初始化實體發(fā)送一個 <features/> 子元素以聲明任何可供協(xié)商的流一級的特性(或者其他需要聲明的能力).目前,這僅用于聲明本文中定義的 TLS的使用(第五章),SASL的使用（第六章）和資源綁定(第七章),以及 XMPP-IM 中定義的會話的建立;無論如何,流特性這一功能將來可以用于聲明任何可協(xié)商的特性.如果一個實體不理解或支持安全特性,它應該(SHOULD)忽略它.如 果要在一個非安全相關(guān)的特性(比如資源綁定)被提議之前,完成一個或多個安全特性(比如T

38、LS和SASL)的協(xié)商,這個非安全相關(guān)的特性不應該 (SHOULD NOT)在相應的安全特性協(xié)商完畢之前被聲明. 4.7. 流錯誤流的根元素可以（MAY）包含一個 <error/> 子元素，由流的名字空間前綴作為它的前綴。這個"錯誤"子元素必須（MUST）由感知到發(fā)生了流級別錯誤的實體發(fā)送（通常是一個服務器而不是一個客戶 端）。 4.7.1. 規(guī)則以下規(guī)則適用于流級別的錯誤: · 它假定所有流級別的錯誤都是不可恢復的；所以，如果一個錯誤發(fā)生在流級別，發(fā)現(xiàn)這個錯誤的實體必須（MUST）發(fā)送一個流錯誤信息給另一個實體，發(fā)送一個 關(guān)閉標簽 </stre

39、am>，并終止這個流所在的TCP連接。· 如果這個錯誤發(fā)生在流剛開始設置的時候，接收實體必須（MUST）仍然發(fā)送一個開放標簽 <stream> ，并在流元素中包含一個<error/>的子元素，然后發(fā)送一個關(guān)閉標簽 </stream>，最后終止相應的TCP連接。在這種情況下，如果初始化實體在 'to' 屬性中提供了一個未知的主機名，服務器應該（SHOULD）在終止之前,先在流的頭信息的 'from' 屬性中提供一個服務器認證的主機名.4.7.2. 語法流錯誤的語法如下: <stream:error>

40、<defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> <text xmlns='urn:ietf:params:xml:ns:xmpp-streams' xml:lang='langcode'> OPTIONAL descriptive text </text> OPTIONAL application-specific condition element </stream:error> <error/>元素:&

41、#183; 必須(MUST)包含一個子元素以描述一個下文定義的節(jié)錯誤條件;這個子元素必須(MUST)符合'urn:ietf:params:xml:ns:xmpp-streams' 名字空間.· 可以(MAY)包含一個 <text/> 子元素,用XML字符數(shù)據(jù)描述錯誤的細節(jié);這個元素必須(MUST)符合'urn:ietf:params:xml:ns:xmpp-streams' 名字空間并且應該(SHOULD)擁有一個'xml:lang'屬性表明XML字符數(shù)據(jù)的自然語言。· 可以（MAY）包含一個子元素用于描述一個明確

42、的應用程序錯誤條件；這個元素必須（MUST）符合一個應用程序定義的名字空間，并且它的結(jié)構(gòu)是由那個名字 空間定義的。<text/> 元素是可選的（OPTIONAL）。如果有這個元素，它應該（SHOULD）僅用于提供描述或調(diào)試信息以補充一個已定義的條件或應用程序定義的條件。它不 應該（SHOULD NOT）被一個應用程序當成一個可編程的信息。它不應該（SHOULD NOT）被用于向用戶表達錯誤信息，但是可以（MAY）作為和條件元素相關(guān)的錯誤信息之外的附加說明。 4.7.3. 已定義的條件以下流級別的錯誤條件是已定義的: · <bad-format/> - 實體已經(jīng)

43、發(fā)送XML但是不能被處理;這個錯誤可以（可以）被更多特定的XML相關(guān)的錯誤替換，比如 <bad-namespace-prefix/>, <invalid-xml/>, <restricted-xml/>, <unsupported-encoding/>, 以及 <xml-not-well-formed/>,盡管更多特定的錯誤是首選的。· <bad-namespace-prefix/> - 實體發(fā)送的名字空間前綴不被支持，或者在一個需要某種前綴的元素中沒有發(fā)送一個名字空間前綴(參見 XML Namespace Na

44、mes and Prefixes (第十一章第二節(jié)).· <conflict/> - 服務器正在關(guān)閉為這個實體激活的流，因為一個和已經(jīng)存在的流有沖突的新的流已經(jīng)被初始化。· <connection-timeout/> - 實體已經(jīng)很長時間沒有通過這個流發(fā)生任何通信流量(可由一個本地服務策略來配置).· <host-gone/> - 初始化實體在流的頭信息中提供的'to'屬性的值所指定的主機已經(jīng)不再由這臺服務器提供· <host-unknown/> - 由初始化實體在流的頭信息中提供的 

45、9;to' 屬性的值和由服務器提供的主機名不一致.· <improper-addressing/> - 一個在兩臺服務器之間傳送的節(jié)缺少 'to' 或 'from' 屬性(或者這個屬性沒有值).· <internal-server-error/> - 服務器配置錯誤或者其他未定義的內(nèi)部錯誤,使得服務器無法提供流服務.· <invalid-from/> - 在'from'屬性中提供的 JID 或 主機名地址，和認證的 JID不匹配 或服務器之間無法通過SASL（或回撥）協(xié)商出

46、合法的域名，或客戶端和服務器之間無法通過它進行認證和資源綁定。· <invalid-id/> - 流 ID 或回撥 ID 是非法的或和以前提供的 ID 不一致.· <invalid-namespace/> - 流名字空間和 "/streams" 不相同或回撥名字空間和 "jabber:server:dialback" 不相同.(參考 XML Namespace Names and Prefixes (第十一章第二節(jié)).· <invalid-xml/&

47、gt; - 實體通過流發(fā)送了一個非法的XML給執(zhí)行驗證的服務器 (參考 Validation (第十一章第三節(jié)).· <not-authorized/> - 實體試圖在流被驗證之前發(fā)送數(shù)據(jù)或不被許可執(zhí)行一個和流協(xié)商有關(guān)的動作，接收實體在發(fā)送錯誤信息之前不允許（MUST NOT）處理厭惡的節(jié)。· <policy-violation/> - 實體違反了某些本地服務策略；服務器可以（MAY）選擇在 <text/> 元素或應用程序定義的錯誤條件（元素）中詳細說明策略。· <remote-connection-failed/>

48、 - 服務器無法正確連接到用于驗證或授權(quán)的遠程實體。· <resource-constraint/> - 服務器缺乏必要的系統(tǒng)資源為流服務。· <restricted-xml/> - 實體試圖發(fā)送受限的XML特性，比如一個注釋，處理指示，DTD，實體參考，或保留的字符(參考 Restrictions (第十一章第一節(jié)).· <see-other-host/> - 服務器將不提供服務給初始化實體但是把它重定向到另一臺主機；服務器應該（SHOULD）在<see-other-host/>元素的XML 字符數(shù)據(jù)中指明替代服務

49、器名或IP地址（它必須（必須）是合法的域名標識）。· <system-shutdown/> - 服務器正在關(guān)機并且所有激活的流正在被關(guān)閉。· <undefined-condition/> - 錯誤條件不在本文已定義的錯誤條件列表之中；這個錯誤條件應該（SHOULD）僅用于"應用程序定義條件"元素.· <unsupported-encoding/> - 初始化實體以一個服務器不不支持的編碼方式編碼了一個流(參照 Character Encoding (第十一章第五節(jié)).· <unsupporte

50、d-stanza-type/> - 初始化實體發(fā)送了一個流的一級子元素但是服務器不支持.· <unsupported-version/> - 由初始化實體在流的頭信息中指定的'version'屬性的值所指定的版本不被服務器支持;服務器可以(MAY)在<text/>元素中指定 一個它支持的版本號.· <xml-not-well-formed/> - 初始化實體發(fā)送了一個不規(guī)范的XML（參考XML）.4.7.4. 應用程序定義條件大家知道,應用程序可以(MAY)在error元素中包含一個適當名字空間的子元素來提供一個應用

51、程序定義流錯誤信息."應用程序定義"元素應該 (SHOULD)補充或甚至限定一個已定義的元素.所以 <error/> 元素將包含兩個或三個子元素:<stream:error> <xml-not-well-formed xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> <text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'> Some special applicati

52、on diagnostic information! </text> <escape-your-data xmlns='application-ns'/> </stream:error> </stream:stream>4.8. 簡化的流示例這里包含兩個簡化的例子，描述了基于流的客戶端在服務器上的“會話”(這里"C"表示從客戶端發(fā)給服務器,"S"表示從服務器發(fā)給客戶端);這些例子只是 用于舉例說明原理.一個基本的 "會話": C: <?xml version=

53、9;1.0'?> <stream:stream to='' xmlns='jabber:client' xmlns:stream='/streams' version='1.0'> S: <?xml version='1.0'?> <stream:stream from='' id='someid' xmlns='jabber:client' xmlns:stream='

54、/streams' version='1.0'> encryption, authentication, and resource binding . C: <message from='juliet' to='romeo' xml:lang='en'> C: <body>Art thou not Romeo, and a Montague?</body> C: </message> S: <message from=

55、'romeo' to='juliet' xml:lang='en'> S: <body>Neither, fair saint, if either thee dislike.</body> S: </message> C: </stream:stream> S: </stream:stream>一個不成功的 "會話" : C: <?xml version='1.0'?> <stream:stream to=''

56、 xmlns='jabber:client' xmlns:stream='/streams' version='1.0'> S: <?xml version='1.0'?> <stream:stream from='' id='someid' xmlns='jabber:client' xmlns:stream='/streams' version=&#

57、39;1.0'> encryption, authentication, and resource binding . C: <message xml:lang='en'> <body>Bad XML, no closing body tag! </message> S: <stream:error> <xml-not-well-formed xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> </stream:error> S: <

58、;/stream:stream>5. TLS 的使用5.1. 概覽XMPP包含的一個保證流安全的方法來防止篡改 和偷聽.這個傳輸層安全協(xié)議TLS的頻道加密方法, 模擬了類似的其他"STARTTLS"(見RFC 2595 USINGTLS)的擴展,如 IMAP IMAP, POP3 POP3, and ACAP ACAP."STARTTLS"的擴展名字空間是'urn:ietf:params:xml:ns:xmpp-tls'.一個給定域的管理員可以(MAY)要求客戶端和服務器通信以及服務器之間通信時使用TLS，或者兩者都要求?？蛻舳藨?/p>

59、（SHOULD）在嘗試完成 SASL （第六章）握手之前使用 TLS，服務器應該（SHOULD）在兩個域之間使用 TLS 以保證服務器間通信的安全。以下是使用規(guī)則: 1. 一個遵守本協(xié)議的初始化實體必須（MUST）在初始化流的頭信息中包含一個'version'屬性并把值設為“1.0”。2. 如果TLS握手發(fā)生在兩個服務器之間，除非服務器聲稱的DNS主機名已經(jīng)被解析(見第十四章第四節(jié) Server-to-Server Communications)，通信不能（MUST NOT）繼續(xù)進行。3. 當一個遵守本協(xié)議的接收實體接收了一個初始化流（它的頭信息中包含一個'versio

60、n'屬性并且值設為“1.0”），在發(fā)送應答流的的頭信息（其中包含 版本標記）之后，它必須發(fā)送（MUST）<starttls/>元素（名字空間為 'urn:ietf:params:xml:ns:xmpp-tls'） 以及其他它支持的流特性 。4. 如果初始化實體選擇使用TLS,TLS握手必須在SASL握手之前完成；這個順序用于幫助保護SASL握手時發(fā)送的認證信息的安全，同時可以在必要的時候 在TLS握手之前為SASL外部機制提供證書。5. TLS握手期間,一個實體不能（MUST NOT）在流的根元素中發(fā)送任何空格符號作為元素的分隔符（在下面的TLS示例中的任何

61、空格符都僅僅是為了便于閱讀）；這個禁令用來幫助確保安全層字節(jié)精 度。6. 接收實體必須（MUST）在發(fā)送<proceed/> 元素的關(guān)閉符號">" 之后立刻開始TLS協(xié)商。初始化實體必須（MUST）在從接收實體接收到<proceed/> 元素的關(guān)閉符號">" 之后立刻開始TLS協(xié)商。7. 初始化實體必須（MUST）驗證接收實體出示的證書；關(guān)于證書驗證流程參見Certificate Validation ( 第十四章第二節(jié))。8. 證書必須（MUST）檢查初始化實體(比如一個用戶)提供的主機名；而不是通過DNS系統(tǒng)解析出來的主機名；例如，如果用戶指定一個主機 名""而一個DNS SRV SRV查詢返回""，證書必須（MUST）檢查"".如果任何種類的XMPP實體（例 如客戶端或服務器）的JID出現(xiàn)在一個證書里，它必須（MUST）表現(xiàn)為一個別名實體里面的UTF8字符串，存在于subjectAltName之中。如 何使用 ASN.1 對象標識符 "id-on-xmppAd