xmpp即時通訊詳解

摘要：

        此文件定義了可擴充套件訊息出席協議（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。