8．服務器回叫
8．1概述
Jabber協議來自於XMPP適用的，包含一個“服務器回叫”方法，用以保護免受域哄騙，因此，使哄騙XML節更困難。服務器回叫並不是一個安全機制，並且僅導致服務器身份弱驗證（參考服務器到服務器的通信（14.4）相關方法的安全特性）。域需要健壯的安全性，應當使用TLS與SASL；參考服務器到服務器通信（4.4）細節。如果SASL用於服務器到服務器的認證，回叫不應當使用，因爲它是不必要的。包含回叫文檔主要是出於與現存實現與部署向後兼容的原因。
服務器回叫方法因域名系統（DNS）存在而成爲可能，由於一個服務器能夠（正常的）對一個給定域發現授權服務器。因爲回叫依靠DNS，域內通信不準處理，直到由服務器宣稱的域名系統（DNS）的主機名被解析（參考服務器到服務器的通信（14.4））。
服務器回叫是單向的，導致一個方向上一個流身份的（弱）驗證。因爲服務器回叫不是一個認證機制，通過回叫是不可能進行雙向認證的。因此，服務器回叫必須在每個方向上完成，爲了使在兩個域間進行雙向通信成爲可能。
產生與驗證密鑰的方法用於服務器回叫，必須考慮被用的主機名，由接收服務器產生的流ID，和由授權服務器的網絡祕密知道。流ID在服務器回叫中是嚴格安全的，並且因此必須是即不可預測也不可重複的（參考[RANDOM]推薦資料相關用於安全觀點的隨機性。）
任何在回叫協商期間發生的錯誤必須考慮一個流錯誤，導致終止流與潛在的TCP連接。協議描述中說明的可能的錯誤條件如下。
以下術語應用：
1） 源服務器——試圖在兩個域間建立連接的服務器。
2） 接收服務器——嘗試認證源服務器是否按它聲明的那樣去表達。
3） 授權服務器——回答由源服務器宣稱的DNS主機名；對基本環境來說是源服務器，但在源服務器網絡中可以是一個分離的機器。
8．2事件順序
以下是回叫事件順序的簡單總結：
1） 源服務器建立到接收服務器的連接。
2） 源服務器通過連接，給接收服務器發送‘key’值。
3） 接收服務器建立到認證服務器的連接。
4） 接收服務器向授權服務器發送相同的‘key’值。
5） 授權服務器回答密鑰值是否有效。
6） 接收服務器通知源服務器授權是否通過。
我們可以將事件順序以下圖表示：
Originating Receiving
Server Server
----------- ---------
| |
| establish connection |
| ----------------------> |
| |
| send stream header |
| ----------------------> |
| |
| send stream header |
| <---------------------- |
| | Authoritative
| send dialback key | Server
| ----------------------> | -------------
| | |
| establish connection |
| ----------------------> |
| |
| send stream header |
| ----------------------> |
| |
| send stream header |
| <---------------------- |
| |
| send verify request |
| ----------------------> |
| |
| send verify response |
| <---------------------- |
|
| report dialback result |
| <---------------------- |
| |
8．3協議
服務器間具體協議交互如下：
1） 源服務器建立TCP連接到接收服務器。
2） 源服務器發送流頭給接收服務器：
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'>
注：‘to’與‘from’屬性在根流元素中是可選的。包含xmlns:db命名空間聲明，名字顯示向接收實體指示源服務器支持回叫。如果命名空間名不正確，那麼，接收服務器必須產生一個<invalid-namespace/>流錯誤條件並終止XML流與TCP連接。
3） 接收服務器應當發送一個流頭返回給源服務器，包含一個用於交互的唯一的ID：
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'
id='457F9224A0...'>
注：‘to’與‘from’屬性在根流元素中是可選的。如果命名空間名不正確，那麼源服務器必須產生一個<invalid-namespace/>流錯誤條件，並終止XML流與TCP連接。而且，接收服務器應當迴應，但可能根據適當的安全策略默默終止XML流與TCP連接。然而，如果接收服務器想要處理，它必須發送一個流頭返回給源服務器。
4） 源服務器發送一個回叫密鑰給接收服務器：
<db:result
to='Receiving Server'
from='Originating Server'>
98AF014EDC0...
</db:result>
注：此密鑰並不被接收服務器所檢查，因爲接收服務器並不保存相關源服務器間會話信息。由源服務器產生的密鑰必須部分基於接收服務器在先前步驟提供的ID值，並部分基於源服務器與授權服務器的保密共享。如果‘to’地址值並不與接收服務器所識別的主機名匹配，那麼，接收服務器必須產生一個<host-unknown/>流錯誤條件並終止XML流與潛在的TCP連接。如果‘from’地址值與帶有接收服務器已經建立的連接的域匹配，那麼，接收服務器可能選擇爲新連接產生一個<not-authorized/>流錯誤條件，然後終止XML流與潛在的與新請求相關的TCP連接。
5） 接收服務器建立一個TCP連接支持由源服務器宣稱的域，作爲它連接到授權服務器的結果。（注意：作爲優化，一個實現可能重用一個現存的連接。）
6） 接收服務器發送給授權服務器一個流頭：
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'>
注：在根流元素中，‘to’與‘from’屬性是可選的。如果命名空間名不正確，則授權服務器必須產生一個<invalid-namespace/>流錯誤條件並終止兩個XML流與潛在的TCP連接。
7） 授權服務器發送給接收服務器一個流頭：
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'
id='1251A342B...'>
注：如果命名空間名不正確，則接收服務器必須產生一個<invalid-namespace/>流錯誤條件並終止它與授權服務器間的兩個XML流與潛在的TCP連接。如果流錯誤發生在接收服務器與授權服務器間，則接收服務器必須產生一個<remote-connection-failed/>流錯誤條件並終止它與發起服務器間的兩個XML流與潛在的TCP連接。
8） 接收服務器發給授權服務器要求認證密鑰的請求：
<db:verify
from='Receiving Server'
to='Originating Server'
id='457F9224A0...'>
98AF014EDC0...
</db:verify>
注：經過這兒的是來自接收服務器的流頭的主機名、源標識符，到步驟3中的發起服務器，源服務器發送給接收服務器的密鑰在步驟4。根據這些信息，還有授權服務器網絡中的共享密鑰信息，密鑰被驗證。任何驗證方法可能用於產生密鑰。如果‘to’地址值與授權服務器識別的主機名不匹配，那麼，授權服務器必須產生一個<host-unknown/>流錯誤條件並終止兩個XML與潛在的TCP連接。如果‘from’地址值與源服務器打開TCP連接時（或任意相關有效域，例如接收服務器的主機名或其它有效域一個有效子域）所表示的主機名不匹配，則授權服務器必須產生一個<invalid-from/>流錯誤條件並終止兩個XML流與潛在的TCP連接。
9） 授權服務器驗證密鑰是否有效
<db:verify
from='Originating Server'
to='Receiving Server'
type='valid'
id='457F9224A0...'/>
或
<db:verify
from='Originating Server'
to='Receiving Server'
type='invalid'
id='457F9224A0...'/>
注：如果ID與步驟3中的接收服務器不匹配，那麼接收服務器必須產生一個<invalid-id/>流錯誤條件並終止兩個XML流與潛在的TCP連接。如果‘to’地址值與接收服務器所識別的主機名不匹配，則接收服務器必須產生一個<host-unknown/>流錯誤條件並終止兩個XML流與潛在的TXP連接。如果‘from’地址值與源服務器打開TCP連接時（或任意相關有效域，例如接收服務器的主機名或其它有效域一個有效子域）所表示的主機名不匹配，則接收服務器必須產生一個<invalid-from/>流錯誤條件並終止兩個XML流與潛在的TCP連接。返回認證信息給接收服務器之後，授權服務器應當終止他們之間的流。
10） 接收服務器通知源服務器結果：
<db:result
from='Receiving Server'
to='Originating Server'
type='valid'/>
注：在這裏，連接可通過一個type='valid'或報告爲無效來被認證。如果連接無效，則接收服務器必須終止兩個XML流與潛在的TCP連接。如果連接被認證，數據可被源服務器發送並被接收服務器讀取；在此這前，所有發送給接收服務器的XML節應該默默被扔掉。
前述結果是接收服務器已經認證了源服務器的身份，爲了節通過“初始流”（如，從源服務器到接收服務器的流）的XML能被源服務器發送與接收服務器能接收，爲了驗證使用“響應流”（如，從接收服務器到源服務器）實體的身份，回叫必須以相反方向完成。
成功回叫協調後，接收服務器應當接收來自通過現存已認證連接的源服務器的子序列<db:result/>包（例如，認證需求發送到子域或其它由接收服務器服務主機名）；這使在一個方向上的原來的已認證連接的"piggybacking"成爲可能。
即使回叫協調成功，服務器必須認證從其它服務器接收的XML節，包括‘from’屬性與‘to’屬性；如果一個節並不滿足此限制，接收節的服務器必須產生一個<improper-addressing/>流錯誤條件並終止兩個XML流與潛在的TCP連接。進一步講，服務器必須認證從其它服務器，包括流的一個已驗證域的‘from’屬性；如果節並不滿足此限制，收到節的服務器必須產生一個<invalid-from/>流錯誤條件並終止兩個XML流與潛在的TCP連接。這兩個檢查有助於阻止關聯到特別節的哄騙。
9．XML節
TLS協商（5節）後，如果需要SASL協商（6節）與資源綁定（7節），XML節可通過流來發送。定義了三種XML節用於'jabber:client'與'jabber:server'命名空間：<message/>, <presence/>, and <iq/>。另外，這種節有五個通用屬性。這些通用屬性，像三種節的基本語義一樣，都定義在此；與即時消息與表示應用相關的XML節的更詳細信息在[XMPP-IM]中提供。
9．1通用屬性
以下五個屬性對message, presence與IQ均通用：
9．1．1 to
‘to’屬性指定接收節的JID。
在‘jabber:client’命名空間中，節應當處理‘to’屬性，雖然，由服務器處理的從客戶端到服務器端的節不應該擁有‘to’屬性。
在'jabber:server'命名空間中，節必須擁有‘to’屬性；如果服務器收到一個不滿足此限制的節，它必須產生一個<improper-addressing/>流錯誤條件並終止兩個XML流與錯誤服務器的潛在連接。
如果‘to’屬性無效或不能連接，發現此事實的（通常是發送的或接收的服務器）實體必須返回一個合適的錯誤給發送者，設置錯誤節的‘from’屬性爲錯誤服務器提供的‘to’屬性值。
9．1．2 from
‘from’屬性指明發送者的IID。
當服務器收到一個在由'jabber:client'命名空間認證的已授權流的上下文中的XML節，它必須做以下事件之一：
1） 驗證客戶端提供的‘from’屬性值就是用於聯合實體的已連接資源的值。
2） 加一個‘from’地址值給節，此節的值是裸JID（<node@domain>）或全JID（<node@domain/resource>），這些JID由服務器決定用於產生節的已聯接資源（看地址決定（3.5節））。
如果一個客戶端試圖發送‘from’屬性並不匹配實體的已聯接資源的XML節，服務器應該返回一個<invalid-from/>流錯誤給客戶端。如果一個客戶端試圖通過一個流來發送一個還未授權的XML節，服務器應當返回一個<not-authorized/>流錯誤給客戶端。如果產生了，這些條件都必須關閉流並終止潛在的TCP連接；這有助於阻止來自於欺詐客戶端的否認服務攻擊。
當一個服務器產生一個來自於服務器本身的節，用於傳送到一個已連接的客戶端（例如：在由服務器代表客戶端提供的數據存儲服務的上下文中），節必須既（1）不包括‘from’屬性或（2）包括‘from’屬性，其值是帳戶的裸JID（<node@domain>）或客戶的全JID（<node@domain/resource>）。服務器不準發送給客戶端一個不包括‘from’屬性的節，它必須設想節是從服務器到已連接客戶端。
在'jabber:server'命名空間中，一個節必須處理一個‘from’屬性；如果服務器收到不滿足此限制的節，它必須產生一個<improper-addressing/>流錯誤條件。更進一步，包含在‘from’屬性中的JID的域標識符部分必須匹配發送服務器（或任何已認證相關域，如發送服務器的主機名或其它由發送服務器已認證域）的主機名，當在SASL協商或回叫協商通信中；如果一個服務器收到一個不滿足此約束的節，它必須產生一個<invalid-from/>流錯誤條件。這些條件都必須關閉流並終止潛在的TCP連接；這有助於阻止欺詐服務器的否認服務攻擊。
9．1．3 id
可選‘id’屬性可能由發送實體因內部跟蹤收發（特別是跟蹤固有在IQ節語義中的請求-響應交互）節而使用。對值‘id’屬性來說，它是可選的唯一全局的，在域內的或流中的。IQ節語義強加了其它約束；看IQ語義（9.2.3）。
9．1．4 type
類型域屬性指定目的或消息上下文，出席或IQ節的詳細信息。‘type’屬性的特別允許值依賴節是否是一個消息，出席，或IQ；消息與出席節的值是特別用於即時消息與出席應用的，並因此定義義在[XMPP-IM]，然而IQ節的值特指IQ節在一個結構化的請求-響應“會話”中的角色，並因此定義在以下IQ語義（9.2.3節）。對三種節僅有的一個通用‘type’值是“error”；看節錯誤（9.3節）。
9．1．5 xml:lang
此節應當處理一個‘xml:lang’屬性（定義在[XML]2.2節），如果節包含傾向於表示到一個人類用戶（RFC2277[CHARSET]中有解釋，“對人的國際化”）的XML字符數據。‘xml:lang’屬性值指定任意人類可讀XML字符數據的缺省語言，可能被特定的子元素的‘xml:lang’屬性覆蓋。如果節沒有‘xml:lang’屬性，實現必須設想爲流指定的缺省語言已在以下流屬性（4。4節）中定義。‘xml:lang’屬性的值必須是一個NMTOKEN並必須遵從定義在3066[LANGTAGS]中的格式。
9．2基本語義
9．2．1消息語義
<message/>節種類可被看作“推”機制，一個實體推信息給其它實體，與EMAIL系統中發生的通信類似。所有消息節應該擁有‘to’屬性，指定有意的消息接收者；根據接收到那樣的一個節，服務器應該路由或傳送它到有意的接收者（參考服務器處理用於相關XML節的通用路由與傳送規則XML節的規則（10節））。
9．2．2 出席語義
<presence/>元素可被看作基本廣播或“出版-訂閱”機制，多實體收到他們已訂閱（在這種情況下，網絡可利用信息）實體的信息。總的來說，出版實體應該發送一個不帶‘to’屬性的出席節，在這種情況下，與此實體相連的服務器應該廣播或複用節給所有訂閱實體。然而，一個出版實體也可能發送一個帶有‘to’屬性的出席節，此種情況下，服務器應該路由或傳送節到有意的接收者。參考處理XML節（10節）的服務器規則，用於通用路由與相關XML節的傳送規則，並且用於即時消息與出席應用的出席-特定規則[XMPP-IM]。
9．2．3 IQ語義
信息/請求，或IQ，是一個請求-響應機制，與[HTTP]在某些方面相似。IQ語義讓一個實體向其它實體請求或接收其它實體的響應成爲可能。請求與響應的數據內容由IQ無素的直接子元素的命名空間聲明定義，並且，交互由請求實體通過使用‘id’屬性來跟蹤。因此，IQ交互遵從結構化數據交換的一個通用模式，此交換例如得到/結果或設置/結果（雖然如果合適的話，對一個請求的響應可能會以錯誤返回）：
Requesting Responding
Entity Entity
---------- ----------
| |
| <iq type='get' id='1'> |
| ------------------------> |
| |
| <iq type='result' id='1'> |
| <------------------------ |
| |
| <iq type='set' id='2'> |
| ------------------------> |
| |
| <iq type='error' id='2'> |
| <------------------------ |
| |
爲了加強這些語義，以下規則應用：
1） 對IQ節來說，‘id’屬性是REQUIRED。
2） 對IQ節來說。‘type’屬性是需要的。值必須是以下之一：
*get——節是一個用於信息或需求的請求。
*set——節提供所需數據，設置新值，或替換現存值。
*result——節是成功得到或設置請求的響應。
*error——先前發送得到或設置的相關過程或傳送的錯誤（參考節錯誤（9.3節））。
3） 收到類型爲“get”或“set”的IQ請求的實體必須以類型爲“result”或“error”的IQ響應來響應（響應必須保留請求的‘id’屬性）。
4） 收到類型爲“result”或“error”的節不準靠發送一個進一步的類型爲“result”或“error”的IQ響應節來響應；然而，如以上顯示，請求實體可能發送另一個請求（如：一個類型爲“set”的IQ，爲了提供通過得到/結果對發現的所需的信息）。
5） 類型爲“get”或“set”的IQ節必須包含一個並僅有一個子元素，指定特別的請求或響應語義。
6） 一個類型爲“result”的IQ節必須包含0或一個子元素。
7） 類型爲“error”類型的IQ節應當包含在相關“get”或“set”子元素中，並且，必須包含一個<error/>子元素；詳細信息，參考節錯誤（9.3節）。
9．3 節錯誤
節相關錯誤以類似流錯誤（4.7節）的方式處理。然而，不像流錯誤，節錯誤不可是不可恢復的；因此，暗含相關源發送者行爲的錯誤節能按順序糾正錯誤。
9．3．1 規則
以下規則應用於節相關錯誤：
1） 檢測相關節錯誤條件的接收或處理實體必須返回給發送實體一個同種節（消息，出席或IQ），它的‘type’屬性被設置成值“error”（那樣的節在此被稱爲“錯誤節”）。
2） 產生錯誤節的實體應當包含被送的源XML，爲了發送者能夠檢測，並且，如果必要的話，在試圖重送前糾正XML。
3） 一個錯誤節必須包含一個<error/>子元素。
4） 一個<error/>子元素不準被包括，如果‘type’屬性有不止一個“錯誤”值（或無‘類型’屬性）。
5） 接收一個錯誤節的實體不準響應帶有進一步錯誤節的節；這有助於阻止循環。
9．3．2 語法
節相關錯誤語法如下：
<stanza-kind to='sender' type='error'>
[RECOMMENDED to include sender XML here]
<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>
[OPTIONAL application-specific condition element]
</error>
</stanza-kind>
節種類是消息、出席或iq之一。
<error/>元素的‘type’屬性值必須是以下之一：
*cancel——不重試（錯誤不可恢復）
*continue——進行（僅是一個警告條件）
*modify——改變數據發送後重試
*auth——提供信任後重試
*wait——等待之後重試（錯誤是臨時的）
<error/>元素：
必須包含一個子元素，此子元素與以下指定的已定義的節錯誤條件一致；此元素必須被'urn:ietf:params:xml:ns:xmpp-stanzas'命名空間所認證。
可能包含<text/>子元素，此子元素包含XML字符數據，用於描繪更細節的錯誤；此元素必須被'urn:ietf:params:xml:ns:xmpp-stanzas'命名空間所認證，並且應該擁有一個'xml:lang'屬性。
可能包含一個子元素，用於特殊-應用錯誤條件；此元素必須由一個已定義-應用命名空間認證，並且，它的結構由此命名空間定義。
<text/>元素是可選的。如果包括在內，它應當僅用於提供描述性或診斷性信息，這些信息用於補充已定義條件或特殊-應用條件的意思。它不應當由應用程序性的描述。它不應當用作向用戶表達的錯誤信息，但可能顯示除與包含條件元素（或元素們）相關的錯誤消息。
最後，爲維護向後兼容性，此方案（在[XMPP-IM]中指定的）允許可選的在<error/>元素中包含‘code’屬性。
9．3．3 已定義條件
以下條件被定義用於節錯誤。
<bad-request/>——發送者已發送畸形的或不能被處理的（例如，一個包含未識別‘type’屬性值的IQ節）XML；相關錯誤類型應當是“modify”。
<conflict/>——訪問不被授權，因爲一個現存資源或會話以同樣名字或地址存在；相關錯誤類型應當是“cancel”。
<feature-not-implemented/>——被請求特徵未被接收者或服務器實現，並且因此不能被處理；相關錯誤類型應當是“cancel”。
<forbidden/>——請求實體不擁有執行行爲的所需許可；相關錯誤類型應當是“auth”。
<gone/>——接收者或服務器不在以此地址聯繫（錯誤節可能包含一個新地址在<gone/>元素的XML字符數據中）；相關錯誤類型應當是“modify”。
<internal-server-error/>——服務器不能處理節，因爲錯誤配置或一個另外-未定義內部服務器錯誤；相關錯誤類型應當是“wait”。
<item-not-found/>——JID地址或被請求項不能被發現；相關錯誤類型應當是“cancel”。
<jid-malformed/>——已提供的發送實體或與一個XMLL地址（例：‘to’屬性值）通信或其它方面（例：資源標識符）與地址方案（3節）中定義的語法不符；相關錯誤類型應當是“modify”。
<not-acceptable/>——接收者或服務器理解請求，但拒絕處理它，因爲它不滿足由接收者或服務器（例：消息中相關可接受字的本地策略）所定義的標準；相關錯誤類型應當是“modify”。
<not-allowed/>——接收者或服務器不允許任何實體執行動作；相關錯誤類型應當是“cancel”。
<not-authorized/>——發送者必須在被允許執行動作前提供合適的信任，或已經提供不合適的信任；相關錯誤類型應當是“auth”。
<payment-required/>——請求實體未授權去訪問被需求服務，因爲需要付費；相關錯誤類型應當是“auth”。
<recipient-unavailable/>——有意的接收者臨時不可用；相關錯誤類型應當是“wait”（注：一個應用不準返回此錯誤，如果這樣做將提供關於意向接收 者對未授權知道此類信息的實體的網絡可利用性信息）。
<redirect/>——接收者或服務器爲此信息重定向請求到其他實體，通常是臨時的（錯誤節應當包含可替換地址，必須是一個有效的JID，在<redirect/>元素的XML字符數據中）；相關錯誤類型應當是“modify”。
<registration-required/>——請求實體未被授權訪問所請求服務，因爲需要註冊；相關錯誤類型應當是“auth”。
<remote-server-not-found/>——一個指定作爲意向接收者的部分或全部的JID的遠程服務器或服務不存在；相關錯誤類型應當是“cancel”。
<remote-server-timeout/>——一個指定作爲意向接收者（或被請求去執行一個請求）的部分或全部的JID的遠程服務器或服務不能在一個合理的時間內被聯繫到；相關錯誤類型應當是“wait”。
<resource-constraint/>——服務器或接收者缺少必要的系統資源去服務請求；相關錯誤類型應當是“wait”。
<service-unavailable/>——服務器或接收者當前並不提供所請求的服務；相關錯誤類型應當是“cancel”。
<subscription-required/>——請求實體不被授權訪問被請求服務，因爲需要訂閱；相關錯誤類型應當是“auth”。
<undefined-condition/>——錯誤條件並不是此列表中由其它條件定義的那些之一；任何錯誤類型可能與此條件相關，並且，它應當僅用於與一個特殊-應用條件相連。
<unexpected-request/>——接收者或服務器理解請求，但此時（例：請求無序/請求不在狀態）並不期望它；相關錯誤類型應當是“wait”。
9．3．4 特殊-應用條件
像所知道的，一個應用可能靠包含一個錯誤元素中的合適的-命名空間的子元素來提供特殊-應用節錯誤信息。特殊-應用元素應當補充或進一步認證一個已定義元素。因此，<error/>元素將包含兩個或三個子元素：
<iq type='error' id='some-id'>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<too-many-parameters xmlns='application-ns'/>
</error>
</iq>
<message type='error' id='another-id'>
<error type='modify'>
<undefined-condition
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xml:lang='en'
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
Some special application diagnostic information...
</text>
<special-application-condition xmlns='application-ns'/>
</error>
</message>
