rfc3920
可擴充套件的訊息和出席資訊協議 (xmpp): 核心協議
關於本文的說明
本文為網際網路社群定義了乙個網際網路標準跟蹤協議，並且申請討論協議和提出了改進的建議。請參照「網際網路官方協議標準」的最新版本（std 1）獲得這個協議的標準化程序和狀態。本文可以不受限制的分發。
版權宣告
本文版權屬於網際網路社群 (c) the internet society (2004).
摘要 本文定義了可擴充套件訊息和出席資訊協議（xmpp）的核心功能，這個協議採用xml流實現在任意兩個網路終端接近實時的交換結構化資訊。xmpp提供乙個通用的可擴充套件的框架來交換xml資料，它主要用來建立即時訊息和出席資訊應用以實現 rfc 2779 的需求。
目錄 1. 緒論
2. 通用的架構
3. 位址空間
4. xml流
5. tls的使用
6. sasl的使用
7. 資源繫結
8. 伺服器回撥
9. xml節
10. 伺服器處理xml節的規則
11. xmpp中的xml用法
12. 核心的相容性要求
13. 國際化事項
14. 安全性事項
15. iana事項
16. 參考
1. 緒論
1.1. 概覽
xmpp是乙個開放式的xml協議，設計用於準實時訊息和出席資訊以及請求-響應服務。其基本的語法和語義最初主要是由jabber開放源**社群於2023年開發的。2023年，xmpp工作組被授權接手開發和改編jabber協議以適應ietf的訊息和出席資訊科技。
作為xmpp工作組的成果，本文定義了 xmpp 1.0 的核心功能；在 rfc 2779 [imp-reqs] 中指定的提供即時訊息和出席資訊功能的擴充套件，定義在 xmpp-im 協議 [the extensible messaging and presence protocol (xmpp): instant messaging and presence] 中。
1.2. 術語
本文中大寫的關鍵字 "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may", 和 "optional" 的確切含義符合 bcp 14, rfc 2119 [terms].
2. 通用的架構
2.1. 概覽
儘管xmpp沒有結合任何特定的網路結構，通常認為它是客戶-伺服器架構的一種實現，在這裡客戶端用xmpp的方式訪問伺服器採用的是tcp連線，伺服器之間的通訊也是tcp連線。
以下是這一架構的抽象的示意圖 (這裡 "-" 表示使用 xmpp 通訊， "=" 表示可使用任何協議通訊)。
c1----s1---s2---c3
|c2----+---g1===fn1===fc1
符號代表的意思如下:
c1, c2, c3 = xmpp 客戶端
s1, s2 = xmpp 伺服器
g1 = 乙個xmpp和外部（非xmpp）訊息網路之間進行「翻譯」的閘道器
fn1 = 乙個外部訊息網路
fc1 = 外部訊息網路上的乙個客戶端
2.2. 伺服器
伺服器充當xmpp通訊的乙個智慧型抽象層，它主要負責：
管理發出的連線或其他實體的會話，在xml流（第四章）的表單中接收和傳送給授權的客戶端，伺服器和其他實體。
用xml流通過實體**特定位址的xml訊息（第九章）
大部分 xmpp 相容的伺服器也負責儲存客戶端使用的資料 (比如基於xmpp應用的聯絡人名單); 在這種情況下， xml 資料直接由伺服器代替客戶端處理而不需要**到其他實體。
2.3. 客戶端
大部分客戶端通過 tcp 連線直接連到伺服器，並通過xmpp獲得由伺服器和任何相關的服務所提供的全部功能。多個不同資源（比如不同的裝置和地點）的客戶端可以同時登陸並且併發的連線到乙個伺服器，每個不同資源的客戶端通過xmpp位址的資源識別符號來區分（比如 和 ），參見位址空間（第三章）。__建議__的客戶端和伺服器連線的埠是 5222 ，這個埠已經在 iana（在第十五章第九節查閱埠號碼） 註冊了。.
2.4. 閘道器
閘道器是乙個特殊用途的伺服器端的服務，主要功能是把 xmpp 翻譯成外部(非xmpp)訊息系統，並把返回的訊息翻譯成 xmpp 。例如到 email（參見 [smtp] ），irc（參見 [irc] ），******（參見 [******] ），sms 的閘道器；還有和別的訊息服務的閘道器，比如aim，icq，msn messenger，yahoo! instant messenger。
閘道器和伺服器之間的通訊，閘道器和外部訊息系統的通訊，不在本文描述範圍之內。
2.5. 網路
因為每個伺服器都是由乙個網路位址來標識的並且伺服器之間的通訊是客戶-伺服器協議的直接擴充套件，實際上整個系統是由很多互通的伺服器構成的。例如， < 可以和 < 交換訊息,出席資訊和其他資訊。這種模式常見於那些需要使網路位址標準化的協議（比如 smtp ）。
任意兩個伺服器之間的通訊是可選（optional）的。如果被啟用，那麼這種通訊應該（should）通過 xml 流繫結到 tcp 連線上進行。建議的（recommended）伺服器之間的連線埠為 5269 ，這個埠號已經在 iana （在第十五章第九節查閱埠號碼）註冊了。
3. 位址空間
3.1. 概覽
乙個實體可以是任何乙個被認為是乙個網路端點的東西(例如網路上的乙個 id )，而且它是通過xmpp進行通訊的。所有這些實體都有乙個具有唯一性的位址，並符合 rfc 2396 [uri]規範要求的格式。由於歷史原因，乙個 xmpp 實體的位址被稱為 jabber identifier 或 jid 。
乙個合法的 jid 包括一組排列好的元素，包括網域名稱（domain identifier），節點名（node identifier），和資源名（resource identifier）。
jid的語法定義，使用 [abnf] 中的 augmented backus-naur 格式。（ipv4 位址和 ipv6位址規則在附錄b 中的 [ipv6] 中定義；確定節點規則的合法字元順序由附錄a 的 [stringprep] 的 nodeprep 部分來定義；確定資源規則的合法字元順序由附錄b 的 [stringprep] 的resourceprep 部分來定義；子網域名稱規則參考 [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 都是基於上述的結構。類似 這種結構，最常用來標識乙個即時訊息使用者，這個使用者所連線的伺服器，以及這個使用者用於連線的資源（比如特定型別的客戶端軟體）。不過,節點型別不是客戶端也是有可能的，比如乙個用來提供多使用者聊天服務的特定的聊天室，位址可以是 （這裡 「room「 是聊天室的名字而 」service「 是多使用者聊天服務的主機名），而加入了這個聊天室的某個特定的使用者的位址則是 （這裡 」nick「 是使用者在聊天室的暱稱）。
許多其他的 jid 型別都是可能的（例如 可能是乙個伺服器端的指令碼或服務）。
乙個 jid 的每個合法部分（節點名，網域名稱，資源名）的長度不能（must not）超過 1023 位元組。也就是整體長度（包括 '@' 和 '/' ）不能超過 3071 位元組。
3.2. 網域名稱
網域名稱是乙個主要的id並且是 jid 中唯一必需（required）的元素（乙個純粹的網域名稱也是乙個合法的 jid）。它通常代表網路的閘道器或者「主」伺服器，其他實體通過連線它來實現 xml **和資料管理功能。然而，由乙個網域名稱標識引用的實體，並非總是乙個伺服器，它也可能是乙個伺服器的子域位址，提供額外的功能（比如多使用者聊天服務，使用者目錄，或乙個到外部訊息系統的閘道器）。
每個伺服器或者服務的網域名稱，可以（may）是乙個 ip 位址，但應該（should）是乙個完全合法的網域名稱(參見 [dns]).乙個網域名稱id必須(must)是 [iana] 裡定義的「國際化網域名稱」，並且按 [stringprep]中的 [nameprep] profile進行成功的字元轉換。在比較兩個網域名稱id之前，伺服器必須(must),客戶端應該(should)首先按照 nameprep profile(定義在[iana]中) 來轉換每個網域名稱的字元。
CAPWAP協議RFC5415培訓初稿
1 概述 2 1.1 標準 2 1.2 capwap協議系統框架 3 1.2.1 split mac 模式 3 1.2.2 local mac 模式 3 1.2.3 三種tunnel模式 4 1.3 capwap協議概述 4 1.3.1 capwap工作原理 5 1.3.2 ap發現ac的過程 6 ...
RFC2326中文版實時流協議RTSP
實時流協議 rtsp real time streaming protocol rtsp 備忘錄的狀態 本文件講述了一種inter 社群的inter 標準跟蹤協議，它需要進一步進行討論和建議以得到改進。請參考最新版的 inter 正式協議標準 std1 來獲得本協議的標準化程度和狀態。本備忘錄的發布...