RFC3920_XMPP中文翻譯規(guī)范.pdf

RFC3920 RFC3920 1 可擴(kuò)展的消息和出席信息協(xié)議可擴(kuò)展的消息和出席信息協(xié)議 XMPP XMPP 核心協(xié)議核心協(xié)議 Q QQ Q 44447 78 80 05 52 28 80 0 翻譯整理翻譯整理 中國海洋大學(xué)海大新星中國海洋大學(xué)海大新星 日期 日期 20112011 年年 8 8 月月 1515 日日起 起 20112011 年年 8 8 月月 3030 日日止止 RFC3920 RFC3920 2 目錄目錄 RFC3920 RFC3920 3 1 說明 1 11 1 關(guān)于本文的說明關(guān)于本文的說明 本文為互聯(lián)網(wǎng)社區(qū)定義了一個(gè)互聯(lián)網(wǎng)標(biāo)準(zhǔn)跟蹤協(xié)議 并且能夠根據(jù)討論和建議來提高和 完善 請參照 互聯(lián)網(wǎng)官方協(xié)議標(biāo)準(zhǔn) 的最新版本 STD 1 來獲得這個(gè)協(xié)議的標(biāo)準(zhǔn)化進(jìn) 程和狀態(tài) 本文可以不受限制的分發(fā) 1 21 2 版權(quán)聲明版權(quán)聲明 本文版權(quán)屬于互聯(lián)網(wǎng)社區(qū) C The Internet Society 2004 1 31 3 摘要摘要 本文定義了可擴(kuò)展消息和表示協(xié)議 XMPP 的核心功能 這個(gè)協(xié)議能夠在任意兩個(gè)網(wǎng) 絡(luò)終端間通過采用 XML 流來實(shí)現(xiàn)近乎實(shí)時(shí)交換的結(jié)構(gòu)化信息 XMPP 協(xié)議為交換的 XML 數(shù)據(jù)提供了一個(gè)通用的可擴(kuò)展框架 它主要用來建立即時(shí)通信和表示應(yīng)用以實(shí)現(xiàn) RFC 2779 的需求 2 2 緒論緒論 2 2 1 1 概覽概覽 XMPP 是一個(gè)開放式的 XML 協(xié)議 主要用于準(zhǔn)實(shí)時(shí)通信和表示及請求 響應(yīng)服務(wù) 其基 本的語法和語義最初主要是由 Jabber 開源代社區(qū)于 1999 年開發(fā)的 2002 年 XMPP 工 作組被授權(quán)接手開發(fā)和改編 Jabber 協(xié)議以適應(yīng) IETF 的即時(shí)通信和表現(xiàn)技術(shù) 作為 XMPP 工作組的成果 本文定義了 XMPP 1 0 的核心功能 在 RFC 2779 IMP REQS 中指定的提供即時(shí)通信和表現(xiàn)功能的擴(kuò)展 定義在 XMPP IM 協(xié)議 the Extensible Messaging and Presence Protocol XMPP Instant Messaging and Presence 中 2 2 2 2 術(shù)語術(shù)語 本文中大寫的關(guān)鍵字 MUST MUST NOT REQUIRED SHALL SHALL NOT SHOULD SHOULD NOT RECOMMENDED MAY 和 OPTIONAL 的含義 在 BCP 14 RFC 2119 TERMS 有確切的描述 3 3 通用的架構(gòu)通用的架構(gòu) RFC3920 RFC3920 4 3 3 1 1 概覽概覽 雖然 XMPP 是不拘泥于任何特定的網(wǎng)絡(luò)架構(gòu) 但是迄今為止 它通常是通過 客戶機(jī) 服務(wù)器 架構(gòu)來實(shí)現(xiàn)的 在這里客戶端用 XMPP 的方式訪問服務(wù)器采用的是 TCP 連接 方式 服務(wù)器之間的通信也是 TCP 連接方式實(shí)現(xiàn)的 下圖大體上描述了這一架構(gòu) 這里 表示使用 XMPP 通訊 表示可使用任何 協(xié)議通訊 各符號含義如下所示 C1 C2 C3 XMPP 客戶端 S1 S2 XMPP 服務(wù)器 G1 一個(gè) XMPP 和外部 非 XMPP 消息網(wǎng)絡(luò)之間進(jìn)行 翻譯 的網(wǎng)關(guān) FN1 一個(gè)外部消息網(wǎng)絡(luò) FC1 外部消息網(wǎng)絡(luò)上的一個(gè)客戶端 3 3 2 2 服務(wù)器服務(wù)器 服務(wù)器充當(dāng) XMPP 通信的智能抽象層 它的作用主要是 管理發(fā)出的連接或與其他實(shí)體的會話 以 XML 信息流的形式在授權(quán)的客戶端 服 務(wù)器和其他實(shí)體之間接收和發(fā)送信息 通過 XML 流在實(shí)體間路由具有正確地址的 XML 節(jié) 大部分支持 XMPP 協(xié)議的服務(wù)器也負(fù)責(zé)存儲客戶端使用的數(shù)據(jù) 比如基于 XMPP 即時(shí) 通信與表示協(xié)議的用戶的聯(lián)系列表 在這種情況下 XML 數(shù)據(jù)直接由服務(wù)器代替客 戶端處理而不需要轉(zhuǎn)發(fā)到其他實(shí)體 3 3 3 3 客戶端客戶端 大多數(shù)的客戶端直接通過 TCP 與服務(wù)器連接 用 XMPP 協(xié)議充分利用一個(gè)服務(wù)和任何 相關(guān)的服務(wù)提供的功能 多個(gè)不同資源 比如不同的設(shè)備和地點(diǎn) 的客戶端可以同時(shí)并 發(fā)的連接到一個(gè)服務(wù)器 每個(gè)不同資源的客戶端通過 XMPP 地址的資源標(biāo)識符來區(qū)分 比如 和 推薦的連接端口為 5222 它 已向 IANA 注冊 2 4 2 4 網(wǎng)關(guān)網(wǎng)關(guān) 網(wǎng)關(guān)是一個(gè)特殊用途的服務(wù)器端的服務(wù) 主要功能是把 XMPP 翻譯成外部 非 XMPP 消息系統(tǒng) 并把返回的消息翻譯成 XMPP 例如到 email 參見 SMTP IRC 參見 IRC SIMPLE 參見 SIMPLE SMS 的網(wǎng) 關(guān) 還有和別的消息服務(wù)的網(wǎng)關(guān) 比如 AIM ICQ MSN Messenger Yahoo RFC3920 RFC3920 5 Instant Messenger 網(wǎng)關(guān)和服務(wù)器之間的通信 網(wǎng)關(guān)和外部消息系統(tǒng)的通 信 不在本文描述范圍之內(nèi) 2 5 2 5 網(wǎng)絡(luò)網(wǎng)絡(luò) 因?yàn)槊總€(gè)服務(wù)器都是由一個(gè)網(wǎng)絡(luò)地址來標(biāo)識的并且服務(wù)器之間的通信是 客 戶 服務(wù)器 協(xié)議的直接擴(kuò)展 實(shí)際上整個(gè)系統(tǒng)是由很多互通的服務(wù)器構(gòu)成的 例如 可以和 交換消息 出 席信息和其他信息 這種模式常見于那些需要使網(wǎng)絡(luò)地址標(biāo)準(zhǔn)化的協(xié)議 比 如 SMTP 任意兩個(gè)服務(wù)器之間的通信是可選 OPTIONAL 的 如果被激 活 那么這種通信應(yīng)該 SHOULD 通過 XML 流綁定到 TCP 連接上進(jìn)行 建 議的 RECOMMENDED 服務(wù)器之間的連接端口為 5269 這個(gè)端口號已經(jīng)在 IANA 在第十五章第九節(jié)查閱端口號碼 注冊了 3 3 地址空間地址空間 3 1 3 1 概覽概覽 一個(gè)實(shí)體可以是任何一個(gè)被認(rèn)為是一個(gè)網(wǎng)絡(luò)端點(diǎn)的東西 例如網(wǎng)絡(luò)上的一個(gè) ID 而且它是通過 XMPP 進(jìn)行通信的 所有這些實(shí)體都有一個(gè)具有唯一性 的地址 并符合 RFC 2396 URI 規(guī)范要求的格式 由于歷史原因 一個(gè) XMPP 實(shí)體的地址被稱為 Jabber Identifier 或 JID 一個(gè)合法的 JID 包括一 組排列好的元素 包括域名 domain identifier 節(jié)點(diǎn)名 node identifier 和資源名 resource identifier JID 的語法定義 使用 ABNF 中的 Augmented Backus Naur 格式 IPv4 地址和 IPv6 地址規(guī)則在 附錄 B 中的 IPv6 中定義 確定節(jié)點(diǎn)規(guī)則的合 法字符順序由 附錄 A 的 STRINGPREP 的 Nodeprep 部分來定義 確定資 源規(guī)則的合法字符順序由 附錄 B 的 STRINGPREP 的 Resourceprep 部分 來定義 子域名規(guī)則參考 IDNA 中關(guān)于國際域名標(biāo)簽的描述 jid node domain resource domain fqdn address literal fqdn sub domain 1 sub domain sub domain internationalized domain label address literal IPv4address IPv6address 所有 JID 都是基于上述的結(jié)構(gòu) 類似 這種結(jié)構(gòu) 最常用來標(biāo)識一個(gè)即時(shí)消息用戶 這個(gè)用戶所連接的服務(wù)器 以及這個(gè)用戶 用于連接的資源 比如特定類型的客戶端軟件 不過 節(jié)點(diǎn)類型不是客戶 端也是有可能的 比如一個(gè)用來提供多用戶聊天服務(wù)的特定的聊天室 地址 可以是 這里 room 是聊天室的名字 而 service 是多用戶聊天服務(wù)的主機(jī)名 而加入了這個(gè)聊天室的某 RFC3920 RFC3920 6 個(gè)特定的用戶的地址則是 這里 nick 是用戶 在聊天室的昵稱 許多其他的 JID 類型都是可能的 例如 可能是一個(gè)服務(wù)器端的腳本或服務(wù) 一個(gè) JID 的每個(gè)合法部分 節(jié)點(diǎn)名 域名 資源名 的長度不能 MUST NOT 超過 1023 字節(jié) 也就是整體長度 包括 和 不能超過 3071 字 節(jié) 3 2 3 2 域名域名 域名是一個(gè)主要的 ID 并且是 JID 中唯一必需 REQUIRED 的元素 一個(gè)純 粹的域名也是一個(gè)合法的 JID 它通常代表網(wǎng)絡(luò)的網(wǎng)關(guān)或者 主 服務(wù)器 其他實(shí)體通過連接它來實(shí)現(xiàn) XML 轉(zhuǎn)發(fā)和數(shù)據(jù)管理功能 然而 由一個(gè)域名 標(biāo)識引用的實(shí)體 并非總是一個(gè)服務(wù)器 它也可能是一個(gè)服務(wù)器的子域地址 提供額外的功能 比如多用戶聊天服務(wù) 用戶目錄 或一個(gè)到外部消息系統(tǒng) 的網(wǎng)關(guān) 每個(gè)服務(wù)器或者服務(wù)的域名 可以 MAY 是一個(gè) IP 地址 但應(yīng)該 SHOULD 是一個(gè)完全合法的域名 參見 DNS 一個(gè)域名ID必須 MUST 是 IANA 里 定義的 國際化域名 并且按 STRINGPREP 中的 NAMEPREP profile 進(jìn)行成功的字符轉(zhuǎn)換 在比較兩個(gè)域名 ID 之前 服務(wù)器必須 MUST 客戶端 應(yīng)該 SHOULD 首先按照 Nameprep profile 定義在 IANA 中 來轉(zhuǎn)換每個(gè)域 名的字符 3 3 3 3 節(jié)點(diǎn)名節(jié)點(diǎn)名 節(jié)點(diǎn)名是一個(gè)可選 OPTIONAL 的第二 ID 放在域名之前并用符號 分開 它通常表示一個(gè)向服務(wù)器或網(wǎng)關(guān)請求和使用網(wǎng)絡(luò)服務(wù)的實(shí)體 比如一個(gè)客戶 端 當(dāng)然它也能夠表示其他的實(shí)體 比如在多用戶聊天系統(tǒng)中的一個(gè)房間 節(jié)點(diǎn)名所代表的實(shí)體 它的地址依賴于一個(gè)特定的域名 在 XMPP 的即時(shí)消 息和出席信息應(yīng)用系統(tǒng)中 這個(gè)地址是 純 JID 中的一 部分 一個(gè)節(jié)點(diǎn)名必須按 STRINGPREP 中的 Nodeprep profile 進(jìn)行成功的字符 轉(zhuǎn)換 在比較兩個(gè)節(jié)點(diǎn) ID 之前 服務(wù)器必須 MUST 客戶端應(yīng)該 SHOULD 首先按 Nodeprep profile 轉(zhuǎn)換每個(gè) ID 的字符 3 4 3 4 資源名資源名 資源名是一個(gè)可選的第三 ID 它放在域名的后面并由符號 分開 資源名 可以跟在 后面也可以跟在 后面 它通常表示一個(gè) 特定的會話 連接 比如設(shè)備或者所在位置 或者一個(gè)附屬于某個(gè)節(jié)點(diǎn) ID RFC3920 RFC3920 7 實(shí)體相關(guān)實(shí)體的對象 比如多用戶聊天室中的一個(gè)參加者 對于服務(wù)器和 和其他客戶端來說 資源名是不透明的 當(dāng)它提供必需的信息以完成資源綁 定 參見第七章 的時(shí)候 通常是由客戶端來實(shí)現(xiàn)的 盡管可以由客戶端向 服務(wù)器請求完成 然后顯示為 已連接的資源 一個(gè)實(shí)體可以 MAY 并 發(fā)維護(hù)多個(gè)已連接的資源 每個(gè)已連接的資源由不同的資源 ID 來區(qū)分 一個(gè)資源名必須 MUST 按 STRINGPREP 中的 Resourceprep profile 進(jìn) 行成功的格式化 在比較兩個(gè)資源 ID 之前 服務(wù)器必須 MUST 客戶端應(yīng) 該 SHOULD 首先按 Resourceprep profile 轉(zhuǎn)換每個(gè) ID 的字符 3 5 3 5 地址的確認(rèn)地址的確認(rèn) 在 SASL 見第六章 握手之后 如果必要的話 也在資源綁定 見第七章 之后 正在接收流信息的實(shí)體必須 MUST 確認(rèn)初始實(shí)體的 ID 對于服務(wù)器間的通信 在 SASL 握手時(shí) 如果沒有指明授權(quán)的 ID 這個(gè)初始 的實(shí)體應(yīng)該 SHOULD 是經(jīng)過認(rèn)證實(shí)體 參見 簡單認(rèn)證和安全層協(xié)議 SASL 中的定義 授權(quán)的 ID 見第六章 對于客戶端和服務(wù)器的通信 在 SASL 握手時(shí) 如果沒有指明授權(quán)的 ID 純 JID 應(yīng)該 SHOULD 是經(jīng)過認(rèn)證實(shí)體 參見 SASL 中 的定義 授權(quán)的 ID 全 JID 的資源 ID 部分 應(yīng)該 SHOULD 是由客戶端和服務(wù)器在資源綁定的時(shí)候商定的 參見第七章 接收的實(shí)體必須 MUST 確保結(jié)果 JID 包括節(jié)點(diǎn)名 域名 資源名以及分 隔符 與本章前面部分描述的規(guī)則和格式相一致 為了滿足這些約束條件 接收實(shí)體可能 MAY 需要把初始實(shí)體的發(fā)送方 JID 替換成接收實(shí)體認(rèn)可的 規(guī)范 JID 4 XML4 XML 流流 4 1 4 1 概覽概覽 兩個(gè)基本概念 XML 流和 XML 節(jié) 使得在出席信息已知的實(shí)體之間 異步交 換低負(fù)載的結(jié)構(gòu)化信息成為可能 這兩個(gè)術(shù)語定義如下 XML 流的定義 一個(gè) XML 流是一個(gè)容器 包含了兩個(gè)實(shí)體之間通過網(wǎng)絡(luò)交換 的 XML 元素 一個(gè) XML 流是由一個(gè) XML 打開標(biāo)簽 包含適當(dāng)?shù)膶?性和名字空間聲明 開始的 流的結(jié)尾則是一個(gè) XML 關(guān)閉 L 標(biāo)簽 在流的整個(gè)生命周期 初始化它的實(shí)體可以通過流發(fā)送大量的 XML 元素 用 于流的握手 例如 TLS 握手 第五章 或 SASL 握手 第六章 或 XML 節(jié) 在 這里指符合缺省名字空間的元素 包括 或 元素 初始的流 由初始化實(shí)體 通常是一個(gè)客戶端或服務(wù)器 和接收 RFC3920 RFC3920 8 實(shí)體 通常是一個(gè)服務(wù)器 握手 從接收實(shí)體來看 它就是那個(gè)初始實(shí)體的 會話 初始化流允許從初始化實(shí)體到接收實(shí)體的單向通信 為了使接收實(shí) 體能夠和初始實(shí)體交換信息 接收實(shí)體必須發(fā)起一個(gè)反向的握手 應(yīng)答流 XML 節(jié)的定義 一個(gè) XML 節(jié)是一個(gè)實(shí)體通過 XML 流向另一個(gè)實(shí)體發(fā)送的結(jié) 構(gòu)化信息中的一個(gè)離散的語義單位 一個(gè) XML 直接存在于根元素 的下一級 并且如果這樣就能夠滿足 XML 內(nèi)容的 production 43 那么它被 認(rèn)為是均衡的 任何 XML 節(jié)都是從一個(gè) XML 流的下一級的某個(gè)打開標(biāo)簽 如 開始 到相應(yīng)的關(guān)閉標(biāo)簽 如 一個(gè) XML 節(jié)可 以 MAY 包含子元素 相關(guān)的屬性 元素 和 XML 字符數(shù)據(jù)等 以表達(dá)完整 的信息 在這里定義的 XML 節(jié)僅限于 和 元素 具體描述見 XML Stanzas 第九章 為 TLS 握手 第五章 SASL 握手 第六章 服務(wù)器回?fù)?第八章 的需要而發(fā)送的 XML 元素 不被認(rèn) 為是一個(gè) XML 節(jié) 設(shè)想一個(gè)客戶端和服務(wù)器會話的例子 為了連接一個(gè)服務(wù)器 一個(gè)客戶端必 須 MUST 發(fā)送一個(gè)打開標(biāo)簽給服務(wù)器 初始化一個(gè) XML 流 也可 選擇 OPTIONAL 在這之前發(fā)送一段文本聲明 XML 版本和支持的字符集 參 見文本聲明的內(nèi)容 第十一章第四節(jié) 也可看字符編碼 第十一章第五節(jié) 視本地化策略和提供的服務(wù)而定 服務(wù)器應(yīng)該 SHOULD 回復(fù)一個(gè) XML 流給 客戶端 同樣的 也可選擇在這之前發(fā) 送一段文本聲明 一旦客戶端完成 了 SASL 握手 第六章 客戶端可以 MAY 通過流發(fā)送不限量的 XML 節(jié)給 網(wǎng)絡(luò)中的任何接收者 當(dāng)客戶端想關(guān)閉這個(gè)流 它只需要簡單的發(fā)送一個(gè)關(guān) 閉標(biāo)簽給服務(wù)器 或者作為另一個(gè)選擇 可能由服務(wù)器關(guān)閉這個(gè) 流 然后 客戶端和服務(wù)器都應(yīng)該 SHOULD 徹底地終止這個(gè)連接 通常 是一個(gè) TCP 連接 那些習(xí)慣認(rèn)為XML是一個(gè)以文本為中心風(fēng)格的人可能希望看看一個(gè)與服務(wù)器 連接的客戶端會話 包含兩個(gè) 打開 關(guān)閉 XML 文檔 一個(gè)是從客戶端到服務(wù) 器 一個(gè)是從服務(wù)器到客戶端 下圖中 根元素 可以被認(rèn)為是每 個(gè) 文檔 的文檔實(shí)體 這兩個(gè) 文檔 通過累積那些在 XML 上傳輸?shù)?XML 節(jié)來搭建的 無論如何 下圖只是方便理解 實(shí)際上 XMPP 并不處理文檔而 是處理 XML 流和 XML 節(jié) 基本上 一個(gè) XML 流相當(dāng)于一個(gè)會話期間所有 XML 節(jié)的一個(gè)信封 我們可以 簡單的把它描述成下圖 RFC3920 RFC3920 9 4 2 4 2 綁定到綁定到 TCPTCP 雖然有很多非必需的連接使用 XML 流來綁定 TCP 連接 兩個(gè)實(shí)體可以通過 別的機(jī)制來互聯(lián) 比如通過 HTPP 連接輪詢 本規(guī)范只定義了 XMPP 到 TCP 的綁定 在客戶和服務(wù)器通信的過程中 服務(wù)器必須 MUST 允許客戶端共 享一個(gè) TCP 連接來傳輸 XML 節(jié) 包括從客戶端傳到服務(wù)器和從服務(wù)器傳到客 戶端 在服務(wù)器之間的通信過程中 服務(wù)器必須 MUST 用一個(gè) TCP 連接 向 對方發(fā)送 XML 節(jié) 另一個(gè) TCP 連接 由對方初始化 接收對方的 XML 節(jié) 一共兩個(gè) TCP 連接 4 3 4 3 流的安全流的安全 在 XMPP 1 0 中 當(dāng) XML 流開始握手時(shí) TLS 應(yīng)該 SHOULD 按 第五章 TLS 的使用 中的規(guī)定來使用 SASL 必須 MUST 按 第六章 SASL 的使用 中的 規(guī)定來使用 盡管可能 MAY 存在某種共有的機(jī)制能夠保證雙向安全 但 是 初始化流 比如從初始化實(shí)體發(fā)給接收實(shí)體的流 和 應(yīng)答流 比 如從接收實(shí)體發(fā)給初始化實(shí)體的流 還是必須 MUST 安全的分開 在流被 驗(yàn)證之間 實(shí)體不應(yīng)該 SHOULD NOT 嘗試通過流發(fā)送 XML 節(jié) 第九章 就算它這樣做了 對方的實(shí)體也不能 MUST NOT 接受這些 XML 節(jié) 并且應(yīng) 該 SHOULD 返回一個(gè) 的流錯(cuò)誤信息并且終止當(dāng)前 TCP 連接上雙方的 XML 流 注意 這僅僅是針對 XML 節(jié) 包含在缺省命名空間中 的 和 元素 而不是指那些用于 TLS 握手 第五章 SASL 握手 第六章 握手的流 4 4 4 4 流屬性流屬性 流元素的屬性如下 to to 屬性應(yīng)該 SHOULD 僅用于從初始化實(shí)體到接收實(shí)體的 XML 流的頭 并且必須 MUST 設(shè)成為接收實(shí)體提供服務(wù)的主機(jī)名 注意 不應(yīng)該 SHOULD NOT 有 to 屬性出現(xiàn)在接收實(shí)體應(yīng)答初始實(shí)體的 XML 流的頭中 無論如何 如果 to 屬性出現(xiàn)在應(yīng)答流中 初始化實(shí)體應(yīng)該 SHOULD 忽略它 from from 屬性應(yīng)該 SHOULD 僅用于接收實(shí)體應(yīng)答初始化實(shí)體的 XML 流的頭 并且必須 MUST 設(shè)成為接收實(shí)體 正在給初始實(shí)體授權(quán) 提供服務(wù)的主機(jī)名 注意 不應(yīng)該 SHOULD NOT 有 from 屬性出現(xiàn)在 RFC3920 RFC3920 10 初始實(shí)體發(fā)送給接收實(shí)體的 XML 流的頭中 無論如何 如果 from 屬性 出現(xiàn)在初始化流中 接收實(shí)體應(yīng)該 SHOULD 忽略它 id id 屬性應(yīng)該 SHOULD 僅用于接收實(shí)體發(fā)送給初始化實(shí)體 XML 流的頭 這個(gè)屬性是一個(gè)由接收實(shí)體創(chuàng)建的具有唯一性的 ID 一個(gè)初始實(shí) 體和接收實(shí)體之間的會話 ID 并且它在接收方的應(yīng)用程序中 通常是一 個(gè)服務(wù)器 必須 MUST 是唯一的 注意 這個(gè)流 ID 必須是足夠安全 的 所以它必須是不可預(yù)知的和不可重復(fù)的 參見 RANDOM 了解如何獲 得隨機(jī)性以保證安全性 不應(yīng)該 SHOULD NOT 有 id 屬性出現(xiàn)在初 始實(shí)體發(fā)送給接收實(shí)體的 XML 流的頭中 無論如何 如果 id 屬性出現(xiàn) 在初始化流中 接收實(shí)體應(yīng)該 SHOULD 忽略它 xml lang xml lang 屬性 定義在 XML 中的第二章第十二節(jié) 應(yīng)該 SHOULD 包含在初始化實(shí)體發(fā)給接收實(shí)體的 XML 流的頭中 以指定在 流中傳輸?shù)目勺x XML 字符所使用的缺省語言 如果這個(gè)屬性出現(xiàn)了 接 收實(shí)體應(yīng)該 SHOULD 記住它的值 作為初始化流和應(yīng)答流的缺省屬性 如果這個(gè)屬性沒有出現(xiàn) 接收實(shí)體應(yīng)該 SHOULD 用一個(gè)可配置的缺省 值用于雙方的流 這個(gè)屬性值必須 MUST 在應(yīng)答流的頭中傳達(dá) 對于 所有初始化流中傳輸?shù)墓?jié) 如果初始實(shí)體沒有提供 xml lang 屬性 接 收實(shí)體應(yīng)該 SHOULD 應(yīng)用缺省值 如果初始實(shí)體提供了 xml lang 屬 性 接收實(shí)體不能 MUST NOT 修改或刪除它 參見第九章第一節(jié)第五 小節(jié) xml lang xml lang 屬性的值必須 MUST 是一個(gè) NMTOKEN 定 義在 XML 的第二章第三節(jié) 并且必須 MUST 遵守 RFC 3066 LANGTAGS 規(guī)定的格式 version version 屬性 最少需要 1 0 為本規(guī)范中和流相關(guān)的協(xié)議 提供了支持 關(guān)于這個(gè)屬性的生成和處理的詳細(xì)規(guī)則將在下文中定義 我們現(xiàn)在可以總結(jié)如下 初始化方發(fā)給接初始化方發(fā)給接 收方收方 接收方發(fā)給初始接收方發(fā)給初始 化方化方 to 接收方的主機(jī)名 忽略 from 忽略 接收方的主機(jī)名 id 忽略 會話鍵值 xml lang 缺省語言 缺省語言 vers ion 支持 XMPP 1 0 支持 XMPP 1 0 4 4 1 4 4 1 版本支持版本支持 在這里XMPP的版本是 1 0 準(zhǔn)確地說 這里囊括了和流相關(guān)的所有協(xié)議 TLS 的使用 第五章 SASL 的使用 第六章 和流錯(cuò)誤 第四章第七節(jié) 以及 三個(gè)定義好的 XML 節(jié)類型 和 XMPP 版本 號的編號順序是 主版本和副版本號必須 MUST 是獨(dú)立的整數(shù)并且每個(gè)號碼可以 MAY 單獨(dú)以阿拉伯?dāng)?shù)字增長 這樣 XMPP RFC3920 RFC3920 11 2 4 的版本將比 XMPP 2 13 更低 號碼前面 的 0 比如 XMPP 6 01 必須 MUST 被接收方忽略并且不能 MUST NOT 被發(fā)送出去 如果流和節(jié)的格式或者必需的處理方式有了顯著的改變 以至于老版本的實(shí) 體如果只是簡單的忽略它不理解的節(jié)和屬性并且繼續(xù)像老版本一樣的處理 方式 會使得老版本的實(shí)體不能夠和新版本的實(shí)體交互 只有在這時(shí)候主版 本號才應(yīng)該 SHOULD 增加 副版本號顯示新的性能 它必須 MUST 被副 版本號更低的實(shí)體忽略 但被高 副 版本號的實(shí)體用于了解信息 例如 一個(gè)副版本號顯示處理某種新定義的 type 屬性的值 用于 message presence 或 IQ 節(jié) 的能力 副版本號高的實(shí)體將會了解到與之通 信的對方不能夠理解這個(gè) type 屬性的值 所以將不會發(fā)送它 以下規(guī)則是用于 版本 屬性在實(shí)現(xiàn)流的頭信息時(shí)如何生成和處理 1 初始化實(shí)體必須 MUST 在初始化流的頭信息中把 版本 的值設(shè)置成它 所支持的最高版本 比如 如果最高版本支持就是本規(guī)范 那么它必 須 MUST 設(shè)置成 1 0 2 接收實(shí)體必須 MUST 在應(yīng)答流的頭信息中把 版本 的值設(shè)置成初始化 實(shí)體所提供的版本或它所支持的最高版本 取其中版本號較低的那一個(gè) 接收實(shí)體必須 MUST 把主版本號和副版本號作為數(shù)字來比較 而不是對 主版本號 副版本號 這個(gè)字符串進(jìn)行比較 3 如果在應(yīng)答流的頭信息的版本號中至少有一個(gè)主版本號低于初始化流的 頭信息的版本號 并且如前所述 新版本的實(shí)體不能夠和舊版本實(shí)體交互 初始化實(shí)體應(yīng)該 SHUOULD 生成一個(gè)的流錯(cuò)誤 信息并終止 XML 流和它的 TCP 連接 4 如果一個(gè)實(shí)體收到一個(gè)頭信息中沒有 version 屬性的流 這個(gè)實(shí)體必須 MUST 把對方實(shí)體的 version 當(dāng)成 0 0 并且在它發(fā)送的應(yīng)答流的頭 中也不應(yīng)該 SHOULD NOT 包含 version 屬性 4 5 4 5 名字空間聲明名字空間聲明 流的元素必須 MUST 同時(shí)滿足一個(gè)流名字空間聲明和一個(gè)缺省名字空間聲 明 名字空間聲明 定義在 XML 名字空間定義 XML NAMES 中 關(guān)于流名 字空間和缺省名字空間的詳細(xì)信息 參考 名字空間的名字和前綴 第十一章 第二節(jié) 4 6 4 6 流的特性流的特性 如果初始化的實(shí)體在初始化流的頭信息中設(shè)置 version 屬性的信息為 1 0 接收實(shí)體必須 MUST 向初始化實(shí)體發(fā)送一個(gè) 子元素以 聲明任何可供協(xié)商的流一級的特性 或者其他需要聲明的能力 目前 這僅 用于聲明本文中定義的 TLS 的使用 第五章 SASL 的使用 第六章 和資源 綁定 第七章 以及 XMPP IM 中定義的會話的建立 無論如何 流特性這一 RFC3920 RFC3920 12 功能將來可以用于聲明任何可協(xié)商的特性 如果一個(gè)實(shí)體不理解或支持安全 特性 它應(yīng)該 SHOULD 忽略它 如果要在一個(gè)非安全相關(guān)的特性 比如資源綁 定 被提議之前 完成一個(gè)或多個(gè)安全特性 比如 TLS 和 SASL 的協(xié)商 這個(gè)非 安全相關(guān)的特性不應(yīng)該 SHOULD NOT 在相應(yīng)的安全特性協(xié)商完畢之前被聲 明 4 7 4 7 流錯(cuò)誤流錯(cuò)誤 流的根元素可以 MAY 包含一個(gè) 子元素 由流的名字空間前綴 作為它的前綴 這個(gè) 錯(cuò)誤 子元素必須 MUST 由感知到發(fā)生了流級別錯(cuò)誤 的實(shí)體發(fā)送 通常是一個(gè)服務(wù)器而不是一個(gè)客戶端 4 7 1 4 7 1 規(guī)則規(guī)則 以下規(guī)則適用于流級別的錯(cuò)誤 它假定所有流級別的錯(cuò)誤都是不可恢復(fù)的 所以 如果一個(gè)錯(cuò)誤發(fā)生在 流級別 發(fā)現(xiàn)這個(gè)錯(cuò)誤的實(shí)體必須 MUST 發(fā)送一個(gè)流錯(cuò)誤信息給另一 個(gè)實(shí)體 發(fā)送一個(gè)關(guān)閉標(biāo)簽 并終止這個(gè)流所在的 TCP 連接 如果這個(gè)錯(cuò)誤發(fā)生在流剛開始設(shè)置的時(shí)候 接收實(shí)體必須 MUST 仍然 發(fā)送一個(gè)開放標(biāo)簽 并在流元素中包含一個(gè)的子元 素 然后發(fā)送一個(gè)關(guān)閉標(biāo)簽 最后終止相應(yīng)的 TCP 連接 在 這種情況下 如果初始化實(shí)體在 to 屬性中提供了一個(gè)未知的主機(jī)名 服務(wù)器應(yīng)該 SHOULD 在終止之前 先在流的頭信息的 from 屬性中提 供一個(gè)服務(wù)器認(rèn)證的主機(jī)名 4 7 2 4 7 2 語法語法 流錯(cuò)誤的語法如下 OPTIONAL descriptive text RFC3920 RFC3920 13 OPTIONAL application specific condition element 元素 必須 MUST 包含一個(gè)子元素以描述一個(gè)下文定義的節(jié)錯(cuò)誤條件 這個(gè)子 元素必須 MUST 符合 urn ietf params xml ns xmpp streams 名字空 間 可以 MAY 包含一個(gè) 子元素 用 XML 字符數(shù)據(jù)描述錯(cuò)誤的細(xì)節(jié) 這個(gè)元素必須 MUST 符合 urn ietf params xml ns xmpp streams 名 字空間并且應(yīng)該 SHOULD 擁有一個(gè) xml lang 屬性表明 XML 字符數(shù)據(jù)的 自然語言 可以 MAY 包含一個(gè)子元素用于描述一個(gè)明確的應(yīng)用程序錯(cuò)誤條件 這 個(gè)元素必須 MUST 符合一個(gè)應(yīng)用程序定義的名字空間 并且它的結(jié)構(gòu) 是由那個(gè)名字空間定義的 元素是可選的 OPTIONAL 如果有這個(gè)元素 它應(yīng)該 SHOULD 僅用于提供描述或調(diào)試信息以補(bǔ)充一個(gè)已定義的條件或應(yīng)用程序定義的條 件 它不應(yīng)該 SHOULD NOT 被一個(gè)應(yīng)用程序當(dāng)成一個(gè)可編程的信息 它不 應(yīng)該 SHOULD NOT 被用于向用戶表達(dá)錯(cuò)誤信息 但是可以 MAY 作為和 條件元素相關(guān)的錯(cuò)誤信息之外的附加說明 4 7 3 4 7 3 已定義的條件已定義的條件 以下流級別的錯(cuò)誤條件是已定義的 實(shí)體已經(jīng)發(fā)送 XML 但是不能被處理 這個(gè)錯(cuò)誤可以 可 以 被更多特定的XML相關(guān)的錯(cuò)誤替換 比如 以 及 盡管更多特定的錯(cuò)誤是首選的 實(shí)體發(fā)送的名字空間前綴不被支持 或者 在一個(gè)需要某種前綴的元素中沒有發(fā)送一個(gè)名字空間前綴 參見 XML Namespace Names and Prefixes 第十一章第二節(jié) 服務(wù)器正在關(guān)閉為這個(gè)實(shí)體激活的流 因?yàn)橐粋€(gè)和已經(jīng) 存在的流有沖突的新的流已經(jīng)被初始化 實(shí)體已經(jīng)很長時(shí)間沒有通過這個(gè)流發(fā)生任何 通信流量 可由一個(gè)本地服務(wù)策略來配置 初始化實(shí)體在流的頭信息中提供的 to 屬性的值所指 定的主機(jī)已經(jīng)不再由這臺服務(wù)器提供 由初始化實(shí)體在流的頭信息中提供的 to 屬性的 值和由服務(wù)器提供的主機(jī)名不一致 一個(gè)在兩臺服務(wù)器之間傳送的節(jié)缺少 to 或 from 屬性 或者這個(gè)屬性沒有值 RFC3920 RFC3920 14 服務(wù)器配置錯(cuò)誤或者其他未定義的內(nèi)部 錯(cuò)誤 使得服務(wù)器無法提供流服務(wù) 在 from 屬性中提供的 JID 或 主機(jī)名地址 和認(rèn) 證的 JID 不匹配 或服務(wù)器之間無法通過 SASL 或回?fù)?協(xié)商出合法的 域名 或客戶端和服務(wù)器之間無法通過它進(jìn)行認(rèn)證和資源綁定 流 ID 或回?fù)?ID 是非法的或和以前提供的 ID 不一 致 流名字空間和 http etherx jabber org streams 不相同或回?fù)苊挚臻g和 jabber server dialback 不相同 參考 XML Namespace Names and Prefixes 第十一章第二節(jié) 實(shí)體通過流發(fā)送了一個(gè)非法的 XML 給執(zhí)行驗(yàn)證的服 務(wù)器 參考 Validation 第十一章第三節(jié) 實(shí)體試圖在流被驗(yàn)證之前發(fā)送數(shù)據(jù)或不被許可執(zhí) 行一個(gè)和流協(xié)商有關(guān)的動作 接收實(shí)體在發(fā)送錯(cuò)誤信息之前不允許 MUST NOT 處理厭惡的節(jié) 實(shí)體違反了某些本地服務(wù)策略 服務(wù)器可以 MAY 選擇在 元素或應(yīng)用程序定義的錯(cuò)誤條件 元素 中詳 細(xì)說明策略 服務(wù)器無法正確連接到用于驗(yàn)證或授 權(quán)的遠(yuǎn)程實(shí)體 服務(wù)器缺乏必要的系統(tǒng)資源為流服務(wù) 實(shí)體試圖發(fā)送受限的 XML 特性 比如一個(gè)注釋 處理指示 DTD 實(shí)體參考 或保留的字符 參考 Restrictions 第十一 章第一節(jié) 服務(wù)器將不提供服務(wù)給初始化實(shí)體但是把它重定 向到另一臺主機(jī) 服務(wù)器應(yīng)該 SHOULD 在元素的 XML 字符數(shù)據(jù)中指明替代服務(wù)器名或 IP 地址 它必須 必須 是合法的域名 標(biāo)識 服務(wù)器正在關(guān)機(jī)并且所有激活的流正在被關(guān)閉 錯(cuò)誤條件不在本文已定義的錯(cuò)誤條件列表 之中 這個(gè)錯(cuò)誤條件應(yīng)該 SHOULD 僅用于 應(yīng)用程序定義條件 元素 初始化實(shí)體以一個(gè)服務(wù)器不不支持的編碼 方式編碼了一個(gè)流 參照 Character Encoding 第十一章第五節(jié) 初始化實(shí)體發(fā)送了一個(gè)流的一級子元 素但是服務(wù)器不支持 由初始化實(shí)體在流的頭信息中指定的 version 屬性的值所指定的版本不被服務(wù)器支持 服務(wù)器可以 MAY 在 元素中指定一個(gè)它支持的版本號 初始化實(shí)體發(fā)送了一個(gè)不規(guī)范的 XML 參考 XML 4 7 4 4 7 4 應(yīng)用程序定義條件應(yīng)用程序定義條件 RFC3920 RFC3920 15 大家知道 應(yīng)用程序可以 MAY 在error元素中包含一個(gè)適當(dāng)名字空間的子元 素來提供一個(gè)應(yīng)用程序定義流錯(cuò)誤信息 應(yīng)用程序定義 元素應(yīng)該 SHOULD 補(bǔ)充或甚至限定一個(gè)已定義的元素 所以 元素將包含兩個(gè)或三個(gè) 子元素 Some special application diagnostic information 4 8 4 8 簡化的流示例簡化的流示例 這里包含兩個(gè)簡化的例子 描述了基于流的客戶端在服務(wù)器上的 會 話 這里 C 表示從客戶端發(fā)給服務(wù)器 S 表示從服務(wù)器發(fā)給客戶端 這 些例子只是用于舉例說明原理 一個(gè)基本的 會話 C S RFC3920 RFC3920 16 encryption authentication and resource binding C C Art thou not Romeo and a Montague C S S Neither fair saint if either thee dislike S C S 一個(gè)不成功的 會話 C S encryption authentication and resource binding C Bad XML no closing body tag S S 5 TLS 5 TLS 的使用的使用 5 1 5 1 概覽概覽 XMPP 包含的一個(gè)保證流安全的方法來防止篡改和偷聽 這個(gè)傳輸層安全協(xié)議 TLS 的頻道加密方法 模擬了類似的其他 STARTTLS 見 RFC 2595 USINGTLS 的擴(kuò)展 如 IMAP IMAP POP3 POP3 and ACAP RFC3920 RFC3920 18 ACAP STARTTLS 的擴(kuò)展名字空間是 urn ietf params xml ns xmpp tls 一個(gè)給定域的管理員可以 MAY 要求客戶端和服務(wù)器通信以及服務(wù)器之間通 信時(shí)使用 TLS 或者兩者都要求 客戶端應(yīng)該 SHOULD 在嘗試完成 SASL 第 六章 握手之前使用 TLS 服務(wù)器應(yīng)該 SHOULD 在兩個(gè)域之間使用 TLS 以 保證服務(wù)器間通信的安全 以下是使用規(guī)則 1 一個(gè)遵守本協(xié)議的初始化實(shí)體必須 MUST 在初始化流的頭信息中包含 一個(gè) version 屬性并把值設(shè)為 1 0 2 如果 TLS 握手發(fā)生在兩個(gè)服務(wù)器之間 除非服務(wù)器聲稱的 DNS 主機(jī)名已 經(jīng)被解析 見第十四章第四節(jié) Server to Server Communications 通 信不能 MUST NOT 繼續(xù)進(jìn)行 3 當(dāng)一個(gè)遵守本協(xié)議的接收實(shí)體接收了一個(gè)初始化流 它的頭信息中包含 一個(gè) version 屬性并且值設(shè)為 1 0 在發(fā)送應(yīng)答流的的頭信息 其 中包含版本標(biāo)記 之后 它必須發(fā)送 MUST 元素 名字空 間為 urn ietf params xml ns xmpp tls 以及其他它支持的流特性 4 如果初始化實(shí)體選擇使用 TLS TLS 握手必須在 SASL 握手之前完成 這個(gè) 順序用于幫助保護(hù) SASL 握手時(shí)發(fā)送的認(rèn)證信息的安全 同時(shí)可以在必要 的時(shí)候在 TLS 握手之前為 SASL 外部機(jī)制提供證書 5 TLS 握手期間 一個(gè)實(shí)體不能 MUST NOT 在流的根元素中發(fā)送任何空格 符號作為元素的分隔符 在下面的 TLS 示例中的任何空格符都僅僅是為 了便于閱讀 這個(gè)禁令用來幫助確保安全層字節(jié)精度 6 接收實(shí)體必須 MUST 在發(fā)送 元素的關(guān)閉符號 之后立刻 開始 TLS 協(xié)商 初始化實(shí)體必須 MUST 在從接收實(shí)體接收到 元素的關(guān)閉符號 之后立刻開始 TLS 協(xié)商 7 初始化實(shí)體必須 MUST 驗(yàn)證接收實(shí)體出示的證書 關(guān)于證書驗(yàn)證流程 參見 Certificate Validation 第十四章第二節(jié) 8 證書必須 MUST 檢查初始化實(shí)體 比如一個(gè)用戶 提供的主機(jī)名 而不是通過 DNS 系統(tǒng)解析出來的主機(jī)名 例如 如果用戶指定一個(gè)主機(jī) 名 而一個(gè) DNS SRV SRV 查詢返回 證 書必須 MUST 檢查 如果任何種類的 XMPP 實(shí)體 例如客 戶端或服務(wù)器 的 JID 出現(xiàn)在一個(gè)證書里 它必須 MUST 表現(xiàn)為一個(gè) 別名實(shí)體里面的 UTF8 字符串 存在于 subjectAltName 之中 如何使用 ASN 1 對象標(biāo)識符 id on xmppAddr 定義在本文的第五章第一節(jié)第 一小節(jié) 9 如果 TLS 握手成功了 接收實(shí)體必須 MUST 丟棄 TLS 生效之前從初 始化實(shí)體得到的任何不可靠的信息 10 如果 TLS 握手成功了 初始化實(shí)體必須 MUST 丟棄 TLS 生效之前從 接收實(shí)體得到的任何不可靠的信息 11 如果 TLS 握手成功了 接收實(shí)體不能 MUST NOT 在流重新開始的時(shí)候通 過提供其他的流特性來向初始化實(shí)體提供 STARTTLS 擴(kuò)展 RFC3920 RFC3920 19 12 如果 TLS 握手成功了 初始化實(shí)體必須 MUST 繼續(xù)進(jìn)行 SASL 握手 13 如果 TLS 握手失敗了 接收實(shí)體必須 MUST 終止 XML 流和相應(yīng)的 TCP 連接 14 關(guān)于必須 MUST 支持的機(jī)制 參照 Mandatory to Implement Technologies 第十四章第七節(jié) 5 1 1 5 1 1 用于用于 XMPP XMPP 地址的地址的 ASN 1 ASN 1 對象標(biāo)識符對象標(biāo)識符 上文提到的 ASN 1 對象標(biāo)識符 id on xmppAddr 定義如下 id pkix OBJECT IDENTIFIER iso 1 identified organization 3 dod 6 internet 1 security 5 mechanisms 5 pkix 7 id on OBJECT IDENTIFIER id pkix 8 other name forms id on xmppAddr OBJECT IDENTIFIER id on 5 XmppAddr UTF8String 對象標(biāo)識符也可以 MAY 使用點(diǎn)分隔的格式 如 1 3 6 1 5 5 7 8 5 5 2 5 2 敘述敘述 當(dāng)一個(gè)初始化實(shí)體用 TLS 保護(hù)一個(gè)和接收實(shí)體之間的流 其步驟如下 1 初始化實(shí)體打開一個(gè) TCP 連接 發(fā)送一個(gè)打開的 XML 流頭信息 其 version 屬性設(shè)置為 1 0 給接收實(shí)體以初始化一個(gè)流 2 接收實(shí)體打開一個(gè) TCP 連接 發(fā)送一個(gè) XML 流頭信息 其 version 屬性 設(shè)置為 1 0 給初始化實(shí)體作為應(yīng)答 3 接收實(shí)體向初始化實(shí)體提議 STARTTLS 范圍 包括其他支持的流特性 如果 TLS 對于和接收實(shí)體交互是必需的 它應(yīng)該 SHOULD 在 元素中包含子元素 4 初始化實(shí)體發(fā)出 STARTTLS 命令 例如 一個(gè)符合 urn ietf params xml ns xmpp tls 名字空間的 元素 以通知接收實(shí)體它希望開始一個(gè) TLS 握手來保護(hù)流 5 接收實(shí)體必須 MUST 以 urn ietf params xml ns xmpp tls 名字空間 中的元素或元素應(yīng)答 如果失敗 接收實(shí)體必須 MUST 終止 XML 流和相應(yīng)的 TCP 連接 如果繼續(xù)進(jìn)行 接收實(shí)體必須 MUST 嘗試通過 TCP 連接完成 TLS 握手并且在 TLS 握手完成之前不能 MUST NOT 發(fā)送任何其他 XML 數(shù)據(jù) 6 初始化實(shí)體和接收實(shí)體嘗試完成 TLS 握手 要符合 TLS 規(guī)范 7 如果 TLS 握手不成功 接收實(shí)體必須 MUST 終止 TCP 連接 如果 TLS 握手成功 初始化實(shí)體必須 MUST 發(fā)送給接收實(shí)體一個(gè)打開的 XML 流 RFC3920 RFC3920 20 頭信息來初始化一個(gè)新的流 先發(fā)送一個(gè)關(guān)閉標(biāo)簽是不必要的 因?yàn)榻邮諏?shí)體和初始化實(shí)體必須 MUST 確保原來的流在 TLS 握手成功之 后被關(guān)閉 8 在從初始化實(shí)體收到新的流頭信息之后 接收實(shí)體必須 MUST 發(fā)送一 個(gè)新的 XML 流頭信息給初始化實(shí)體作為應(yīng)答 其中應(yīng)包含可用的特性但 不包含 STATRTTLS 特性 5 3 5 3 客戶端客戶端 服務(wù)器服務(wù)器 示例示例 以下例子展示一個(gè)客戶端使用 STARTTLS 保護(hù)數(shù)據(jù)流 注意 以下步驟舉例 說明協(xié)議中的失敗案例 在這個(gè)例子中它們并不詳盡并且也不是必須被數(shù)據(jù) 傳輸觸發(fā)的 步驟 1 客戶端初始化流給服務(wù)器 步驟 2 服務(wù)器發(fā)送一個(gè)流標(biāo)簽給客戶端作為應(yīng)答 步驟 3 服務(wù)器發(fā)送 STARTTLS 范圍給客戶端 包括驗(yàn)證機(jī)制和任何其他流 特性 RFC3920 RFC3920 21 DIGEST MD5 PLAIN 步驟 4 客戶端發(fā)送 STARTTLS 命令給服務(wù)器 步驟 5 服務(wù)器通知客戶端可以繼續(xù)進(jìn)行 步驟 5 或者 服務(wù)器通知客戶端 TLS 握手失敗并關(guān)閉流和 TCP 連接 步驟 6 客戶端和服務(wù)器嘗試通過已有的 TCP 連接完成 TLS 握手 步驟 7 如果 TLS 握手成功 客戶端初始化一個(gè)新的流給服務(wù)器 步驟 7 或者 如果 TLS 握手不成功 服務(wù)器關(guān)閉 TCP 連接 步驟 8 服務(wù)器發(fā)送一個(gè)流頭信息應(yīng)答客戶端 其中包括任何可用的流特 性 DIGEST MD5 PLAIN EXTERNAL 步驟 9 客戶端繼續(xù) SASL 握手 第六章 5 4 5 4 服務(wù)器服務(wù)器 服務(wù)器示例服務(wù)器示例 以下例子展示兩個(gè)服務(wù)器之間使用 STARTTLS 保護(hù)數(shù)據(jù)流 注意 以下步驟 舉例說明協(xié)議中的失敗案例 在這個(gè)例子中它們并不詳盡并且也不是必須被 數(shù)據(jù)傳輸觸發(fā)的 步驟 1 Server1 初始化流給 Server2 步驟 2 Server2 發(fā)送一個(gè)流標(biāo)簽給 Server1 作為應(yīng)答 步驟 3 Server2 發(fā)送 STARTTLS 范圍給 Server1 包括驗(yàn)證機(jī)制和任何 其他流特性 DIGEST MD5 KERBEROS V4 步驟 4 Server1 發(fā)送 STARTTLS 命令給 Server2 步驟 5 Server2 通知 Server1 允許繼續(xù)進(jìn)行 步驟 5 或者 Server2 通知 Server1 TLS 握手失敗并關(guān)閉流 步驟 6 Server1 和 Server2 嘗試通過 TCP 完成 TLS 握手 步驟 7 如果 TLS 握手成功 Server1 初始化一個(gè)新的流給 Server2 步驟 7 或者 如果 TLS 握手不成功 Server2 關(guān)閉 TCP 連接 步驟 8 Server2 發(fā)送一個(gè)包含任何可用流特性的流頭信息給 Server1 DIGEST MD5 KERBEROS V4 EXTERNAL 步驟 9 Server1 繼續(xù)進(jìn)行 SASL 握手 第六章 6 SASL 6 SASL 的使用的使用 6 1 6 1 概覽概覽 XMPP 有一個(gè)驗(yàn)證流的方法 即 XMPP 特定的 SASL 簡單驗(yàn)證和安全層 SASL SASL 提供了一個(gè)通用的方法為基于連接的協(xié)議增加驗(yàn)證支持 而 XMPP 使用 了一個(gè)普通的 XML 名字空間來滿足 SASL 的需要 RFC3920 RFC3920 25 以下規(guī)則應(yīng)用于 1 如果 SASL 協(xié)商發(fā)生在兩臺服務(wù)器之間 除非服務(wù)器宣稱的 DNS 主機(jī)名得 到解析 不能 MUST NOT 進(jìn)行通信 參見 服務(wù)器間的通信 第十四章 第四節(jié) 2 如果初始化實(shí)體有能力使用 SASL 協(xié)商 它必須 MUST 在初始化流的 頭信息中包含一個(gè)值為 1 0 的屬性 version 3 如果接收實(shí)體有能力使用 SASL 協(xié)商 它必須 MUST 在應(yīng)答從初始化 實(shí)體收到的打開流標(biāo)簽時(shí) 如果打開的流標(biāo)簽包含一個(gè)值為 1 0 的 version 屬性 通過 urn ietf params xml ns xmpp sasl 名字空間 中的元素聲明一個(gè)或多個(gè)驗(yàn)證機(jī)制 4 當(dāng) SASL 協(xié)商時(shí) 一個(gè)實(shí)體不能 MUST NOT 在流的根元素中發(fā)送任何 空格符號 匹配 production 3 content of XML 作為元素之間的分 隔符 在以下的SASL例子中任何空格符號的出現(xiàn)僅僅是為了增加可讀性 這條禁令幫助確保安全層字節(jié)的精確度 5 當(dāng) SASL 握手時(shí) 在 XML 元素中使用的任何 XML 字符數(shù)據(jù)必須被編碼成 base64 編碼遵循 RFC 3548 第三章的規(guī)定 6 如果一個(gè) 簡單名字 simple username 規(guī)范被選定的 SASL 機(jī)制所 支持 比如 這被 DIGEST MD5 和 CRAM MD5 機(jī)制支持但不被 EXTERNAL 和 GSSAPI 機(jī)制支持 驗(yàn)證的時(shí)候初始化實(shí)體應(yīng)該 SHOULD 在服務(wù)器間通信時(shí)提供 簡單名字 自身的發(fā)送域 IP 地址或包含在一個(gè) 域標(biāo)識符中的域名全稱 在客戶端與服務(wù)器之間通信時(shí)提供注冊用戶 名 包含在一個(gè) XMPP 節(jié)點(diǎn)標(biāo)識符中的用戶或節(jié)點(diǎn)名 7 如果初始化實(shí)體希望以另一個(gè)實(shí)體的身份出現(xiàn)并且 SASL 機(jī)制支持授權(quán) ID 的傳輸 初始化實(shí)體在 SASL 握手時(shí)必須 MUST 提供一個(gè)授權(quán) ID 如果初始化實(shí)體不希望以另一個(gè)實(shí)體的身份出現(xiàn) 初始化實(shí)體在 SASL 握 手時(shí)不能 MUST NOT 提供一個(gè)授權(quán) ID 在 SASL 的定義中 除非授權(quán) ID 不同于從驗(yàn)證 ID 詳見 SASL 中得到的缺省的授權(quán) ID 初始化實(shí)體 不能 MUST NOT 提供授權(quán) ID 如果提供了 這個(gè)授權(quán) ID 的值必須 MUST 是的格式 對于服務(wù)器來說 或的格式 對于客戶 端來說 8 在成功進(jìn)行包括安全層的 SASL 握手之后 接收實(shí)體必須 MUST 丟棄任 何從初始化實(shí)體得到的而不是從 SASL 協(xié)商本身獲得的信息 9 在成功進(jìn)行包括安全層的 SASL 握手之后 初始化實(shí)體必須 MUST 丟棄 任何從接收實(shí)體得到的而不是從 SASL 協(xié)商本身獲得的信息 10 參看 強(qiáng)制執(zhí)行的技術(shù) 第十四章第七屆 了解關(guān)于必須 MUST 支持 的機(jī)制 6 2 6 2 敘述敘述 一個(gè)初始化實(shí)體使用 SASL 和接收實(shí)體做驗(yàn)證的步