1
銆?/font>
Extensible Messaging and Presence Protocol (XMPP): Core
1.1. Status of this Memo/
璇存槑
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
鏈枃妗h緇嗚鏄庝簡搴旂敤浜?/font>
Internet
閫氳鐨勬爣鍑嗗崗璁傚浜庢湰鍗忚鐨勬洿鏂扮殑涓浜涢渶姹傝璁哄拰寤鴻錛岃鎻愪氦褰撳墠鐗堟湰鍒扳滃浗闄呮爣鍑嗗崗璁粍緇団濄傛湰鏂囨。鍒嗗彂涓嶅彈闄愬埗銆?/span>
1.2. Copyright Notice/
鐗堟潈鐢蟲槑
Copyright (C) The Internet Society (2004).
1.3. Abstract/
姒傝
This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779.
鏈枃瀹氫箟浜?/font>
XMPP
鍗忚鐨勬牳蹇冪壒鎬с?/font>
XMPP
鏄熀浜?/font>
XML
嫻佸厓绱犳墿灞曠殑錛屽畠鏃ㄥ湪鍚戜袱涓綉緇滅粓绔湪榪戜箮瀹炴椂鐨勬儏鍐典笅浜ゆ崲緇撴瀯淇℃伅銆?/font>
XMPP
涔熸彁渚涗簡涓涓病鏈夋樉钁楃壒鐐圭殑錛屽彲鎵╁睍鐨?/font>
XML
鏁版嵁浜ゆ崲鐨勬鏋剁粨鏋勬ā鍨嬨傚湪
RFC 2779
鏍囧噯瀹氫箟鐨勯渶姹備笅錛屽畠搴旂敤浜庡緩绔嬪嵆鏃墮氳鍜屽嵆鏃朵細璁殑搴旂敤紼嬪簭銆?/span>
1.4. Table of Contents/
鐩綍
1.聽聽聽聽聽聽
Introduction/
綆浠?/font>
2.聽聽聽聽聽聽
Generalized Architecture/
閫氱敤鐨勭粨鏋?/span>
3.聽聽聽聽聽聽
Addressing Scheme/
鍦板潃閰嶇疆
4.聽聽聽聽聽聽
XML Streams/ XML
嫻?/font>
5.聽聽聽聽聽聽
Use of TLS/ TSL
鐨勫簲鐢?/font>
6.聽聽聽聽聽聽
Use of SASL聽/ SASL
鐨勫簲鐢?/font>
7.聽聽聽聽聽聽
Resource Binding聽/
璧勬簮緇戝畾
聽
8.聽聽聽聽聽聽
Server Dialback聽/
鏈嶅姟鍥炲彨
9.聽聽聽聽聽聽
XML Stanzas聽/ XML
鑺?/font>
10.聽聽聽
Server Rules for Handling XML Stanzas聽/聽XML
鎿嶄綔鐨勬湇鍔¤鍒?/font>
聽
11.聽聽聽
XML Usage within XMPP聽/ XMPP
鐨?/font>
XML
鐢ㄦ硶
聽
12.聽聽聽
Core Compliance Requirements聽/聽聽
鏍稿績闇姹?/span>
13.聽聽聽
Internationalization Considerations聽/
鍥介檯鍖栬冭檻
聽
14.聽聽聽
Security Considerations聽/
瀹夊叏鑰冭檻
聽
15.聽聽聽
IANA Considerations / IANA
鑰冭檻
16.聽聽聽
References /
鍙傝冩枃鐚?/span>
17.聽聽聽
Nodeprep /
鑺傜偣鍛藉悕
路聽聽聽聽聽聽聽聽
B. Resourceprep /
璧勬簮鍛藉悕
路聽聽聽聽聽聽聽聽
C. XML Schemas / XML
璁″垝
路聽聽聽聽聽聽聽聽
D. Differences Between Core Jabber Protocols and XMPP / JABBER
鍜?/font>
XMPP
鏍稿績鍗忚鐨勫尯鍒?/span>
聽聽聽聽聽聽 路聽聽聽聽聽聽聽聽
Contributors/
璐$尞鑰?/span>
路聽聽聽聽聽聽聽聽
Acknowledgements/
鐭ヨ瘑鍑嗗
路聽聽聽聽聽聽聽聽
Author's Address/
浣滆呭湴鍧
路聽聽聽聽聽聽聽聽
Full Copyright Statement/
鐗堟潈鐢蟲槑聽聽聽聽聽聽聽聽聽聽聽聽聽 寰呯畫.........
1.4聽聽
1. Introduction/綆浠?/font>
1.4 1.1 Overview/緇艱堪
The Extensible Messaging and Presence Protocol (XMPP) is an open Extensible Markup Language [XML] protocol for near-real-time messaging, presence, and request-response services. The basic syntax and semantics were developed originally within the Jabber open-source community, mainly in 1999. In 2002, the XMPP WG was chartered with developing an adaptation of the Jabber protocol that would be suitable as an IETF instant messaging (IM) and presence technology. As a result of work by the XMPP WG, the current memo defines the core features of XMPP 1.0; the extensions required to provide the instant messaging and presence functionality defined in RFC 2779 [IMP-REQS] are specified in the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence [XMPP-IM].
xmpp鏄竴涓紑鏀劇殑鍩轟簬xml鐨?鎻愪緵 榪戜箮瀹炴椂娑堟伅銆佺幇鍦哄嫎瀵熷拰璇鋒眰搴旂瓟鏈嶅姟鐨勫崗璁傚畠鏈鍒濇槸鐢眏abber寮婧愮ぞ鍖哄湪澶х害 1999騫村彂璧峰茍涓鐩撮瀵肩殑鍗蟲椂娑堟伅鐨勫疄鏃剁郴緇燂紝鍦?002騫達紝xmpp WG 銆備綔涓簒mppWG鐨勫伐浣滅粨鏋滐紝褰撳墠澶囧繕褰曞畾涔変簡xmpp1.0鐨勬牳蹇冪壒寰?鍦?榪欎釜鎵╁睍閮ㄨ姹傛彁渚涘畾涔夊湪<<rfc 2779>>鐨勫嵆鏃舵秷鎭拰鐜板満鍕樺療鍔熻兘錛屾槸鍒楀湪xmpp 涓? [xmpp-im]銆?/font>
1.4聽 1.2 Terminology/鏈
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [TERMS].
涓嬮潰澶у啓鐨勫叧閿瓧 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "REC
OMMENDED", "MAY", and "OPTIONAL" 鍦ㄨ繖綃囨枃妗d腑鐨勬剰涔?璇峰弬瑙丷FC 2119
1.4 聽2. Generalized Architecture/閫氱敤鐨勭粨鏋?/font>
1.4 聽2.1 Overview/緇艱堪
聽Although XMPP is not wedded to any specific network architecture, to date it usually has been implemented via a client-server architecture wherein a client utilizing XMPP accesses a server over a [TCP] connection, and servers also communicate with each other over TCP connections.
The following diagram provides a high-level overview of this architecture (where "-" represents communications that use XMPP and "=" represents communications that use any other protocol).
C1---S1---S2--C3
C2---+---G1==============FN1==================FC1
The symbols are as follows:
路C1, C2, C3 = XMPP clients
路S1, S2 = XMPP servers
路G1 = A gateway that translates between XMPP and the protocol(s)
聽聽聽聽聽聽聽聽聽聽聽聽 used on a foreign (non-XMPP) messaging network
路FN1 = A foreign messaging network
路FC1 = A client on a foreign messaging network
灝界xmpp涓嶆兂涓庝換浣曠壒孌婄殑緗戠粶浣撶郴鏈烘瀯鐩哥粨鍚堬紝浣嗗畠閫氬父鏄熀浜巆/s鏋舵瀯鐨勶紝 鍏朵腑涓涓鎴風閫氳繃涓涓猼cp榪炴帴鎸夌潃 xmpp 璁塊棶涓涓湇鍔″櫒錛?鏈嶅姟鍣ㄥ悓鏍蜂篃鏄?閫氳繃tcp涓庡叾瀹冨疄浣撻氫俊銆?/p>
涓嬮潰鐨勫浘琛ㄦ彁渚涗簡榪欎釜浣撶郴鏈烘瀯鐨勯珮灞傝鍥?--浠h〃鐢▁mpp榪涜閫氫俊錛?浠h〃鏄?鍏跺畠鍗忚榪涜閫氫俊 )銆?
C1---S1---S2--C3
C2---+---G1==============FN1==================FC1
路C1,C2,C3 浠h〃 XMPP瀹㈡埛绔?/p>
路S1,S2浠h〃XMPP鏈嶅姟鍣?/p>
路G1浠h〃涓涓綉鍏籌紝瀹僗MPP鍜?鍏跺畠澶栭儴(闈瀤mpp)娑堟伅緗戠粶涔嬮棿鐨勭炕璇戙?/p>
路FN1 浠h〃涓涓閮ㄦ秷鎭綉緇?/p>
路FC1 浠h〃涓涓閮ㄦ秷鎭綉緇滅殑瀹㈡埛绔偮犅犅犅犅犅犅犅犅犅犅犅犅犅犅犅犅犅犅犅犅犅犅犅犅犅犅犅犅犅犅犅?寰呯畫.........
聽
1.4聽 2.2. Server/鏈嶅姟鍣?/h3>
A server acts as an intelligent abstraction layer for XMPP communications. Its primary responsibilities are:
路to manage connections from or sessions for other entities, in the form of XML streams (Section 4) to and from authorized clients, servers, and other entities
路to route appropriately-addressed XML stanzas (Section 9) among such entities over XML streams
Most XMPP-compliant servers also assume responsibility for the storage of data that is used by clients (e.g., contact lists for users of XMPP-based instant messaging and presence applications); in this case, the XML data is processed directly by the server itself on behalf of the client and is not routed to another entity.
涓涓湇鍔℃媴褰撲竴涓猉MPP閫氫俊鐨勬櫤鑳芥彁鍙栧眰錛岃繖涓昏璐熻矗錛?/p>
路綆$悊涓涓潵鑷叾瀹冮氫俊瀹炰綋鐨勪互xml嫻佹柟寮忕殑榪炴帴鎴栦細璇濓紝 瀹冨彲浠ユ潵鑷簬鎺堟潈鐨勫鎴風銆佹湇鍔″櫒銆佹垨鑰呭叾瀹冮氫俊瀹炰綋
路璺敱鍦ㄥ熀浜巟ml嫻佸疄浣撲腑鍏鋒湁姝g‘鍦板潃鐨剎ml鑺? 絎節鑺?
澶у鏁扮殑鏀寔xmpp鐨勬湇鍔″櫒涔熷彲鑳戒負鐢ㄦ埛鎷呬換鏁版嵁瀛樺偍鐨勮亴璐? 濡傜敤鎴風殑鑱旂郴鍒楄〃);鏃㈢劧榪欐牱錛屾湇鍔″櫒浠h〃鐢ㄦ埛鐩存帴澶勭悊xml鏁版嵁錛岃屼笉琚礬鐢卞埌鍙︿竴涓疄浣撱?/p>
1.4聽 2.3 Client/瀹㈡埛绔?/h3>
Most clients connect directly to a server over a [TCP] connection and use XMPP to take full advantage of the functionality provided by a server and any associated services. Multiple resources (e.g., devices or locations) MAY connect simultaneously to a server on behalf of each authorized client, with each resource differentiated by the resource identifier of an XMPP address (e.g., <node@domain/ home> vs. <node@domain/work>) as defined under Addressing Scheme (Section 3). The RECOMMENDED port for connections between a client and a server is 5222, as registered with the IANA (see Port Numbers (Section 15.9)).
澶у鏁扮殑瀹㈡埛绔洿鎺ラ氳繃tcp涓庢湇鍔″櫒榪炴帴錛岀敤XMPP鍗忚鍏呭垎鍒╃敤涓涓湇鍔″拰浠諱綍鐩稿叧鐨勬湇鍔℃彁渚涚殑鍔熻兘銆傚涓殑璧勬簮(濡傝澶囨垨鍦板尯)鍙兘鍚屾椂榪炴帴鍒頒竴涓湇鍔″櫒錛屽悇鑷唬琛ㄧ殑涓涓巿鏉冪殑瀹㈡埛錛屽畠浠氳繃XMPP鍦板潃(濡?<node@domain/home> 鍜?<node@domain/work>)鐨?strong>resource鏍囪瘑絎︽潵鍖哄埆銆傛帹鑽愮殑榪炴帴绔彛涓?font color="#ff0000">5222, 瀹冨凡鍚慖ANA娉ㄥ唽銆?/font>
1.4 聽2.4 Gateway/緗戝叧
A gateway is a special-purpose server-side service whose primary function is to translate XMPP into the protocol used by a foreign (non-XMPP) messaging system, as well as to translate the return data back into XMPP. Examples are gateways to email (see [SMTP]), Internet Relay Chat (see [IRC]), SIMPLE (see [SIMPLE]), Short Message Service (SMS), and legacy instant messaging services such as AIM, ICQ, MSN Messenger, and Yahoo! Instant Messenger. Communications between gateways and servers, and between gateways and the foreign messaging system, are not defined in this document.
涓涓綉鍏蟲槸鏈嶅姟鍣ㄤ笂鐨勪竴涓叿鏈夌壒孌婄洰鐨勭殑鏈嶅姟銆傚畠涓昏鐨勫姛鑳芥槸涓庡閮ㄦ秷鎭郴緇熼氫俊鏃訛紝灝唜mpp鏁版嵁緲昏瘧鎴愯緋葷粺鐨勫崗璁暟鎹紝鍚屾槸灝嗚緋葷粺榪斿洖鐨勬暟鎹炕璇戞垚xmpp鏁版嵁銆備緥濡俥mail, irc, SIMPLE,SMS, 鍜屽叾瀹冪殑鍗蟲椂娑堟伅濡?AIM,ICQ, MSN Messenger, Yahoo!.緗戝叧涓庢湇鍔″櫒涔嬮棿鐨勯氫俊 鍜?緗戝叧涓庡閮ㄦ秷鎭郴緇熶箣闂?鐨勯氫俊鐨勫畾涔変笉鍦ㄨ繖綃囨枃妗d腑銆?/p>
1.4 聽2.5 聽Network/緗戠粶
Because each server is identified by a network address and because server-to-server communications are a straightforward extension of the client-to-server protocol, in practice, the system consists of a network of servers that inter-communicate. Thus, for example, <
juliet@example.com
> is able to exchange messages, presence, and other information with <
romeo@example.net
>. This pattern is familiar from messaging protocols (such as [SMTP]) that make use of network addressing standards. Communications between any two servers are OPTIONAL. If enabled, such communications SHOULD occur over XML streams that are bound to [TCP] connections. The RECOMMENDED port for connections between servers is 5269, as registered with the IANA (see Port Numbers (Section 15.9)).
鍥犱負姣忎竴涓湇鍔″櫒閮藉彲浠ラ氳繃涓涓綉緇滃湴鍧鏉ユ爣璇嗭紝鍚屾椂鍥犱負鏈嶅姟鍣ㄤ箣闂寸殑閫氫俊鏄鎴風涓庢湇鍔″櫒涔嬮棿鐨勯氫俊鍗忚鐨勪竴涓洿鎺ョ殑鎵╁睍錛屽湪瀹炶返涓紝緋葷粺鐢變氦浜掗氫俊鐨勬湇鍔″櫒緗戠粶緇勬垚銆傚洜姝わ紝渚嬪<
juliet@example.com
>鑳藉涓?lt;
romeo@example.net
> 浜ゆ崲娑堟伅銆佺幇鍦哄嫎瀵熷拰鍏跺畠淇℃伅銆傝繖縐嶆ā寮忓湪浣跨敤緗戠粶鍦板潃鏍囧噯鐨勬秷鎭氫俊鍗忚 (濡係MTP)涓槸甯歌鐨勶紝浠諱綍涓や釜閫氫俊鏄彲閫夌殑銆傚寮鍚紝閭d箞閫氫俊鍦ㄥ熀浜巟ml嫻佷笂鍙戠敓錛屽畠涓瀹氳寤虹珛TCP榪炴帴銆傛帹鑽愮殑榪炴帴绔彛涓?font color="#ff0000">5269, 瀹冨凡鍚慖ANA娉ㄥ唽銆?/font>
1.4 聽3. Addressing Scheme/鍦板潃閰嶇疆
1.4聽3.1 Overview/緇艱堪
An entity is anything that can be considered a network endpoint (i.e., an ID on the network) and that can communicate using XMPP. All such entities are uniquely addressable in a form that is consistent with RFC 2396 [URI]. For historical reasons, the address of an XMPP entity is called a Jabber Identifier or JID. A valid JID contains a set of ordered elements formed of a domain identifier, node identifier, and resource identifier.
The syntax for a JID is defined below using the Augmented Backus-Naur Form as defined in [ABNF]. (The IPv4address and IPv6address rules are defined in Appendix B of [IPv6]; the allowable character sequences that conform to the node rule are defined by the Nodeprep profile of [STRINGPREP] as documented in Appendix A of this memo; the allowable character sequences that conform to the resource rule are defined by the Resourceprep profile of [STRINGPREP] as documented in Appendix B of this memo; and the sub-domain rule makes reference to the concept of an internationalized domain label as described in [IDNA].)
jid = [ node "@" ] domain [ "/" resource ] domain = fqdn / address-literal fqdn = (sub-domain 1*("." sub-domain)) sub-domain = (internationalized domain label) address-literal = IPv4address / IPv6address
All JIDs are based on the foregoing structure. The most common use of this structure is to identify an instant messaging user, the server to which the user connects, and the user's connected resource (e.g., a specific client) in the form of <user@host/resource>. However, node types other than clients are possible; for example, a specific chat room offered by a multi-user chat service could be addressed as <room@service> (where "room" is the name of the chat room and "service" is the hostname of the multi-user chat service) and a specific occupant of such a room could be addressed as <room@service/nick> (where "nick" is the occupant's room nickname). Many other JID types are possible (e.g., <domain/resource> could be a server-side script or service).
Each allowable portion of a JID (node identifier, domain identifier, and resource identifier) MUST NOT be more than 1023 bytes in length, resulting in a maximum total size (including the '@' and '/' separators) of 3071 bytes.
涓涓疄浣撳彲浠ユ槸浠諱綍緗戠粶绔偣(濡傜綉緇滀腑鐨勪竴涓狪D)騫惰兘澶熺敤XMPP閫氫俊鐨勪簨 鐗┿?鎵鏈夎繖涓綾葷殑瀹炰綋鍙互鍞竴緙栧潃鐨勶紝騫剁鍚圼RFC 2396 [URI]]椋庢牸銆?鍥犱負鍘嗗彶鍘熷洜錛?strong>涓涓猉MPP瀹炰綋鐨勫湴鍧琚彨鍋欽abber鏍囪瘑絎︽垨JID銆備竴涓湁鏁堢殑JID鍖呮嫭涓変釜閮ㄥ垎錛?strong>鍩熸爣璇嗙錛?strong>鑺傜偣鏍囪瘑絎?/strong>鍜?strong>璧勬簮鏍囪瘑絎?/strong>
JID璇硶浣跨敤[ABNF]琛ㄨ揪寮忓畾涔夈?IPv4鍦板潃鍜孖Pv6鍦板潃鐨勮鍒欑殑瀹氫箟鍦ㄩ檮褰旴 [IPv6] 涓?/p>
jid = [ node "@" ] domain [ "/" resource ]
domain = fqdn / address-literal
fqdn = (sub-domain 1*("." sub-domain))
sub-domain = (internationalized domain label)
address-literal = IPv4address / IPv6address
鎵鏈夌殑JID閮芥槸鍩轟簬涓婅堪緇撴瀯涓殑銆傝繖涓粨鏋勫ぇ澶氭槸鐢ㄦ潵鏍囪瘑涓涓嵆鏃舵秷鎭氫俊鐨勭敤鎴鳳紝鍦ㄦ湇鍔″櫒涓婃湁鍝嚑涓繛鎺ワ紝鍙婄敤鎴風殑榪炴帴璧勬簮浠?lt;user@host/resource> 鐨勫艦寮? 鍙槸,鑺傜偣鐨勭被鍨嬪彲鑳戒笉鏄鎴風;渚嬪涓涓亰澶╁鎻愪緵澶氱敤鎴瘋亰澶╂湇鍔★紝瀹冪殑鍦板潃鍙互鍙互鏄?lt;room@service>( 鈥渞oom鈥濇槸 鑱婂ぉ瀹ょ殑鍚嶅瓧錛?service"鏄彁渚涘鐢ㄦ埛鑱婂ぉ鏈嶅姟鐨勪富鏈哄悕) 銆傛垨鑰呬竴涓亰澶╁涓殑 鏌愪釜鐢ㄦ埛琚紪鍧涓?lt;room@service/nick> ( "mick"鏄鐢ㄦ埛鍦ㄨ亰澶╁涓殑鏄電О). 鍏鋒湁澶氫釜鍏跺畠JID綾誨瀷鏄彲鑳界殑(濡?lt;domain/resource>鍙互鏄竴涓湇鍔″櫒绔殑 script鎴栨湇鍔?銆?/p>
涓涓狫ID鐨勬瘡涓閮ㄥ垎(鍩熸爣璇嗙錛岃妭鐐規爣璇嗙鍜岃祫婧愭爣璇嗙)鐨勯暱搴﹂兘涓嶈兘瓚呰繃1023 涓瓧鑺傦紝浠庤屾誨瓧鑺傛暟(鍖呮嫭"@"鍜?/")涓嶈兘瓚呰繃3071涓瓧鑺傘?/p>
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽 寰呯畫......

]]>