此文檔定義了可擴展消息出席協議（XMPP）的核心特性：協議使用XML元素在任意兩個網絡端點間近實時的交換結構化信息。當XMPP爲交換XML數據提供通常化，可擴展的框架時，它主要用於創建知足RFC2779的即時消息與出席應用的需求。
1 介紹
1.1 概要
XMPP是一個開放的可擴展標記語言[XML]協議，用於近實時的消息、出席與請求-響應服務。基本語法語義最初是由Jabber開源社區在1999年開發的。2002年，XMPP工做組受權開發一個Jabber協議的改寫本，將適用於IETF的即時消息（IM）與出席技術。
做爲XMPP工做組的成果，此文檔定義了XMPP 1.0的核心內容；提供即時消息與出席功能的擴展需求定義在RFC2779[IM-REQS]中，由XMPP：即時消息與出席[XMPP-IM]指定。
1.2 術語
文檔中的大寫關鍵字："MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"在BCP14, 在RFC 2119 [TERMS]中描述。
2 通常架構
2.1 概述
雖然XMPP並未與任何特定網絡架構結合，但到目前爲止，它大體上已經由一個客戶-服務器的架構實現了。其中，客戶端利用XMPP訪問基於[TCP]鏈接的一個服務器，而且，服務器間也經過TCP鏈接進行彼此間的通訊。
XMPP
Client------------Server------------Server
TCP TCP
下圖爲此架構的高層視圖（「-」表示使用XMPP通訊，「=」表示使用任何其它協議通訊）
C1----S1---S2---C3
|
C2----+--G1===FN1===FC1
符號表示以下：
1） C1，C2，C3 = XMPP客戶端
2） S1，S2 = XMPP服務器
3） G1 = 網關：在XMPP與外部協議（非XMPP）的消息網絡間轉換。
4） FN1 = 外部消息網絡
5） C1 = 外部消息網絡的客戶端
2.2 服務器
服務器做爲XMPP通訊擔當智能抽象層。它的主要責任是：
1） 管理鏈接其它實體的會話，以XML流格式（第4節）在已受權的客戶端、服務器以及其它實體間來回傳送。
2） 經過XML流在實體間路由具備合適地址的XML節（第9節）。
大多數與XMPP兼容的服務器設想有能力存儲客戶端的數據（例：基於XMPP即時消息與出席應用的用戶的聯繫列表）；在這種狀況下，XML數據由服務器自身表明客戶端直接處理，並不路由到其它實體。
2.3 客戶端
大多數客戶端經過[TCP]鏈接直接連到服務器，而且使用XMPP，充分利用由服務器及任何相關服務所提供的功能。多種資源（例如：設備或位置）可能表明每一個被受權客戶端同時連到服務器上。每一個資源均由定義在地址方案（第3節）下的XMPP地址的資源標識符來區別（例如：<node@domain/home> vs. <node@domain/work>）。客戶端與服務器的推薦鏈接端口爲5222，已由IANA註冊（參考端口編號（15.9節））。
2.4 網關
網關是服務器端的一種特殊服務，它的主要功能是將XMPP翻譯成外部消息系統所使用的協議（非XMPP），也可將數據翻譯回XMPP。例如EMAIL網關（參考[SMTP]），Internet Relay Chat（參考[IRC]），SIMPLE（參考[SIIMPLE]，Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions），短消息服務（SMS），遺留即時消息服務，諸如AIM，ICQ，MSN Messenger，Yahoo! Instant Messenger。網關與服務器間的通訊，網關與外部消息系統間的通訊，均未在此文檔中定義。
2.5 網絡
因爲每一個服務器由網絡地址指定，而且因爲服務器與服務器間的通訊是客戶與服務器協議的直接擴展，實際上，系統由互相通訊的服務器網絡組成。舉個例子，<juliet@example.com>能與<romeo@example.net>交換消息、出席，以及其它信息。這是使用網絡尋址標準的消息協議（例如[SMTP]）所熟悉的模式。任意兩服務器間的通訊是可選的。若是可通訊，此類通訊就應當發生在綁定到[TCP]鏈接的 XML流上。服務器間鏈接的推薦端口爲5269，由IANA註冊（參考端口編號（15.9節））
3 尋址方案
3.1 概述
實體可被看做是使用XMPP進行通訊的任意網絡端點（例如：一個網絡上的ID）。任意此類實體均以與RFC2396[URI]一致的格式來惟一設定地址。因爲歷史緣由，XMPP實體的地址稱做Jabber標識符或JID。一個有效JID包含一套有序元素：域標識符，結點標識符，資源標識符。
JID的語法定義以下，使用增廣巴斯科範式[ABNF]（Augmented Backus-Naur Form）。（Ipv4地址與Ipv6地址規則定義在[Ipv6]的附錄B；符合結點規則的容許字符序列由Nodeprep profile of [STRINGPREP]定義，編入本文檔的附錄A；符合資源規則的容許字符序列由Resourceprep profile of [STRINGPREP]定義，編入本文檔的附錄B；子域規則參考國際化域標識的概念，在[IDNA]中有述）。
jid = [ node "@" ] domain [ "/" resource ]
domain = fqdn / address-literal
fqdn = (sub-domain 1*("." sub-domain))
sub-domain = (internationalized domain label)
address-literal = IPv4address / IPv6address
全部JID均基於前述規則。此結構最普通的用法就是用戶以<user@host/resource>形式標識一個即時消息用戶、用戶鏈接的服務器、用戶鏈接的資源（例如：特別的客戶端）。
然而，結點類型可能不只是客戶端，舉個例子，一個提供多用戶聊天服務的特別聊天室，能夠以<room@service>（「room」是聊天室名，「service」是多用戶聊天服務的主機名）做爲地址。而且，此聊天室的特別擁有者可能以<room@service/nick> （「nick」是此擁有者的房間暱稱）做地址，許多其它JID類型均有可能（例如：<domain/resource>多是一個服務器端腳本或服務）。
JID（結點標識符，域標識符，資源標識符）的每一個可容許部分長度不許超過1023字節，結果，最大總長度（包括‘@’，‘/’分隔符）爲3071字節。
3.2 域標識符
域標識符是基本標識符，且是JID中僅有的一個必須的元素（僅有域標識符的JID是有效的）。它一般表示網絡網關與「主要的」服務器，具備爲其它實體間的鏈接進行XML路由與數據管理的能力。然而，由域標識符做爲參考的實體並不老是服務器，它多是一項以服務器子域爲地址的服務，提供多於服務器（例：多用戶聊天服務，用戶目錄，或外部消息系統的一個網關）的功能。
每一個服務器或服務的域標識符將經過網絡進行通訊，它多是IP地址，並應當是徹底合法的域名（參考[DNS]）。域標識符必須是一個「國際化的域名」，定義在[IDNA]，Nameprep [NAMEPREP] profile of stringprep [STRINGPREP]能夠無錯應用。比較兩個域標識符以前，服務器必須（客戶端是應該）首先對標籤（定義在[IDNA]）應用Nameprep profile，以補足每一個標識符。
3.3 節點標識符
結點標識符是一個可選的輔助標識符，放在域標識符以前，後以‘@’字符分隔。它一般表示實體請求與使用由服務器或網關（例如：一個客戶端）提供的網絡訪問，雖然它也能表示其它種類的實體（例如：有多用戶聊天服務功能的聊天室）。由結點標識符表示的實體，在特定域上下文中，在XMPP即時消息與出席應用中被加以地址，此類地址稱做「bare JID」，形式爲<node@domain>
結點標識符必須像the Nodeprep profile of [STRINGPREP]這樣格式化，能夠無錯應用。比較兩個結點標識符以前，服務器必須（客戶端應該）首先對每一個標識符應用Nameprep profile。
3.4 資源標識符
資源標識符是一個可選的第三位標識符，位於域標識符以後，後跟‘/’做爲分隔符。資源標識符能夠修改<node@domain>也能夠只是<domain>地址。它一般表示一個特別的會話、鏈接（例如：一個設備或位置），或屬於帶有節點標識符的對象（例如：在多用戶聊天室的一個參與者）。當提供必要的信息來完成資源綁定（第7節）時，資源標識符對服務器與其它客戶端均不透明，而且由客戶端實現來定義，之後，它做爲一個「已鏈接資源」參考。實體可能同時維護多鏈接，每一個已鏈接的資源均由資源標識符來進行區別。
資源標識符必須按Resourceprep profile of [STRINGPREP]格式化，才能無錯應用。比較兩個資源標識符前，服務器必須（客戶端應該）首先爲每一個標識符應用Resourceprep profile。
3.5 決定地址
SASL協商後（第6節），若是正確，資源綁定（第7節），流接收實體必須決定初始實體的JID。
若是SASL協商（第6節）期間未指定受權身份，對服務器與服務器間的通訊，初始實體的JID應當被受權身份，派生於認證身份，在SASL（Simple Authentication and Security Layer簡單受權與安全層）說明[SASL]中定義。
若是SASL協商（第6節）期間未指定受權身份，對客戶端到服務器的通訊，「bare JID」（<node@domain>）應該被受權身份，被派生於受權認證，定義在[SASL]。在資源綁按期間（第7節）「full JID」（<node@domain/resource>）的資源標識符部分應當是客戶端與服務器間協商的資源標識符。
接收實體必須確保結果JID（包括結點標識符，域標識符，資源標識符，分隔符）聽從此節中前面所定義的規則與格式；爲知足此限制，接收實體可能須要替代由接收實體所決定的規範的JID初始實體所發送的JID。
本文同步分享在 博客「xiangzhihong8」（CSDN）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。node