由於接收端是作為其所服務域的守護者，它會對連線來的客戶端提出一些條件。至少，在接收端在接收請求端傳送來的xml節點前，需要對請求方進行身份驗證。然而，接收方也可能要考慮一些其他比身份驗證更有強制協商性的條件，如採用tls加密通訊。當然接收方會通知請求方，提出自己的條件，這個通知是採用「流特性」的方式進行的---這是請求方在接收方接收其發出的xml節點前，必須要完成的一組協議互動過程，當然有些協議互動過程是自願的，但有些可能會優化xml流的處理過程（如在應用層建立壓縮機制）。
有了這些連線條件，也就意味著協商的必要性。由於tcp, tls和sasl等都有先後順序，那也就表示協商也要分階段處理。有兩個因素決定了這個處理順序：（1）是否提供乙個流特性，要看實體是否需要，即可能只有某些實體才依賴這個特性；也可能依賴於某些其他特性的協商，就是說在某些其他特性協商後才能提供該流特性（如資源繫結只有在sasl驗證之後才能提供）；（2）流特性可以是強制協商的，也可以是自願協商的；最後，出於安全原因，流的各部分需要在完成對某些特性的互動的定義後，丟棄一些在協商過程中得到的能力（如規範中定義的sasl驗證機制，當通過sasl驗證完畢後，tls連線即被丟棄和而sasl在安全層建立時的sasl）。這一般要在當前tcp連線中，通過重新傳送初始化流來完成。
如果請求方發生的初始化流中包含version屬性，並且屬性值只是是1.0，那麼接收方在傳送完反饋的初始化流之後，必須傳送子節點，以通知請求方完成協商過程所需要的條件。條件是以的子節點的形式傳送的，每個子節點表示乙個條件。可以包含乙個子節點，多個子節點，也可以不包含任何節點，子節點的順序不做要求。
特性本身就是被要求為強制協商的（如xmpp客戶端的資源繫結）；或者
在一次互動過程中，為接收方指定一種方式來標記特性是強制協商的（如，starttls，它是通過在該流特性中新增乙個空的節點來實現的，但這不是所有特性都可以使用這樣的方式）；對於新的強制協商特性來說，還是推薦像starttls這樣，在特性節點中新增節點來實現。
由於沒有通用的格式或方式來標記特性是否為強制性的，接收方也無法做出正確的判斷，從而導致無法完成流協商。但是，儘管存在這樣的問題，但是xmpp協議工作組認為這樣的情況是很罕見的，因此沒有必要尋找通用的解決方案。
出於安全原因，某些流特性在完成流協商後，有必要要求請求方重新傳送初始化流（如tls,及 在安全層建立時的sasl特性）。如果乙個特性是這樣的，那麼它的定義就需要體現出「協商完後，需要重啟」的特徵。
如果節點中只是還包含乙個強制協商的特性，那麼就表示流協商並沒有完成，就需要請求方必須進一步對特性進行協商。如：
r:
如乙個節點既包含強制協商特性也包含自願協商特性，可以判斷協商沒有完成，但是請求方可能需要先完成自願協商的特性，然後在試著協商強制特性。如：
r: zlib
lzw
r: zlib
lzw
r:流重啟之後，接收方必須傳送乙個更新後的流特性列表，如果沒有特性需要進一步協商，或者可能只有特性的組合的話，更新後的特性列表可能就是空的。
接收方通過給請求方傳送空的節點，或只包含自願協商的特性的節點的方式，來決定協商的完成。之後，請求方可能傳送乙個空的節點，但一定不能傳送其他附加的特性（如果接收方有新的特性需要傳送的話，最好限制在強制協商或緊急的安全特性上，那麼可以通過傳送關閉流，並帶乙個的錯誤節點，然後在請求方重新連線時處理新特性。最好通過交叉的方式關閉現有的流，避免所有的初始實體都一起重連）。流協商完成後，請求方就可以傳送xml節（message, presence, iq等）了。
需要注意的是，由於歷史原因，資源繫結不適用於上述規則，因為它是客戶端使用xml節來實現強制協商的。
請求方在協商完成之前，一定不能嘗試向其他實體或連線的伺服器傳送xml節（message, presence, iq等）。即使請求方傳送了，接收方也一定不能接收，而一定要關閉流，並帶流錯誤。該規則只適用於xml節（即, 和等內容命名空間限定的節點），而不適用於流協商時使用的xml節點（如，用於完成tls和sasl協商的節點）。
Type C PD協商過程解析
type c pd協商過程解析 type c的pd power delivery 允許裝置通過type c埠協商功率，如 1.5v 3a 2.9v 3a 3.15v 3a 4.20v 5a 最大可到100w的輸出 pd協商 pd協商通過功率提供者 provider 和功率消費者 consumer 之...
SSL金鑰協商過程詳解
由於非對稱加密的速度比較慢，所以它一般用於金鑰交換，雙方通過公鑰演算法協商出乙份金鑰，然後通過對稱加密來通訊，當然，為了保證資料的完整性，在加密前要先經過hmac的處理。ssl預設只進行server端的認證，客戶端的認證是可選的。以下是其流程圖 摘自tls協議 client server clien...
IPsecVPN協商過程 主模式
ipsec協商共分為兩個階段，主模式第一階段共6個包，第二階段共3個包。1 4個包是明文傳輸，5 9個包是加密傳輸。第一階段 1.第1個包 1 加密演算法 des 3des aes.2 認證方法 pre share rsa 3 認證與完整性演算法 md5 sha 1 4 group組 1 2 5 7...