864
汽車大全
xmpp即時通訊四
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>
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流頭中都是需要的。流命名空間名必須是'https://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]中查。實現不準試圖使用其它編碼。
最後更新：2017-04-03 12:54:48