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

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