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'/>
</iq>
<message type='error' id='another-id'>
<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...
<special-application-condition xmlns='application-ns'/>
</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]中查。實作不準試圖使用其它編碼。
![sqli-labs第一關--報錯注入練習[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)