Xmpp Rfc3920 10-~15章 研討會報告
10. 伺服器處理XML節的規則 (Server Rules for Handling XML Stanzas)
相容的伺服器實做必須（MUST）確保兩個實體之間的XML節按次序處理. 除了按次序處理的需求之外, 每個伺服器實作將包含它自己的遞送樹"delivery tree"以處理它接收到的節.這個樹決定一個節是否需要路由到其他域, 在內部處理, 還是遞送到和一個已連接的節點相關的資源. 以下規則適用:
________________________________________
10.1. 沒有'to'地址 (No 'to' Address)
如果這個節沒有'to'屬性, 伺服器應該(SHOULD)為發送它的實體處理這個節. 因為所有從其他伺服器收到的節必須(MUST)擁有'to'屬性, 這個規則僅適用於從一個連接到這台伺服器的已註冊實體(如一個用戶端)收到的節,如果這個伺服器收到一個沒有'to'屬性的出席資訊節, 伺服器應該(SHOULD)向那些訂閱了這個發送實體的出席資訊的所有實體廣播它, 如果可能的話(即時消息和出席資訊應用程式中出席資訊廣播的語義定義在XMPP-IM). 如果伺服器接收到一個IQ類型為 "get" 或 "set" 且沒有'to'屬性的節並且它理解這個節的名字空間下的內容, 它必須(MUST)為這個發送實體處理節(在這裏"處理"的含義是由相關的名字空間的語義所決定的)或返回一個錯誤給發送實體.
#c to s 可以不用有 to 屬性 ,因為c to s 預設的 to 即是 server
#若是出席訊息＜presence＞沒有to屬性,即為廣播給所有訂閱者,rfc3921第五章說明如下:
(5.1.1初始化出席資訊 :
建立起一個會話之後, 一個用戶端應該(SHOULD)發送初始化出席資訊給伺服器來通知它的通信可用性.如這裏定義的, 初始化出席資訊節 (1) 必須(MUST) 不擁有'to'屬性(這表示它是由伺服器代替用戶端發送的廣播) 並且 (2) 必須(MUST) 不擁有'type'屬性).
________________________________________
10.2. 外部域 (Foreign Domain) (s to s)
如果'to'屬性中的JID的域ID部分的主機名和伺服器自身或其子域配置的主機名不匹配, 伺服器應該（SHOULD）路由這個節到外部域(取決於本地服務規定或安全策略關於域間通信的規定).有兩種可能的情況:
- 一個伺服器to伺服器之間的流已經存在於兩個域之間: 發送者的伺服器透過這個已存在的流為這個外部域路由(轉送)這個節到授權伺服器 - 兩個域之間沒有伺服器to伺服器之間的流: 發送者伺服器 (1) 解析這個外部域的主機名(定義在伺服器間的通信Server-to-Server Communications (第十四章第四節)), (2) 在兩個域之間進行伺服器到伺服器的流協商(定義在 Use of TLS (第五章) 和 Use of SASL (第六章)), 然後 (3) 通過這個新建的流為外部域路由(轉送)這個節到授權伺服器
如果路由(轉送)到接收者的伺服器不成功, 發送者的伺服器必須（MUST）返回一個錯誤給發送者; 如果接收者的伺服器聯繫上了但是從接收者的伺服器遞送到接收者不成功, 接收者伺服器必須（MUST）透過發送者的伺服器返回一個錯誤給發送者.
________________________________________
10.3. 子域 (Subdomain) (?)
如果'to'屬性中的JID的域ID部分的主機名和伺服器自身配置的主機名的一個子功能變數名稱匹配,伺服器必須（MUST）自己處理這個節或路由這個節到專門負責這個子域的特定服務(如果子域被配置了),或者返回一個錯誤給發送者(如果子域沒有配置).
________________________________________
10.4. 純粹的域或特定的資源 (Mere Domain or Specific Resource)
如果'to'屬性中的JID的域ID部分的主機名和伺服器自身配置的主機名本身匹配,並且'to'屬性中的JID類型是＜domain＞ 或 ＜domain/resource＞, 伺服器(或其中定義的資源)必須（MUST）根據節的類型適當的處理這個節或返回一個錯誤節給發送者.
________________________________________
10.5. 同一域中的節點 (Node in Same Domain)
如果'to'屬性中的JID的域ID部分的主機名和伺服器自身配置的主機名本身匹配,並且'to'屬性中的JID類型是＜node@domain＞ 或 ＜node@domain/resource＞, 伺服器應該(SHOULD)遞送這個節到'to'屬性中的JID所指明的預定的接收者. 以下規則適用:
1. 如果這個JID包含一個資源ID(例如, 格式是＜node@domain/resource＞)並且存在一個連接的資源符合這個全JID, 接收者伺服器應該（SHOULD）遞送這個節給正確符合這個資源ID的流或會話.
2. 如果這個JID包含一個資源ID(例如, 格式是＜node@domain/resource＞)並且不存在一個連接的資源符合這個全JID, 接收者伺服器應該（SHOULD）返回一個＜service-unavailable/＞ 節錯誤給發送者.
3. 如果這個JID的格式是＜node@domain＞並且存在至少一個此節點的連接資源, 接收伺服器應該（ SHOULD）遞送這個節給至少其中一個已連接的資源, 依據應用程式定義的規則(一系列即時消息和出席資訊應用程式的遞送規則定義在XMPP-IM).
@Rfc3921第11章 伺服器處理XML節的規則有詳細的說明如下:
如果JID的格式是＜user@domain＞並且這個用戶至少有一個可用的資源, 接收者的伺服器必須(MUST)遵守以下規則:
1. 對於消息(message)節, 伺服器應該(SHOULD)遞送這個節給高優先順序的可用資源(如果這個資源沒有提供＜priority/＞元素的值, 伺服器應該(SHOULD)認為它提供的值為零). 如果兩個或更多的可用資源有相同的優先順序, 伺服器可以(MAY)使用一些其他的規則(例如, 最近的連接時間, 最近的活動時間, 或由一些＜show/＞值的層次所定義的最高的可用性) 來從它們中間選擇,或可以(MAY)遞送這個消息到所有這些資源. 無論如何, 伺服器不能(MUST NOT)遞送這個節到一個優先順序為負數的可用資源; 如果唯一的一個可用資源的優先順序是負數, 伺服器應該(SHOULD)當成沒有可用資源一樣處理這個消息(定義在後面). 另外, 伺服器不能(MUST NOT)重寫'to'屬性(換言之, 它必須(MUST)讓它保持＜user@domain＞而不是改成＜user@domain/resource＞).
2. 對於類型不是"probe"(探測)的出席資訊節, 伺服器必須(MUST)遞送這個節給所有可用的資源;對於出席資訊調查, 伺服器應該(SHOULD)基於定義在 出席資訊調查Presence Probes (第五章第一節第三小節)的規則來應答. 另外, 伺服器不能(MUST NOT)重寫'to'屬性(換言之, 它必須(MUST)保持＜user@domain＞而不是改為＜user@domain/resource＞).
3. 對於IQ節, 伺服器本身必須(MUST)代替用戶應答一個IQ result或一個IQ error, 並且不能(MUST NOT)遞送這個IQ節給任何可用的資源. 具體來說, 如果合格的名字空間的語義定義了一個伺服器可以提供的應答, 伺服器必須(MUST)代替用戶應答這個節; 如果沒有, 伺服器必須(MUST)應答一個＜service-unavailable/＞節錯誤.
＜presence from='juliet@example.com/balcony'＞
＜priority＞13＜/priority＞ =＞ whose value is an integer between -128 and +127. rfc3921 2.2.2.3
＜/presence＞
＜presence from='juliet@example.com/balcony'＞
＜show＞away＜/show＞ =＞ chat dnd xa rfc3921 2.2.2.1
＜/presence＞
________________________________________
11. XMPP中的XML用法 (XML Usage within XMPP)
________________________________________
11.1. 限制 (Restrictions)
XMPP是一個簡單的流式XML元素的專用協定用於接近即時地交換結構化資訊. 因為XMPP不需要任意的解析和所有的XML文檔, 所以XMPP不需要支援[XML]的所有功能. 特殊的, 適用以下限制.
關於XML生成, 一個XMPP實作不能(MUST NOT)在XML流中注入以下任何東西:
o 注釋 (第二章第五節[XML]) ,如 ＜!--XXX--＞
o 處理指令(第二章第六節 同上) , target content parent
o 內部或外部的 DTD 子集 (第二章第八節 同上)
o 內部或外部的實體參考 (第四章第二節 同上) 除了預定實體以外(第四章第六節 同上)
o 字元資料或屬性值包含和預定實體列表中吻合的未逸出的unescaped字元(第四章第六節 同上); 這些字元必須（MUST）逸出 ,如 & ＜ ＞ …
關於XML處理, 如果一個XMPP實現接收到這些受限的XML資料,它必須（MUST）忽略這些資料.
________________________________________
11.2. XML 命名空間的名字和前綴詞 (XML Namespace Names and Prefixes)
XML名字空間[XML-NAMES]為所有XMPP相容的XML建立資料所有權的嚴格界限. 這個名字空間的基本功能是把結構上混合在一起的XML元素區分出不同的辭彙. 確保XMPP相容的XML有名字空間的感知能力使得任何允許的XML可以被結構化的混合到任何XMPP資料元素中. XML名字空間的名字和首碼的規則在下一小節中.
________________________________________
11.2.1. 流命名空間 (Streams Namespace)
在所有的XML流頭中必須聲明一個流名字空間. 流名字空間必須（MUST）是 'http://etherx.jabber.org/streams'. 元素名＜stream/＞和它的＜features/＞和＜error/＞子元素必須（MUST）在所有實例中符合這個流名字空間首碼. 一個實作應該（SHOULD）只為這些元素生成'stream:'首碼, 並且由於歷史原因可以（MAY）只接受'stream:'首碼.
________________________________________
11.2.2. 預設命名空間 (Default Namespace)
在所有的XML流中必須聲明一個預設的流名字空間用於定義允許的流根元素的一級子元素. 這個名字空間聲明對於初始化流和應答流必須（MUST）是相同的使得雙方的流都是合格一致的. 預設的名字空間聲明適用於流和所有在流中發送的節(除非由流名字空間或回撥名字空間的首碼顯式的符合另一個名字空間).
一個伺服器實現必須（MUST）支持以下兩個預設名字空間(由於歷史原因, 一些實現可能(MAY)只支持這兩個預設名字空間):
o jabber:client -- 當流用於用戶端和伺服器的通信時聲明這個預設名字空間
o jabber:server -- 當流用於兩個伺服器間的通信時聲明這個預設名字空間
＜?xml version='1.0'?＞
＜stream:stream
to='127.0.0.1'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'＞
一個用戶端實作必須（MUST）支持'jabber:client'預設名字空間,並且由於歷史原因可以（MAY）只支持這個預設名字空間.
如果預設名字空間是'jabber:client'或'jabber:server'，一個實作不能（MUST NOT）在這個名字空間下為元素生成名字空間前綴詞. 一個實作不應該（SHOULD NOT）按照元素的內容（可能和流相反）生成不同於'jabber:client'和'jabber:server'名字空間前綴詞.
注意: 'jabber:client' 和 'jabber:server' 名字空間接近於相同但是用於不同的上下文(用戶端伺服器通信用'jabber:client' 而伺服器間通信用'jabber:server'). 這兩者之間僅有的不同在於在'jabber:client'中被發送的節中'to'和'from'屬性是可選的（OPTIONAL）,而在'jabber:server'中被發送的節中它們是必需的（REQUIRED）. 如果相容的實施接受一個符合'jabber:client'或'jabber:server'名字空間的流, 它必須（MUST）支援通用屬性(第九章第一節)和三個核心節類型(message, presence, 和IQ)的基本語義(第九章第二節).
________________________________________
11.2.3. 回撥名字空間 (Dialback Namespace)(?)
所有用於伺服器回撥的(第八章)元素都必須聲明一個回撥名字空間. 回撥名字空間的名字必須（MUST）是'jabber:server:dialback'. 所有符合此名字空間的元素必須（MUST）有首碼. 一個實現應該（SHOULD）只為這些元素生成'db:'首碼並且只可以（MAY）接受'db:'首碼.
________________________________________
11.3. 確認 (Validation)
除了注意'jabber:server'名字空間中關於節中'to'和'from'位址的規定,一個伺服器不需要為轉發到用戶端或其他伺服器負責檢查XML元素;一個實作可以（MAY）選擇僅提供有效資料元素但這是可選的（OPTIONAL）. 用戶端不應該（SHOULD NOT）濫用發送不符合schema的資料的能力, 並且應該（SHOULD）忽略接收到的XML流中任何和schema不一致的元素或屬性值. XML流和節的有效性確認是可選的（OPTIONAL）,並且在這裏提到的schemas僅用於描述的用途.
________________________________________
11.4. 文本聲明的包含 (Inclusion of Text Declaration)(?)
實現應該（SHOULD）在發送一個流標頭資訊之前發送一個文本聲明. 應用程式必須（MUST）遵守[XML]中關於環境（那裏對文本聲明做了規定）的規則.
________________________________________
11.5. 字元編碼 (Character Encoding)
Implementations MUST support the UTF-8 (RFC 3629 [UTF 8]) transformation of Universal Character Set (ISO/IEC 10646-1 [UCS2]) characters, as required by RFC 2277 [CHARSET]. Implementations MUST NOT attempt to use any other encoding.
實作必須（MUST）支援通用字元集Universal Character Set (ISO/IEC 10646-1 [UCS2])字元到UTF-8(RFC 3629 [UTF-8])的轉換, 必須符合 RFC 2277 [CHARSET]. 實作不能（MUST NOT）試圖使用任何其他的編碼.
@UTF-8為Unicode編碼的一種轉換格式,UCS2 為Unicode 雙字節編碼規範
________________________________________
12. 核心的相容性要求 (Core Compliance Requirements)
本章總結了可擴展的消息和出席資訊協定中的某些方面，為了實施的相容性，它們必須（MUST）被伺服器和用戶端支援，當然協定的其他方面也應該（SHOULD）被支持. 為了相容的目的, 我們在核心協議和即時消息協定之間劃了一個級別. 在本章中定義了所有伺服器和用戶端的相容性要求; 即時消息伺服器和用戶端的相容性要求在XMPP-IM的相關章節中定義.
________________________________________
12.1. 伺服器 (Servers)
除了所有已定義的關於安全, XML使用, 和國際化的要求之外, 一個伺服器還必須(MUST)支援以下核心協定以保證相容性:
o 在地址中應用[STRINGPREP] 的 [NAMEPREP], Nodeprep (附錄 A),和 Resourceprep (附錄 B) profiles (包括確保域ID是[IDNA]中定義的國際化功能變數名稱)
o XML流(第四章), 包括Use of TLS(第五章), Use of SASL(第六章), 和Resource Binding (第七章)
o 三個在stanza semantics(第九章第二節)中已定義的節類型(即,＜message/＞, ＜presence/＞, 和＜iq/＞)的基本語義
o 生成錯誤的語法及相關的流, TLS, SASL, 和 XML節的語義
另外, 一個伺服器可以(MAY)支援以下核心協定:
o 伺服器回撥 (第八章)
@IDNA Internationalizing Domain Names in Applications =＞ http://www.ietf.org/rfc/rfc3490.txt
為國際域名應用協定,將域名to ascii and to unicode的程序來達到國際化域名的應用
@STRINGPREP =＞ rfc3454 http://www.ietf.org/rfc/rfc3454.txt
是字串辨識(比對)的標準協定,規範內容大概如下:
1. 字型的運用
2. 對於input and output字元的使用
3. 字串比對
4. unicode的標準化
5. 禁止的字元
6. 字串雙向性的問題
@NAMEPREP =＞ rfc3491 http://www.ietf.org/rfc/rfc3491.txt
是使用在domain name system 上的協定
主要是儘可能將IDN在經過對照（Mapping）、正規化（Normalization）、禁止檢查（Prohibition）的處理後，得到一個符合IDN規格的形式。
________________________________________
12.2. 用戶端 (Clients)
一個用戶端必須(MUST)支援以下核心協定以滿足相容性:
o XML流(第四章), 包括Use of TLS(第五章), Use of SASL(第六章), 和Resource Binding (第七章)
o 三個在stanza semantics(第九章第二節)中已定義的節類型(即,＜message/＞, ＜presence/＞, 和＜iq/＞)的基本語義
o 處理(並且, 如果可能, 生成) 錯誤的語法及相關的流, TLS, SASL, 和 XML節的語義
另外, 一個用戶端應該(SHOULD)支援以下核心協定:
o 地址的生成應用[STRINGPREP] 的 [NAMEPREP], Nodeprep (附錄 A),和 Resourceprep (附錄 B) profiles
________________________________________
13. 國際化事項 (Internationalization Considerations)
XML流在Character Encoding(第十一章第五節)中定義為必須(MUST)被編碼成UTF-8. 在Stream Attributes(第四章第四節)中特別定義了, 一個XML流應該(SHOULD)包含一個'xml:lang'屬性,它被認為是通過這個用於人類用戶解讀的流發送的任何XML字元資料的預設語言. 在 xml:lang (第九章第一節第五小節)特別定義了, 如果一個XML節是用來給人類用戶解讀，這個節應該（SHOULD）包含一個'xml:lang'屬性. 伺服器在為連接的實體路由或遞送節的時候應該（SHOULD）應用預設的'xml:lang'屬性, 並且不能（MUST NOT）修改或刪除它從其他實體收到的節的'xml:lang'屬性.
＜message from='juliet@example.com' to='romeo@example.net' xml:lang='en'＞
＜body＞Art thou not Romeo, and a Montague?＜/body＞
＜/message＞ en 英語 zh華語 ja日語 …
________________________________________
14. 安全性事項 (Security Considerations)
________________________________________
14.1. 高安全性 (High Security)
為了XMPP通信的目的(用戶端-伺服器 和 伺服器-伺服器), "高安全性"條款談的是相互驗證和完整性檢查安全性技術的使用; 特別是, 當使用基於憑證的驗證來提供高安全性, 應該（ SHOULD）建立一個帶外的信任鏈,儘管一個共用簽名憑證可能允許以前不知道的憑證在帶內建立信任關係. 參見以下第十四章第二節關於憑證確認程式. 實施必須（MUST）支持高安全性. 服務提供者應該（SHOULD）基於本地安全策略使用高安全性. ________________________________________
14.2. 憑證確認 (Certificate Validation) (?)
當一個XMPP點和另一個XMPP點安全的地通信, 它必須（MUST）確認對方終端的憑證.有三種可能的情況:
情形 #1: 點包含一個終端實體憑證，以根憑證的憑證鏈中一環出現(見[X509]中的第六章第一節).
情形 #2: 點的憑證由一個對方不知道的憑證授權.
情形 #3: 點的憑證由自己簽名.
在情形#1, 確認方必須(MUST)做以下兩點之一:
1. 根據[X509]的規則確認對方憑證.然後憑證應該(SHOULD)被對方接下來在[HTTP-TLS]中描述的規則反向確認預期的身份。但如果"xmpp"是subjectAltName擴展類型，則必須（MUST）使用憑證中的顯示的身份。如果這兩項檢查之一失敗,用戶導向的用戶端必須（MUST）通知用戶（用戶端可以（MAY）給用戶機會繼續連接）或以一個壞憑證的錯誤終止連接。自動用戶端應該（SHOULD）終止連接(以一個壞憑證錯誤)並在適當的日誌中記錄這個錯誤。自動用戶端可以（MAY）提供一個配置設置成禁止檢查,但同時必須（MUST）提供一個啟動檢查的配置。
2. 點應該（SHOULD）出示憑證給一個用戶用於批准,包括完整的憑證鏈.點必須（MUST）緩存這個憑證(或一些其他不會忘記的表達方式比如一個哈希值).在將來的連接中,點必須（MUST）展示相同的憑證並且如果改變了憑證必須（MUST）通知用戶.
在情形#2 和情形#3, 實現應該（SHOULD）執行上述第二條.
________________________________________
14.3. 用戶端-伺服器通信 (Client-to-Server Communications)
一個相容的用戶端實現必須（MUST）支持TLS和SASL用於連接到伺服器.
用於加密XML流的TLS協議(在 Use of TLS(第五章)定義)提供可信的機制幫助確保機密性和實體之間資料交換的完整性.
用於驗證XML流的SASL協定(在 Use of SASL(第六章)定義)提供可靠的機制用於確認一個連接到伺服器的用戶端確實是它自己所聲明的那個用戶端.
伺服器宣稱的DNS主機名被解析之前，用戶端-伺服器通信不能（MUST NOT）繼續進行。應該首先嘗試解析[SRV]記錄，其服務名為"xmpp-client"，協議名為"tcp"，整個資源記錄類似"_xmpp-client._tcp.example.com."(使用字元"xmpp-client"表示服務ID是經過IANA註冊).如果SRV查找失敗,退而求其次，將查找一個正規的IPv4/IPv6位址記錄來決定IP位址，使用"xmpp-client"埠5222，這個埠是在IANA註冊了的。
用戶端的IP位址和訪問方法不能（MUST NOT）被伺服器公開, 也不能被被任何原始伺服器之外的伺服器索取。這幫助保護用戶端的伺服器避免受到直接攻擊（譯者注：似乎應該是客戶避免受到直接攻擊，但原文如此）或被第三方知道它的身份。
@IANA =＞ Internet Assigned Numbers Authority 網際網路號分配機構。負責對IP位址分配規劃以及對TCP/UDP公共服務的埠定義。
________________________________________
14.4. 伺服器-伺服器通信 (Server-to-Server Communications)
一個相容的伺服器實現必須（MUST）支持TLS和SASL，用於域間的通信.因為歷史原因,一個相容的實施也應該（SHOULD）支持伺服器回撥(第八章).
因為服務提供者是一個策略問題,對於任何給定域和其他域的通信中，它是可選的（OPTIONAL），伺服器之間的通信可以（MAY）被任何特定部署的管理員禁止。如果一個特殊的域允許域間的通信，它應該（SHOULD）允許高安全性。
管理員可能想在伺服器間使用SASL來通信，以確保雙方的驗證和保密性(比如在機構的私有網路).相容實施應該（SHOULD）為這個目的支援SASL.
伺服器宣稱的DNS主機名被解析之前，伺服器-伺服器通信不能（MUST NOT）繼續進行。應該首先嘗試解析[SRV]記錄，其服務名為"xmpp-server"，協議名為"tcp"，整個資源記錄類似"_xmpp-server._tcp.example.com."(使用字元"xmpp-server"表示服務ID是經過IANA註冊的，注意要用"xmpp-server"取代以前用的"jabber",因為以前的用法不符合[SRV]標準；希望保持向後相容的實現可以繼續查找或應答"jabber"服務ID).如果SRV查找失敗,退而求其次，將查找一個正規的IPv4/IPv6位址記錄來決定IP位址，使用"xmpp-server"埠5269，這個埠是在IANA註冊了的。
伺服器回撥防止域欺騙,從而使得偽造XML節更為困難.它和SASL和TLS不一樣，它不是一個用於驗證、安全或加密伺服器之間的流的機制, 所以只是伺服器身份的微弱確認而已。而且除非它使用了DNSSec [DNSSEC]否則它容易受到DNS中毒攻擊,即使DNS資訊是正確的,如果攻擊者劫持了遠程域,回撥也不能防止它的攻擊.需要健壯的安全性的域應該(SHOULD)使用TLS和SASL.如果伺服器間的驗證使用了SASL,回撥就不應該(SHOULD NOT)使用了,因為它是多餘的.
________________________________________
14.5. 層的次序 (Order of Layers)
協議中的層的次序必須(MUST)如下堆積:
1. TCP
2. TLS
3. SASL
4. XMPP
這個次序的原理是,[TCP]是基於連接的層,被所有使用,所以處於最上層, [TLS]經常是由作業系統層提供,[SASL]經常由應用程式層提供, XMPP則是應用程式本身.
________________________________________
14.6. 缺乏綁定到TLS的SASL通道 (Lack of SASL Channel Binding to TLS)(?)
SASL構架不提供一個機制來綁定SASL驗證到一個提供機密性和完整性保護的安全層。這一通道綁定"channel binding"的缺乏阻礙了SASL確認低層安全性所綁定的源和目標終端和SASL所驗證的結果是否一致。如果終端不一致, 低層安全性不能被信任用來保護SASL驗證的實體之間的資料傳輸。在這種情況下，一個SASL安全層進行握手的時候應該有效的忽略低層安全性的存在。
________________________________________
14.7. 強制實現的技術 (Mandatory-to-Implement Technologies)
最低要求, 所有實現必須（MUST）支持以下機制:
對於驗證: SASL [DIGEST-MD5] 機制
對於機密性: TLS (使用 TLS_RSA_WITH_3DES_EDE_CBC_SHA 密碼)
對於兩者: TLS 加 SASL EXTERNAL(使用 TLS_RSA_WITH_3DES_EDE_CBC_SHA 密碼支援用戶端憑證)
________________________________________
14.8. 防火牆 (Firewalls)
使用XMPP通信通常是通過[TCP]連接到5222埠(用戶端-伺服器)或5269埠(伺服器-伺服器), 正如在IANA註冊的那樣(見 IANA Considerations (第十五章)). 使用這些廣為人知的埠允許管理員很容易的通過一般的防火牆來啟動或禁止XMPP活動.
________________________________________
14.9. 在SASL中使用base64
用戶端和伺服器都必須（MUST）確認在SASL協商中收到的任何[BASE64]資料. 一個實現必須(MUST)拒絕(不是忽略)任何非顯式允許base64字母的字串; 這有助於預防建立隱蔽通道洩漏資訊的行為。一個實現不能（MUST NOT）在非法輸入處中斷，如果那個('=')被包含在一些和最後的資料字元(如, "=AAA" or "BBBB=CCC")不同的東西裏面，必須(MUST)拒絕接下來的任何包含('=')的base64字元；這有助於防止對這個實現的緩存溢出攻擊和其他攻擊。Base 64編碼從外表看隱藏了容易辨認的資訊，例如密碼，但是不提供任何演算法機密性。Base 64編碼必須（MUST）按照RFC 3548[BASE64]第三章的定義執行。
________________________________________
14.10. Stringprep Profiles
為了處理域ID,XMPP使用了[STRINGPREP]中的[NAMEPREP] profile; 和Nameprep有關的安全性考慮, 參考[NAMEPREP]中的相關章節.
另外, XMPP 定義了兩個[STRINGPREP]的 profiles: 用於node identifiers的Nodeprep(附錄 A)和用於resource identifiers的Resourceprep(附錄 B).
Unicode 和 ISO/IEC 10646 集有許多字元看起來相似. 在許多時候, 安全協議的使用者可能看起來吻合,比如當比較信任的第三方的名字的時候. 因為沒有很多上下文的時候不可能映射看起來相似的字元,比如知道所用的字元集, stringprep不匹配相似字串,也不因為一些字串看起來像別的字串而禁止它們.
一個節點ID可能被作為一個實體的XMPP位址的一部分. 一個通常的用途是作為一個即時消息用戶的用戶名；另一個用途是作為一個多用途聊天室的名字; 很多其他種類的實體可能使用節點ID作為他們的位址的一部分。 這些服務的安全性可能會受到國際化節點ID的不同表達的威脅;例如, 一個用戶鍵入一個單獨的國際化的節點ID可能訪問了另一個用戶的帳號資訊, 或一個用戶可能獲得訪問一個受限的聊天室或服務的訪問許可權.
一個資源ID可能被作為一個實體的XMPP位址的一部分。一個通常的用戶是即時消息用戶所連接的資源(啟動的會話)的名字; 另一個是作為多用戶聊天室的某用戶的昵稱; 許多其他種類的實體可能使用資源ID作為他們位址的一部分.這些服務的安全性可能會受到國際化資源ID的不同表達的威脅;例如, 一個用戶可能嘗試以同一個名字初始化多個會話,或一個用戶可能發送一個消息給多用戶聊天室的一個人但實際上發給了另外一個人.
________________________________________
15. IANA 事項 (IANA Considerations)
________________________________________
15.1. 用於TLS資料的XML名字空間名
XMPP中用於TLS相關資料的 URN 子名字空間定義如下. (這個名字空間的名字遵守The IETF XML Registry [XML-REG]定義的格式.)
@IETF =＞internet enginner task force(負責網際網路標準研究及制定的組織)
URI: urn:ietf:params:xml:ns:xmpp-tls
________________________________________
15.2. 用於SASL資料的XML名字空間名
XMPP中用於SASL相關資料的 URN 子名字空間定義如下. (這個名字空間的名字遵守The IETF XML Registry [XML-REG]定義的格式.)
URI: urn:ietf:params:xml:ns:xmpp-sasl
＜stream:features＞
＜starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'＞
＜required/＞
＜/starttls＞
＜mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'＞
＜mechanism＞DIGEST-MD5＜/mechanism＞
＜mechanism＞PLAIN＜/mechanism＞
＜/mechanisms＞
＜/stream:features＞
________________________________________
15.3. 用於流錯誤的XML名字空間名
XMPP中用於流相關錯誤的 URN 子名字空間定義如下. (這個名字空間的名字遵守The IETF XML Registry [XML-REG]定義的格式.)
URI: urn:ietf:params:xml:ns:xmpp-streams
＜stream:error＞
＜xml-not-well-formed xmlns='urn:ietf:params:xml:ns:xmpp-streams'/＞
＜/stream:error＞
________________________________________
15.4. 用於資源綁定的XML名字空間名
XMPP中用於資源綁定的 URN 子名字空間定義如下. (這個名字空間的名字遵守The IETF XML Registry [XML-REG]定義的格式.)
URI: urn:ietf:params:xml:ns:xmpp-bind
＜stream:features＞
＜bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/＞
＜/stream:features＞
________________________________________
15.5. 用於節錯誤的XML名字空間名
XMPP中用於節相關錯誤資料的 URN 子名字空間定義如下. (這個名字空間的名字遵守The IETF XML Registry [XML-REG]定義的格式.)
URI: urn:ietf:params:xml:ns:xmpp-stanzas
＜stanza-kind to='sender' type='error'＞
＜error type='error-type'＞
＜defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/＞
＜text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas' xml:lang='langcode'＞OPTIONAL descriptive text＜/text＞
＜/error＞
＜/stanza-kind＞
________________________________________
15.6. Nodeprep Profile of Stringprep
The Nodeprep profile of stringprep是在Nodeprep(附錄 A)定義的. IANA已經在stringprep profile registry中註冊了 Nodeprep.
________________________________________
15.7. Resourceprep Profile of Stringprep
The Resourceprep profile of stringprep是在Resourceprep(附錄 B)定義的. IANA已經在stringprep profile registry中註冊了Resourceprep.
________________________________________
15.8. GSSAPI 服務名
IANA已經註冊了 "xmpp" 作為一個 GSSAPI [GSS-API] 服務名, 在SASL Definition (第六章第三節)定義
@GSSAPI =＞ Generic Security Services Application Programming Interface
通用安全服務應用程式程介面，它提供了一個通用的認證和安全訊息傳遞介面
http://www.faqs.org/rfcs/rfc2743.html
________________________________________
15.9. 埠號
IANA已經註冊了"xmpp-client" 和 "xmpp-server" 作為[TCP]埠號5222和5269的關鍵字.
這些埠應該（SHOULD）用於用戶端-伺服器 和 伺服器-伺服器通信,但它們的使用是可選的（OPTIONAL）.
________________________________________
參考資料:
Punycode =＞ http://www.ietf.org/rfc/rfc3492.txt
http://xn--fx5a34a.xn--fiqp7jnrek3iomgb4cbweev5d.tw/IDN.pdf
http://hi.baidu.com/jabber/blog/category/Jep
http://wiki.jabbercn.org/space/start
10. 伺服器處理XML節的規則 (Server Rules for Handling XML Stanzas)
相容的伺服器實做必須（MUST）確保兩個實體之間的XML節按次序處理. 除了按次序處理的需求之外, 每個伺服器實作將包含它自己的遞送樹"delivery tree"以處理它接收到的節.這個樹決定一個節是否需要路由到其他域, 在內部處理, 還是遞送到和一個已連接的節點相關的資源. 以下規則適用:
________________________________________
10.1. 沒有'to'地址 (No 'to' Address)
如果這個節沒有'to'屬性, 伺服器應該(SHOULD)為發送它的實體處理這個節. 因為所有從其他伺服器收到的節必須(MUST)擁有'to'屬性, 這個規則僅適用於從一個連接到這台伺服器的已註冊實體(如一個用戶端)收到的節,如果這個伺服器收到一個沒有'to'屬性的出席資訊節, 伺服器應該(SHOULD)向那些訂閱了這個發送實體的出席資訊的所有實體廣播它, 如果可能的話(即時消息和出席資訊應用程式中出席資訊廣播的語義定義在XMPP-IM). 如果伺服器接收到一個IQ類型為 "get" 或 "set" 且沒有'to'屬性的節並且它理解這個節的名字空間下的內容, 它必須(MUST)為這個發送實體處理節(在這裏"處理"的含義是由相關的名字空間的語義所決定的)或返回一個錯誤給發送實體.
#c to s 可以不用有 to 屬性 ,因為c to s 預設的 to 即是 server
#若是出席訊息＜presence＞沒有to屬性,即為廣播給所有訂閱者,rfc3921第五章說明如下:
(5.1.1初始化出席資訊 :
建立起一個會話之後, 一個用戶端應該(SHOULD)發送初始化出席資訊給伺服器來通知它的通信可用性.如這裏定義的, 初始化出席資訊節 (1) 必須(MUST) 不擁有'to'屬性(這表示它是由伺服器代替用戶端發送的廣播) 並且 (2) 必須(MUST) 不擁有'type'屬性).
________________________________________
10.2. 外部域 (Foreign Domain) (s to s)
如果'to'屬性中的JID的域ID部分的主機名和伺服器自身或其子域配置的主機名不匹配, 伺服器應該（SHOULD）路由這個節到外部域(取決於本地服務規定或安全策略關於域間通信的規定).有兩種可能的情況:
- 一個伺服器to伺服器之間的流已經存在於兩個域之間: 發送者的伺服器透過這個已存在的流為這個外部域路由(轉送)這個節到授權伺服器 - 兩個域之間沒有伺服器to伺服器之間的流: 發送者伺服器 (1) 解析這個外部域的主機名(定義在伺服器間的通信Server-to-Server Communications (第十四章第四節)), (2) 在兩個域之間進行伺服器到伺服器的流協商(定義在 Use of TLS (第五章) 和 Use of SASL (第六章)), 然後 (3) 通過這個新建的流為外部域路由(轉送)這個節到授權伺服器
如果路由(轉送)到接收者的伺服器不成功, 發送者的伺服器必須（MUST）返回一個錯誤給發送者; 如果接收者的伺服器聯繫上了但是從接收者的伺服器遞送到接收者不成功, 接收者伺服器必須（MUST）透過發送者的伺服器返回一個錯誤給發送者.
________________________________________
10.3. 子域 (Subdomain) (?)
如果'to'屬性中的JID的域ID部分的主機名和伺服器自身配置的主機名的一個子功能變數名稱匹配,伺服器必須（MUST）自己處理這個節或路由這個節到專門負責這個子域的特定服務(如果子域被配置了),或者返回一個錯誤給發送者(如果子域沒有配置).
________________________________________
10.4. 純粹的域或特定的資源 (Mere Domain or Specific Resource)
如果'to'屬性中的JID的域ID部分的主機名和伺服器自身配置的主機名本身匹配,並且'to'屬性中的JID類型是＜domain＞ 或 ＜domain/resource＞, 伺服器(或其中定義的資源)必須（MUST）根據節的類型適當的處理這個節或返回一個錯誤節給發送者.
________________________________________
10.5. 同一域中的節點 (Node in Same Domain)
如果'to'屬性中的JID的域ID部分的主機名和伺服器自身配置的主機名本身匹配,並且'to'屬性中的JID類型是＜node@domain＞ 或 ＜node@domain/resource＞, 伺服器應該(SHOULD)遞送這個節到'to'屬性中的JID所指明的預定的接收者. 以下規則適用:
1. 如果這個JID包含一個資源ID(例如, 格式是＜node@domain/resource＞)並且存在一個連接的資源符合這個全JID, 接收者伺服器應該（SHOULD）遞送這個節給正確符合這個資源ID的流或會話.
2. 如果這個JID包含一個資源ID(例如, 格式是＜node@domain/resource＞)並且不存在一個連接的資源符合這個全JID, 接收者伺服器應該（SHOULD）返回一個＜service-unavailable/＞ 節錯誤給發送者.
3. 如果這個JID的格式是＜node@domain＞並且存在至少一個此節點的連接資源, 接收伺服器應該（ SHOULD）遞送這個節給至少其中一個已連接的資源, 依據應用程式定義的規則(一系列即時消息和出席資訊應用程式的遞送規則定義在XMPP-IM).
@Rfc3921第11章 伺服器處理XML節的規則有詳細的說明如下:
如果JID的格式是＜user@domain＞並且這個用戶至少有一個可用的資源, 接收者的伺服器必須(MUST)遵守以下規則:
1. 對於消息(message)節, 伺服器應該(SHOULD)遞送這個節給高優先順序的可用資源(如果這個資源沒有提供＜priority/＞元素的值, 伺服器應該(SHOULD)認為它提供的值為零). 如果兩個或更多的可用資源有相同的優先順序, 伺服器可以(MAY)使用一些其他的規則(例如, 最近的連接時間, 最近的活動時間, 或由一些＜show/＞值的層次所定義的最高的可用性) 來從它們中間選擇,或可以(MAY)遞送這個消息到所有這些資源. 無論如何, 伺服器不能(MUST NOT)遞送這個節到一個優先順序為負數的可用資源; 如果唯一的一個可用資源的優先順序是負數, 伺服器應該(SHOULD)當成沒有可用資源一樣處理這個消息(定義在後面). 另外, 伺服器不能(MUST NOT)重寫'to'屬性(換言之, 它必須(MUST)讓它保持＜user@domain＞而不是改成＜user@domain/resource＞).
2. 對於類型不是"probe"(探測)的出席資訊節, 伺服器必須(MUST)遞送這個節給所有可用的資源;對於出席資訊調查, 伺服器應該(SHOULD)基於定義在 出席資訊調查Presence Probes (第五章第一節第三小節)的規則來應答. 另外, 伺服器不能(MUST NOT)重寫'to'屬性(換言之, 它必須(MUST)保持＜user@domain＞而不是改為＜user@domain/resource＞).
3. 對於IQ節, 伺服器本身必須(MUST)代替用戶應答一個IQ result或一個IQ error, 並且不能(MUST NOT)遞送這個IQ節給任何可用的資源. 具體來說, 如果合格的名字空間的語義定義了一個伺服器可以提供的應答, 伺服器必須(MUST)代替用戶應答這個節; 如果沒有, 伺服器必須(MUST)應答一個＜service-unavailable/＞節錯誤.
＜presence from='juliet@example.com/balcony'＞
＜priority＞13＜/priority＞ =＞ whose value is an integer between -128 and +127. rfc3921 2.2.2.3
＜/presence＞
＜presence from='juliet@example.com/balcony'＞
＜show＞away＜/show＞ =＞ chat dnd xa rfc3921 2.2.2.1
＜/presence＞
________________________________________
11. XMPP中的XML用法 (XML Usage within XMPP)
________________________________________
11.1. 限制 (Restrictions)
XMPP是一個簡單的流式XML元素的專用協定用於接近即時地交換結構化資訊. 因為XMPP不需要任意的解析和所有的XML文檔, 所以XMPP不需要支援[XML]的所有功能. 特殊的, 適用以下限制.
關於XML生成, 一個XMPP實作不能(MUST NOT)在XML流中注入以下任何東西:
o 注釋 (第二章第五節[XML]) ,如 ＜!--XXX--＞
o 處理指令(第二章第六節 同上) , target content parent
o 內部或外部的 DTD 子集 (第二章第八節 同上)
o 內部或外部的實體參考 (第四章第二節 同上) 除了預定實體以外(第四章第六節 同上)
o 字元資料或屬性值包含和預定實體列表中吻合的未逸出的unescaped字元(第四章第六節 同上); 這些字元必須（MUST）逸出 ,如 & ＜ ＞ …
關於XML處理, 如果一個XMPP實現接收到這些受限的XML資料,它必須（MUST）忽略這些資料.
________________________________________
11.2. XML 命名空間的名字和前綴詞 (XML Namespace Names and Prefixes)
XML名字空間[XML-NAMES]為所有XMPP相容的XML建立資料所有權的嚴格界限. 這個名字空間的基本功能是把結構上混合在一起的XML元素區分出不同的辭彙. 確保XMPP相容的XML有名字空間的感知能力使得任何允許的XML可以被結構化的混合到任何XMPP資料元素中. XML名字空間的名字和首碼的規則在下一小節中.
________________________________________
11.2.1. 流命名空間 (Streams Namespace)
在所有的XML流頭中必須聲明一個流名字空間. 流名字空間必須（MUST）是 'http://etherx.jabber.org/streams'. 元素名＜stream/＞和它的＜features/＞和＜error/＞子元素必須（MUST）在所有實例中符合這個流名字空間首碼. 一個實作應該（SHOULD）只為這些元素生成'stream:'首碼, 並且由於歷史原因可以（MAY）只接受'stream:'首碼.
________________________________________
11.2.2. 預設命名空間 (Default Namespace)
在所有的XML流中必須聲明一個預設的流名字空間用於定義允許的流根元素的一級子元素. 這個名字空間聲明對於初始化流和應答流必須（MUST）是相同的使得雙方的流都是合格一致的. 預設的名字空間聲明適用於流和所有在流中發送的節(除非由流名字空間或回撥名字空間的首碼顯式的符合另一個名字空間).
一個伺服器實現必須（MUST）支持以下兩個預設名字空間(由於歷史原因, 一些實現可能(MAY)只支持這兩個預設名字空間):
o jabber:client -- 當流用於用戶端和伺服器的通信時聲明這個預設名字空間
o jabber:server -- 當流用於兩個伺服器間的通信時聲明這個預設名字空間
＜?xml version='1.0'?＞
＜stream:stream
to='127.0.0.1'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'＞
一個用戶端實作必須（MUST）支持'jabber:client'預設名字空間,並且由於歷史原因可以（MAY）只支持這個預設名字空間.
如果預設名字空間是'jabber:client'或'jabber:server'，一個實作不能（MUST NOT）在這個名字空間下為元素生成名字空間前綴詞. 一個實作不應該（SHOULD NOT）按照元素的內容（可能和流相反）生成不同於'jabber:client'和'jabber:server'名字空間前綴詞.
注意: 'jabber:client' 和 'jabber:server' 名字空間接近於相同但是用於不同的上下文(用戶端伺服器通信用'jabber:client' 而伺服器間通信用'jabber:server'). 這兩者之間僅有的不同在於在'jabber:client'中被發送的節中'to'和'from'屬性是可選的（OPTIONAL）,而在'jabber:server'中被發送的節中它們是必需的（REQUIRED）. 如果相容的實施接受一個符合'jabber:client'或'jabber:server'名字空間的流, 它必須（MUST）支援通用屬性(第九章第一節)和三個核心節類型(message, presence, 和IQ)的基本語義(第九章第二節).
________________________________________
11.2.3. 回撥名字空間 (Dialback Namespace)(?)
所有用於伺服器回撥的(第八章)元素都必須聲明一個回撥名字空間. 回撥名字空間的名字必須（MUST）是'jabber:server:dialback'. 所有符合此名字空間的元素必須（MUST）有首碼. 一個實現應該（SHOULD）只為這些元素生成'db:'首碼並且只可以（MAY）接受'db:'首碼.
________________________________________
11.3. 確認 (Validation)
除了注意'jabber:server'名字空間中關於節中'to'和'from'位址的規定,一個伺服器不需要為轉發到用戶端或其他伺服器負責檢查XML元素;一個實作可以（MAY）選擇僅提供有效資料元素但這是可選的（OPTIONAL）. 用戶端不應該（SHOULD NOT）濫用發送不符合schema的資料的能力, 並且應該（SHOULD）忽略接收到的XML流中任何和schema不一致的元素或屬性值. XML流和節的有效性確認是可選的（OPTIONAL）,並且在這裏提到的schemas僅用於描述的用途.
________________________________________
11.4. 文本聲明的包含 (Inclusion of Text Declaration)(?)
實現應該（SHOULD）在發送一個流標頭資訊之前發送一個文本聲明. 應用程式必須（MUST）遵守[XML]中關於環境（那裏對文本聲明做了規定）的規則.
________________________________________
11.5. 字元編碼 (Character Encoding)
Implementations MUST support the UTF-8 (RFC 3629 [UTF 8]) transformation of Universal Character Set (ISO/IEC 10646-1 [UCS2]) characters, as required by RFC 2277 [CHARSET]. Implementations MUST NOT attempt to use any other encoding.
實作必須（MUST）支援通用字元集Universal Character Set (ISO/IEC 10646-1 [UCS2])字元到UTF-8(RFC 3629 [UTF-8])的轉換, 必須符合 RFC 2277 [CHARSET]. 實作不能（MUST NOT）試圖使用任何其他的編碼.
@UTF-8為Unicode編碼的一種轉換格式,UCS2 為Unicode 雙字節編碼規範
________________________________________
12. 核心的相容性要求 (Core Compliance Requirements)
本章總結了可擴展的消息和出席資訊協定中的某些方面，為了實施的相容性，它們必須（MUST）被伺服器和用戶端支援，當然協定的其他方面也應該（SHOULD）被支持. 為了相容的目的, 我們在核心協議和即時消息協定之間劃了一個級別. 在本章中定義了所有伺服器和用戶端的相容性要求; 即時消息伺服器和用戶端的相容性要求在XMPP-IM的相關章節中定義.
________________________________________
12.1. 伺服器 (Servers)
除了所有已定義的關於安全, XML使用, 和國際化的要求之外, 一個伺服器還必須(MUST)支援以下核心協定以保證相容性:
o 在地址中應用[STRINGPREP] 的 [NAMEPREP], Nodeprep (附錄 A),和 Resourceprep (附錄 B) profiles (包括確保域ID是[IDNA]中定義的國際化功能變數名稱)
o XML流(第四章), 包括Use of TLS(第五章), Use of SASL(第六章), 和Resource Binding (第七章)
o 三個在stanza semantics(第九章第二節)中已定義的節類型(即,＜message/＞, ＜presence/＞, 和＜iq/＞)的基本語義
o 生成錯誤的語法及相關的流, TLS, SASL, 和 XML節的語義
另外, 一個伺服器可以(MAY)支援以下核心協定:
o 伺服器回撥 (第八章)
@IDNA Internationalizing Domain Names in Applications =＞ http://www.ietf.org/rfc/rfc3490.txt
為國際域名應用協定,將域名to ascii and to unicode的程序來達到國際化域名的應用
@STRINGPREP =＞ rfc3454 http://www.ietf.org/rfc/rfc3454.txt
是字串辨識(比對)的標準協定,規範內容大概如下:
1. 字型的運用
2. 對於input and output字元的使用
3. 字串比對
4. unicode的標準化
5. 禁止的字元
6. 字串雙向性的問題
@NAMEPREP =＞ rfc3491 http://www.ietf.org/rfc/rfc3491.txt
是使用在domain name system 上的協定
主要是儘可能將IDN在經過對照（Mapping）、正規化（Normalization）、禁止檢查（Prohibition）的處理後，得到一個符合IDN規格的形式。
________________________________________
12.2. 用戶端 (Clients)
一個用戶端必須(MUST)支援以下核心協定以滿足相容性:
o XML流(第四章), 包括Use of TLS(第五章), Use of SASL(第六章), 和Resource Binding (第七章)
o 三個在stanza semantics(第九章第二節)中已定義的節類型(即,＜message/＞, ＜presence/＞, 和＜iq/＞)的基本語義
o 處理(並且, 如果可能, 生成) 錯誤的語法及相關的流, TLS, SASL, 和 XML節的語義
另外, 一個用戶端應該(SHOULD)支援以下核心協定:
o 地址的生成應用[STRINGPREP] 的 [NAMEPREP], Nodeprep (附錄 A),和 Resourceprep (附錄 B) profiles
________________________________________
13. 國際化事項 (Internationalization Considerations)
XML流在Character Encoding(第十一章第五節)中定義為必須(MUST)被編碼成UTF-8. 在Stream Attributes(第四章第四節)中特別定義了, 一個XML流應該(SHOULD)包含一個'xml:lang'屬性,它被認為是通過這個用於人類用戶解讀的流發送的任何XML字元資料的預設語言. 在 xml:lang (第九章第一節第五小節)特別定義了, 如果一個XML節是用來給人類用戶解讀，這個節應該（SHOULD）包含一個'xml:lang'屬性. 伺服器在為連接的實體路由或遞送節的時候應該（SHOULD）應用預設的'xml:lang'屬性, 並且不能（MUST NOT）修改或刪除它從其他實體收到的節的'xml:lang'屬性.
＜message from='juliet@example.com' to='romeo@example.net' xml:lang='en'＞
＜body＞Art thou not Romeo, and a Montague?＜/body＞
＜/message＞ en 英語 zh華語 ja日語 …
________________________________________
14. 安全性事項 (Security Considerations)
________________________________________
14.1. 高安全性 (High Security)
為了XMPP通信的目的(用戶端-伺服器 和 伺服器-伺服器), "高安全性"條款談的是相互驗證和完整性檢查安全性技術的使用; 特別是, 當使用基於憑證的驗證來提供高安全性, 應該（ SHOULD）建立一個帶外的信任鏈,儘管一個共用簽名憑證可能允許以前不知道的憑證在帶內建立信任關係. 參見以下第十四章第二節關於憑證確認程式. 實施必須（MUST）支持高安全性. 服務提供者應該（SHOULD）基於本地安全策略使用高安全性. ________________________________________
14.2. 憑證確認 (Certificate Validation) (?)
當一個XMPP點和另一個XMPP點安全的地通信, 它必須（MUST）確認對方終端的憑證.有三種可能的情況:
情形 #1: 點包含一個終端實體憑證，以根憑證的憑證鏈中一環出現(見[X509]中的第六章第一節).
情形 #2: 點的憑證由一個對方不知道的憑證授權.
情形 #3: 點的憑證由自己簽名.
在情形#1, 確認方必須(MUST)做以下兩點之一:
1. 根據[X509]的規則確認對方憑證.然後憑證應該(SHOULD)被對方接下來在[HTTP-TLS]中描述的規則反向確認預期的身份。但如果"xmpp"是subjectAltName擴展類型，則必須（MUST）使用憑證中的顯示的身份。如果這兩項檢查之一失敗,用戶導向的用戶端必須（MUST）通知用戶（用戶端可以（MAY）給用戶機會繼續連接）或以一個壞憑證的錯誤終止連接。自動用戶端應該（SHOULD）終止連接(以一個壞憑證錯誤)並在適當的日誌中記錄這個錯誤。自動用戶端可以（MAY）提供一個配置設置成禁止檢查,但同時必須（MUST）提供一個啟動檢查的配置。
2. 點應該（SHOULD）出示憑證給一個用戶用於批准,包括完整的憑證鏈.點必須（MUST）緩存這個憑證(或一些其他不會忘記的表達方式比如一個哈希值).在將來的連接中,點必須（MUST）展示相同的憑證並且如果改變了憑證必須（MUST）通知用戶.
在情形#2 和情形#3, 實現應該（SHOULD）執行上述第二條.
________________________________________
14.3. 用戶端-伺服器通信 (Client-to-Server Communications)
一個相容的用戶端實現必須（MUST）支持TLS和SASL用於連接到伺服器.
用於加密XML流的TLS協議(在 Use of TLS(第五章)定義)提供可信的機制幫助確保機密性和實體之間資料交換的完整性.
用於驗證XML流的SASL協定(在 Use of SASL(第六章)定義)提供可靠的機制用於確認一個連接到伺服器的用戶端確實是它自己所聲明的那個用戶端.
伺服器宣稱的DNS主機名被解析之前，用戶端-伺服器通信不能（MUST NOT）繼續進行。應該首先嘗試解析[SRV]記錄，其服務名為"xmpp-client"，協議名為"tcp"，整個資源記錄類似"_xmpp-client._tcp.example.com."(使用字元"xmpp-client"表示服務ID是經過IANA註冊).如果SRV查找失敗,退而求其次，將查找一個正規的IPv4/IPv6位址記錄來決定IP位址，使用"xmpp-client"埠5222，這個埠是在IANA註冊了的。
用戶端的IP位址和訪問方法不能（MUST NOT）被伺服器公開, 也不能被被任何原始伺服器之外的伺服器索取。這幫助保護用戶端的伺服器避免受到直接攻擊（譯者注：似乎應該是客戶避免受到直接攻擊，但原文如此）或被第三方知道它的身份。
@IANA =＞ Internet Assigned Numbers Authority 網際網路號分配機構。負責對IP位址分配規劃以及對TCP/UDP公共服務的埠定義。
________________________________________
14.4. 伺服器-伺服器通信 (Server-to-Server Communications)
一個相容的伺服器實現必須（MUST）支持TLS和SASL，用於域間的通信.因為歷史原因,一個相容的實施也應該（SHOULD）支持伺服器回撥(第八章).
因為服務提供者是一個策略問題,對於任何給定域和其他域的通信中，它是可選的（OPTIONAL），伺服器之間的通信可以（MAY）被任何特定部署的管理員禁止。如果一個特殊的域允許域間的通信，它應該（SHOULD）允許高安全性。
管理員可能想在伺服器間使用SASL來通信，以確保雙方的驗證和保密性(比如在機構的私有網路).相容實施應該（SHOULD）為這個目的支援SASL.
伺服器宣稱的DNS主機名被解析之前，伺服器-伺服器通信不能（MUST NOT）繼續進行。應該首先嘗試解析[SRV]記錄，其服務名為"xmpp-server"，協議名為"tcp"，整個資源記錄類似"_xmpp-server._tcp.example.com."(使用字元"xmpp-server"表示服務ID是經過IANA註冊的，注意要用"xmpp-server"取代以前用的"jabber",因為以前的用法不符合[SRV]標準；希望保持向後相容的實現可以繼續查找或應答"jabber"服務ID).如果SRV查找失敗,退而求其次，將查找一個正規的IPv4/IPv6位址記錄來決定IP位址，使用"xmpp-server"埠5269，這個埠是在IANA註冊了的。
伺服器回撥防止域欺騙,從而使得偽造XML節更為困難.它和SASL和TLS不一樣，它不是一個用於驗證、安全或加密伺服器之間的流的機制, 所以只是伺服器身份的微弱確認而已。而且除非它使用了DNSSec [DNSSEC]否則它容易受到DNS中毒攻擊,即使DNS資訊是正確的,如果攻擊者劫持了遠程域,回撥也不能防止它的攻擊.需要健壯的安全性的域應該(SHOULD)使用TLS和SASL.如果伺服器間的驗證使用了SASL,回撥就不應該(SHOULD NOT)使用了,因為它是多餘的.
________________________________________
14.5. 層的次序 (Order of Layers)
協議中的層的次序必須(MUST)如下堆積:
1. TCP
2. TLS
3. SASL
4. XMPP
這個次序的原理是,[TCP]是基於連接的層,被所有使用,所以處於最上層, [TLS]經常是由作業系統層提供,[SASL]經常由應用程式層提供, XMPP則是應用程式本身.
________________________________________
14.6. 缺乏綁定到TLS的SASL通道 (Lack of SASL Channel Binding to TLS)(?)
SASL構架不提供一個機制來綁定SASL驗證到一個提供機密性和完整性保護的安全層。這一通道綁定"channel binding"的缺乏阻礙了SASL確認低層安全性所綁定的源和目標終端和SASL所驗證的結果是否一致。如果終端不一致, 低層安全性不能被信任用來保護SASL驗證的實體之間的資料傳輸。在這種情況下，一個SASL安全層進行握手的時候應該有效的忽略低層安全性的存在。
________________________________________
14.7. 強制實現的技術 (Mandatory-to-Implement Technologies)
最低要求, 所有實現必須（MUST）支持以下機制:
對於驗證: SASL [DIGEST-MD5] 機制
對於機密性: TLS (使用 TLS_RSA_WITH_3DES_EDE_CBC_SHA 密碼)
對於兩者: TLS 加 SASL EXTERNAL(使用 TLS_RSA_WITH_3DES_EDE_CBC_SHA 密碼支援用戶端憑證)
________________________________________
14.8. 防火牆 (Firewalls)
使用XMPP通信通常是通過[TCP]連接到5222埠(用戶端-伺服器)或5269埠(伺服器-伺服器), 正如在IANA註冊的那樣(見 IANA Considerations (第十五章)). 使用這些廣為人知的埠允許管理員很容易的通過一般的防火牆來啟動或禁止XMPP活動.
________________________________________
14.9. 在SASL中使用base64
用戶端和伺服器都必須（MUST）確認在SASL協商中收到的任何[BASE64]資料. 一個實現必須(MUST)拒絕(不是忽略)任何非顯式允許base64字母的字串; 這有助於預防建立隱蔽通道洩漏資訊的行為。一個實現不能（MUST NOT）在非法輸入處中斷，如果那個('=')被包含在一些和最後的資料字元(如, "=AAA" or "BBBB=CCC")不同的東西裏面，必須(MUST)拒絕接下來的任何包含('=')的base64字元；這有助於防止對這個實現的緩存溢出攻擊和其他攻擊。Base 64編碼從外表看隱藏了容易辨認的資訊，例如密碼，但是不提供任何演算法機密性。Base 64編碼必須（MUST）按照RFC 3548[BASE64]第三章的定義執行。
________________________________________
14.10. Stringprep Profiles
為了處理域ID,XMPP使用了[STRINGPREP]中的[NAMEPREP] profile; 和Nameprep有關的安全性考慮, 參考[NAMEPREP]中的相關章節.
另外, XMPP 定義了兩個[STRINGPREP]的 profiles: 用於node identifiers的Nodeprep(附錄 A)和用於resource identifiers的Resourceprep(附錄 B).
Unicode 和 ISO/IEC 10646 集有許多字元看起來相似. 在許多時候, 安全協議的使用者可能看起來吻合,比如當比較信任的第三方的名字的時候. 因為沒有很多上下文的時候不可能映射看起來相似的字元,比如知道所用的字元集, stringprep不匹配相似字串,也不因為一些字串看起來像別的字串而禁止它們.
一個節點ID可能被作為一個實體的XMPP位址的一部分. 一個通常的用途是作為一個即時消息用戶的用戶名；另一個用途是作為一個多用途聊天室的名字; 很多其他種類的實體可能使用節點ID作為他們的位址的一部分。 這些服務的安全性可能會受到國際化節點ID的不同表達的威脅;例如, 一個用戶鍵入一個單獨的國際化的節點ID可能訪問了另一個用戶的帳號資訊, 或一個用戶可能獲得訪問一個受限的聊天室或服務的訪問許可權.
一個資源ID可能被作為一個實體的XMPP位址的一部分。一個通常的用戶是即時消息用戶所連接的資源(啟動的會話)的名字; 另一個是作為多用戶聊天室的某用戶的昵稱; 許多其他種類的實體可能使用資源ID作為他們位址的一部分.這些服務的安全性可能會受到國際化資源ID的不同表達的威脅;例如, 一個用戶可能嘗試以同一個名字初始化多個會話,或一個用戶可能發送一個消息給多用戶聊天室的一個人但實際上發給了另外一個人.
________________________________________
15. IANA 事項 (IANA Considerations)
________________________________________
15.1. 用於TLS資料的XML名字空間名
XMPP中用於TLS相關資料的 URN 子名字空間定義如下. (這個名字空間的名字遵守The IETF XML Registry [XML-REG]定義的格式.)
@IETF =＞internet enginner task force(負責網際網路標準研究及制定的組織)
URI: urn:ietf:params:xml:ns:xmpp-tls
________________________________________
15.2. 用於SASL資料的XML名字空間名
XMPP中用於SASL相關資料的 URN 子名字空間定義如下. (這個名字空間的名字遵守The IETF XML Registry [XML-REG]定義的格式.)
URI: urn:ietf:params:xml:ns:xmpp-sasl
＜stream:features＞
＜starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'＞
＜required/＞
＜/starttls＞
＜mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'＞
＜mechanism＞DIGEST-MD5＜/mechanism＞
＜mechanism＞PLAIN＜/mechanism＞
＜/mechanisms＞
＜/stream:features＞
________________________________________
15.3. 用於流錯誤的XML名字空間名
XMPP中用於流相關錯誤的 URN 子名字空間定義如下. (這個名字空間的名字遵守The IETF XML Registry [XML-REG]定義的格式.)
URI: urn:ietf:params:xml:ns:xmpp-streams
＜stream:error＞
＜xml-not-well-formed xmlns='urn:ietf:params:xml:ns:xmpp-streams'/＞
＜/stream:error＞
________________________________________
15.4. 用於資源綁定的XML名字空間名
XMPP中用於資源綁定的 URN 子名字空間定義如下. (這個名字空間的名字遵守The IETF XML Registry [XML-REG]定義的格式.)
URI: urn:ietf:params:xml:ns:xmpp-bind
＜stream:features＞
＜bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/＞
＜/stream:features＞
________________________________________
15.5. 用於節錯誤的XML名字空間名
XMPP中用於節相關錯誤資料的 URN 子名字空間定義如下. (這個名字空間的名字遵守The IETF XML Registry [XML-REG]定義的格式.)
URI: urn:ietf:params:xml:ns:xmpp-stanzas
＜stanza-kind to='sender' type='error'＞
＜error type='error-type'＞
＜defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/＞
＜text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas' xml:lang='langcode'＞OPTIONAL descriptive text＜/text＞
＜/error＞
＜/stanza-kind＞
________________________________________
15.6. Nodeprep Profile of Stringprep
The Nodeprep profile of stringprep是在Nodeprep(附錄 A)定義的. IANA已經在stringprep profile registry中註冊了 Nodeprep.
________________________________________
15.7. Resourceprep Profile of Stringprep
The Resourceprep profile of stringprep是在Resourceprep(附錄 B)定義的. IANA已經在stringprep profile registry中註冊了Resourceprep.
________________________________________
15.8. GSSAPI 服務名
IANA已經註冊了 "xmpp" 作為一個 GSSAPI [GSS-API] 服務名, 在SASL Definition (第六章第三節)定義
@GSSAPI =＞ Generic Security Services Application Programming Interface
通用安全服務應用程式程介面，它提供了一個通用的認證和安全訊息傳遞介面
http://www.faqs.org/rfcs/rfc2743.html
________________________________________
15.9. 埠號
IANA已經註冊了"xmpp-client" 和 "xmpp-server" 作為[TCP]埠號5222和5269的關鍵字.
這些埠應該（SHOULD）用於用戶端-伺服器 和 伺服器-伺服器通信,但它們的使用是可選的（OPTIONAL）.
________________________________________
參考資料:
Punycode =＞ http://www.ietf.org/rfc/rfc3492.txt
http://xn--fx5a34a.xn--fiqp7jnrek3iomgb4cbweev5d.tw/IDN.pdf
http://hi.baidu.com/jabber/blog/category/Jep
http://wiki.jabbercn.org/space/start
留言