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>
10． 處理XML節的服務器規則
兼容服務器實現必須確保有序處理任兩實體間的XML節。
超出有序處理的需求，每一個服務器實現將包含它本身的「傳送樹」用於處理它所接收的節。那樣的一個樹決定是否一個節須要被路由到其它域，內部處理，或傳送到與被連節點相關的資源。如下規則應用：
10．1 無‘to’地址
若是節擁有無‘to’屬性，服務器應當表明發送它的實體處理它。由於全部從其它服務器收到的節必須擁有一個‘to’屬性，此規則僅應用於從一個連到服務器的已註冊實體（如客戶端）收到的節。若是服務器收到一個無‘to’屬性的出席節，服務器應當廣播它到被訂閱到發送實體的出席實體，若是可利用的話（用於定義在[XMPP-IP]即時消息與表示應用的出席廣播的語義。）若是服務器接收一個類型爲「get」或「set」的沒有‘to’屬性的IQ節，而且它理解認證節內容的命名空間，它必須也能表明發送實體處理節或返回給發送實體（在「process」意思處被認證命名空間的語義決定）一個錯誤。
10．2 外部域
若是JID的域標識符部分的主機包含在‘to’屬性中並不匹配服務器自己的已配置主機名或子域中的已配置主機之一，服務器應當路由節到外部域（服從本地服務提供與相關內部域通訊的安全策略）。有兩種可能狀況：
一個服務器到服務器流已在兩域間存在：發送者的服務器爲現存流的外部域路由節到已受權服務器。
兩域間存在無主機到主機流：發送者的服務器（1）解析外部域（定義在如下服務器到服務器通訊（節14。4））的主機名，（2）在兩域間（定義在以下使用 TLS（節5）而且使用SASL（節6））協商服務器到服務器的流，並（3）爲經過新近-創建的流的外部域路由節到受權服務器。
若是路由到接收者的服務器不成功，發送者的服務器必須返回一個錯誤給發送者；若是接收者的服務器能被聯繫但被接收者的服務器傳送到接收者是不成功的，接收者的服務器必須經由發送者的服務器返回一個錯誤給發送者。
10．3 子域
若是包含在‘to’屬性中的JID域標識符部分的主機名匹配服務器自己已配置主機名之一的子域，服務器必須也處理節自己或路由節到一個特別的對那個子域（若是子域被配置）有責任的服務，或返回一個錯誤給發送者（若是子域不被配置）。
10．4 僅有域或特別資源
若是包含在‘to’屬性中的JID域標識符部分的主機名匹配服務器自己的一個已配置主機名，而且包含在‘to’屬性中的JID 是<domain>或<domain/resource>形式，服務器（或在內的一個已定義資源）必須合乎節種類處理節或返回錯誤節給發送者。
10．5 同域中的節點
若是包含在‘to’屬性中的JID域標識符部分的主機名匹配服務器自己的一個已配置主機名，而且包含在‘to’屬性中的JID 是<node@domain>或<node@domain/resource>形式，服務器應當傳送節到由包含在‘to’屬性中的JID表達的節的意向接收者。如下規則應用：
1） 若是JID包含一個資源標識符（例：是<node@domain/resource>形式）而且，這兒存在一個已鏈接資源匹配全JID，接收者的服務器應當傳送的節到確切匹配此資源標識符流或會話。
2） 若是JID包含一個資源標識符而且這兒存在匹配全JID的無鏈接資源，接收者的服務器應當返回一個<service-unavailable/>節錯誤給發送者。
3） 若是JID是<node@domain>形式，而且這兒存在爲此結點的至少一個已鏈接資源，接收者的服務器應當傳送節到鏈接資源的至少一個，根據應用-特殊規則（一套傳送規則，用於定義在[XMPP-IM]即時消息與出席應用）。
11． XMPP內的XML使用
11．1 約束
XMPP是流XML元素的一個簡單與特殊的協議，用來近實時的交換結構化信息。因爲XMPP不須要任意分析與完整XML文檔，這兒沒有XMPP須要支持[XML]全特徵的需求。特別的，如下約束應用。
關於XML產生，一個XMPP實現不許注入如下任意一個XML流：
*評論（定義在[XML]節2。5）
*處理說明（2。6節）
*內部或外部DTD子集（2。8節）
*除了預約義實體（4。6節）的內部或外部實體參考。
*包含映射到預約義實體（4。6節）保留字符的字符數據或屬性值；那樣的字符必須被避免
關於XML處理，若是一個XMPP實現接收到那樣的約束XML數據，它必須忽略此數據。
11．2 XML命名空間名與前綴
XML命名空間[XML-NAMES]被用在全部與XMPP-兼容的XML中，去建立數據擁有權的嚴格界限。命名空間的基本功能是分離結構的混合在一塊兒的 XML元素的不一樣詞彙。確保XMPP-兼容XML是命名空間-瞭解使任意容許的XML可以與XMPP中的任意數據元素結構化的混合。XML命名空間名與前綴的規則定義在如下子部分。
11．2．1 流命名空間
流命名空間聲明在全部XML流頭中都是須要的。流命名空間名必須是'http://etherx.jabber.org /streams'。<stream/>元素與它的<features/>與<error/>子元素的元素名必須被全部實例中的流命名空間認定合格。一個實現應當爲那些元素產生僅有的'stream:'前綴，而且由於歷史緣由可能接受僅有的'stream:'前綴。
11．2．2 缺省命名空間
缺省命名空間聲明是須要的，而且用在全部XML流中，爲了定義容許的根流元素的第一級子元素。此命名空間聲明必須與初始流與響應流相同，爲了兩個流一致的被認證合格。缺省命名空間聲明應用於流與全部在由其它命名空間認證合格的流（除非由另外一命名空間顯示認定合格，或由流命名空間或回叫命名空間前綴認證）中發送的節。
服務器實現必須支持如下兩個缺省命名空間（因爲歷史緣由，一些實現可能支持僅有的那些兩個缺省命名空間）：
*jabber:client——缺省命名空間，當流用於客戶端與服務器通訊時所聲明的。
*jabber:server——缺省命名空間，當流用於兩服務器間通訊時聲明的。
客戶端實現必須支持'jabber:client'缺省命名空間，而且因爲歷史緣由可能只支持缺省命名空間。
實現不許爲缺省命名空間中的元素產生命名空間前綴，若是缺省命名空間是'jabber:client'或'jabber:server'。一個實現不該當爲元素產生命名空間前綴，元素由'jabber:client'與'jabber:server'以外的內容（與流相反）命名空間認證的。
注：'jabber:client'與'jabber:server'命名空間是接近同一的，但用在不一樣的上下文中（客戶端到服務順通訊用 'jabber:client'與服務器到服務器通訊用'jabber:server'）。這兩個僅有的不一樣是‘to’與‘from’屬性在 'jabber:client'中發送的節中是可選的，然而在'jabber:server'中發送的節是必須的。若是一個兼容實現接受一個由 'jabber:client'或'jabber:server'命名空間認證合格的流，它必須支持全部三個核心節種類的（消息，出席，與IQ）通用屬性（9。1節）與基本語義（9。2節）。
11．2．3 回叫命名空間
回叫命名空間聲明對於全部用在服務器回叫（8節）中的元素都是須要的。回叫命名空間的名字必須是'jabber:server:dialback'。全部由這個命名空間認證合格的元素必須被加前綴。一個實現應當爲那種元素僅產生'db:'前綴並可能接受僅有的'db:'前綴。
11．3 確認（驗證）
除了'jabber:server'命名空間中節的相關‘to’與‘from’地址，服務器不爲轉發到客戶端或另外一個服務器的XML元素負責；一個實現可能選擇提供僅有的認證數據元素，但這是可選的（雖然一個實現不許接受XML，那也不是好格式）。客戶端不該當依賴此能力去發送數據，這些數據與方案並不符，而且應當忽略一個來的XML流中的非構造元素或屬性。XML流與節的驗證是可選的，包含在此的方案僅用於描述目的。
11．4 包含文本聲明
實現應當在發送流頭以前發送文本聲明。應用必須遵循文本聲明包含在內的相關環境的[XML]中的規則。
11．5 字符編碼
實現必須支持UTF-8 (RFC 3629 [UTF-8])統一字符集(ISO/IEC 10646-1 [UCS2])字符傳輸，RFC 2277 [CHARSET]中查。實現不許試圖使用其它編碼。node
本文同步分享在 博客「xiangzhihong8」（CSDN）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。安全