XMPP 3920 最靠譜的中文翻譯文檔(六)

XMPP 3920 最靠譜的中文翻譯文檔(六)
2009-10-17 19:58
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]中查。實現不準試圖使用其它編碼。

http://hi.baidu.com/xboxsky/blog/item/7a461e17732be70b4b90a70b.html

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章