XMPP核心协议标准详解

需积分: 9 106 浏览量更新于2024-07-15 收藏 3.97MB PDF 举报

"关于Extensible Messaging and Presence Protocol (XMPP)的核心协议规范文档" Extensible Messaging and Presence Protocol (XMPP) 是一种基于XML的应用层通信协议，主要用于即时消息传递和在线状态（即网络可用性，也称为“存在”）的实时交换。这个协议允许任意两个或多个网络实体之间进行结构化但可扩展的数据交互。XMPP的设计目标是提供高效、灵活且可扩展的消息传递解决方案。 RFC 6120是XMPP的核心协议标准，由P. Saint-Andre在2011年发布，取代了之前的RFC 3920。该文档详细定义了XMPP协议的关键组件和方法，包括： 1. **XML流的建立与断开**：XMPP基于XML流进行通信，这个过程包括建立连接、发送和接收XML片段以及关闭连接。 2. **通道加密**：为了保证通信的安全性，XMPP支持使用TLS（Transport Layer Security）对XML流进行加密，以防止数据在传输过程中被窃取或篡改。 3. **认证机制**：XMPP提供了多种身份验证方式，如SIMPLE、DIGEST-MD5、PLAIN等，确保只有授权的实体才能参与通信。 4. **错误处理**：定义了错误报告和处理的规则，帮助系统识别并解决通信中出现的问题。 5. **消息传递**：XMPP提供了基础的消息发送和接收机制，支持一对一和多对多的通信模式，同时也允许用户创建和管理聊天室。 6. **存在（Presence）**：用户的状态信息，如在线、离线、忙碌等，可以通过XMPP协议实时更新和传播，使得其他用户可以获取到这些信息。 7. **请求-响应交互**：XMPP支持基于请求-响应模式的交互，例如查询、确认、订阅等操作，可以用于实现各种高级功能，如文件传输、音视频通话等。 8. **标准化进程**：作为IETF的互联网标准，RFC 6120代表了互联网社区的共识，并经过了广泛的公开审查和批准。 XMPP的开放性和可扩展性使其成为许多即时通讯应用的首选协议，例如Jabber服务器和客户端软件。此外，XMPP还被广泛应用于企业级的协作系统、物联网设备通信以及游戏中的实时通信场景。 XMPP核心协议提供了丰富的功能和灵活性，是构建可靠、安全、可扩展的即时通讯系统的基石。通过不断演进和标准化，XMPP保持了其在现代通信技术中的重要地位。

2020/11/7 Extensible Messaging and Presence Protocol (XMPP): Core

https://xmpp.org/rfcs/rfc6120.html 16/146

TOC

<stream:stream

from='juliet@im.example.com'

to='im.example.com'

version='1.0'

xml:lang='en'

xmlns='jabber:client'

xmlns:stream='http://etherx.jabber.org/streams'>

The receiving entity then replies by sending a stream header of its own (the "response

stream header") to the initiating entity.

R: <?xml version='1.0'?>

<stream:stream

from='im.example.com'

id='++TR84Sm6A3hnt3Q065SnAbbk3Y='

to='juliet@im.example.com'

version='1.0'

xml:lang='en'

xmlns='jabber:client'

xmlns:stream='http://etherx.jabber.org/streams'>

The entities can then proceed with the remainder of the stream negotiation process.

4.3. Stream Negotiation

4.3.1. Basic Concepts

Because the receiving entity for a stream acts as a gatekeeper to the domains it services, it

imposes certain conditions for connecting as a client or as a peer server. At a minimum, the

initiating entity needs to authenticate with the receiving entity before it is allowed to send

stanzas to the receiving entity (for client-to-server streams this means using SASL as

described under ). However, the receiving entity can consider conditions other than

authentication to be mandatory-to-negotiate, such as encryption using TLS as described

under . The receiving entity informs the initiating entity about such conditions by

communicating "stream features": the set of particular protocol interactions that the initiating

entity needs to complete before the receiving entity will accept XML stanzas from the

initiating entity, as well as any protocol interactions that are voluntary-to-negotiate but that

might improve the handling of an XML stream (e.g., establishment of application-layer

compression as described in ).

The existence of conditions for connecting implies that streams need to be negotiated. The

order of layers (TCP, then TLS, then SASL, then XMPP as described under )

implies that stream negotiation is a multi-stage process. Further structure is imposed by two

factors: (1) a given stream feature might be offered only to certain entities or only after

certain other features have been negotiated (e.g., resource binding is offered only after SASL

authentication), and (2) stream features can be either mandatory-to-negotiate or voluntary-

to-negotiate. Finally, for security reasons the parties to a stream need to discard knowledge

that they gained during the negotiation process after successfully completing the protocol

interactions defined for certain features (e.g., TLS in all cases and SASL in the case when a

security layer might be established, as defined in the specification for the relevant SASL

mechanism). This is done by flushing the old stream context and exchanging new stream

headers over the existing TCP connection.

4.3.2. Stream Features Format

Section 6

Section 5

[XEP‑0138]

Section 13.3

2020/11/7 Extensible Messaging and Presence Protocol (XMPP): Core

https://xmpp.org/rfcs/rfc6120.html 17/146

If the initiating entity includes in the initial stream header the 'version' attribute set to a

value of at least "1.0" (see ), after sending the response stream header the

receiving entity MUST send a <features/> child element (typically prefixed by the stream

namespace prefix as described under ) to the initiating entity in order to

announce any conditions for continuation of the stream negotiation process. Each condition

takes the form of a child element of the <features/> element, qualified by a namespace that

is different from the stream namespace and the content namespace. The <features/>

element can contain one child, contain multiple children, or be empty.

Implementation Note: The order of child elements contained in any given

<features/> element is not significant.

If a particular stream feature is or can be mandatory-to-negotiate, the definition of that

feature needs to do one of the following:

1. Declare that the feature is always mandatory-to-negotiate (e.g., this is true of

resource binding for XMPP clients); or

2. Specify a way for the receiving entity to flag the feature as mandatory-to-

negotiate for this interaction (e.g., for STARTTLS, this is done by including an

empty <required/> element in the advertisement for that stream feature, but

that is not a generic format for all stream features); it is RECOMMENDED that

stream feature definitions for new mandatory-to-negotiate features do so by

including an empty <required/> element as is done for STARTTLS.

Informational Note: Because there is no generic format for indicating that a

feature is mandatory-to-negotiate, it is possible that a feature that is not

understood by the initiating entity might be considered mandatory-to-negotiate

by the receiving entity, resulting in failure of the stream negotiation process.

Although such an outcome would be undesirable, the working group deemed it

rare enough that a generic format was not needed.

For security reasons, certain stream features necessitate the initiating entity to send a new

initial stream header upon successful negotiation of the feature (e.g., TLS in all cases and

SASL in the case when a security layer might be established). If this is true of a given stream

feature, the definition of that feature needs to specify that a stream restart is expected after

negotiation of the feature.

A <features/> element that contains at least one mandatory-to-negotiate feature indicates

that the stream negotiation is not complete and that the initiating entity MUST negotiate

further features.

R: <stream:features>

</starttls>

</stream:features>

A <features/> element MAY contain more than one mandatory-to-negotiate feature. This

means that the initiating entity can choose among the mandatory-to-negotiate features at

this stage of the stream negotiation process. As an example, perhaps a future technology will

perform roughly the same function as TLS, so the receiving entity might advertise support for

both TLS and the future technology at the same stage of the stream negotiation process.

However, this applies only at a given stage of the stream negotiation process and does not

apply to features that are mandatory-to-negotiate at different stages (e.g., the receiving

entity would not advertise both STARTTLS and SASL as mandatory-to-negotiate, or both

SASL and resource binding as mandatory-to-negotiate, because TLS would need to be

negotiated before SASL and because SASL would need to be negotiated before resource

binding).

A <features/> element that contains both mandatory-to-negotiate and voluntary-to-

negotiate features indicates that the negotiation is not complete but that the initiating entity

MAY complete the voluntary-to-negotiate feature(s) before it attempts to negotiate the

mandatory-to-negotiate feature(s).

Section 4.7.5

Section 4.8.5

2020/11/7 Extensible Messaging and Presence Protocol (XMPP): Core

https://xmpp.org/rfcs/rfc6120.html 18/146

TOC

R: <stream:features>

</compression>

</stream:features>

A <features/> element that contains only voluntary-to-negotiate features indicates that the

stream negotiation is complete and that the initiating entity is cleared to send XML stanzas,

but that the initiating entity MAY negotiate further features if desired.

R: <stream:features>

</compression>

</stream:features>

An empty <features/> element indicates that the stream negotiation is complete and that

the initiating entity is cleared to send XML stanzas.

R: <stream:features/>

4.3.3. Restarts

On successful negotiation of a feature that necessitates a stream restart, both parties MUST

consider the previous stream to be replaced but MUST NOT send a closing </stream> tag

and MUST NOT terminate the underlying TCP connection; instead, the parties MUST reuse

the existing connection, which might be in a new state (e.g., encrypted as a result of TLS

negotiation). The initiating entity then MUST send a new initial stream header, which

SHOULD be preceded by an XML declaration as described under . When the

receiving entity receives the new initial stream header, it MUST generate a new stream ID

(instead of reusing the old stream ID) before sending a new response stream header (which

SHOULD be preceded by an XML declaration as described under ).

4.3.4. Resending Features

The receiving entity MUST send an updated list of stream features to the initiating entity

after a stream restart. The list of updated features MAY be empty if there are no further

features to be advertised or MAY include any combination of features.

4.3.5. Completion of Stream Negotiation

The receiving entity indicates completion of the stream negotiation process by sending to the

initiating entity either an empty <features/> element or a <features/> element that contains

only voluntary-to-negotiate features. After doing so, the receiving entity MAY send an empty

<features/> element (e.g., after negotiation of such voluntary-to-negotiate features) but

MUST NOT send additional stream features to the initiating entity (if the receiving entity has

new features to offer, preferably limited to mandatory-to-negotiate or security-critical

features, it can simply close the stream with a <reset/> stream error ( )

and then advertise the new features when the initiating entity reconnects, preferably closing

existing streams in a staggered way so that not all of the initiating entities reconnect at

once). Once stream negotiation is complete, the initiating entity is cleared to send XML

stanzas over the stream for as long as the stream is maintained by both parties.

Section 11.5

Section 4.9.3.16

2020/11/7 Extensible Messaging and Presence Protocol (XMPP): Core

https://xmpp.org/rfcs/rfc6120.html 19/146

TOC

Informational Note: Resource binding as specified under is an

historical exception to the foregoing rule, since it is mandatory-to-negotiate for

clients but uses XML stanzas for negotiation purposes.

The initiating entity MUST NOT attempt to send to entities other than itself

(i.e., the client's connected resource or any other authenticated resource of the client's

account) or the server to which it is connected until stream negotiation has been completed.

Even if the initiating entity does attempt to do so, the receiving entity MUST NOT accept such

stanzas and MUST close the stream with a <not-authorized/> stream error

( ). This rule applies to XML stanzas only (i.e., <message/>, <presence/>,

and <iq/> elements qualified by the content namespace) and not to XML elements used for

stream negotiation (e.g., elements used to complete or

4.3.6. Determination of Addresses

After the parties to an XML stream have completed the appropriate aspects of stream

negotiation, the receiving entity for a stream MUST determine the initiating entity's JID.

For client-to-server communication, both and MUST

be completed before the server can determine the client's address. The client's bare JID

(<localpart@domainpart>) MUST be the authorization identity (as defined by ), either

(1) as directly communicated by the client during or (2) as derived by the

server from the authentication identity if no authorization identity was specified during SASL

negotiation. The resourcepart of the full JID (<localpart@domainpart/resourcepart>) MUST

be the resource negotiated by the client and server during . A client MUST

NOT attempt to guess at its JID but instead MUST consider its JID to be whatever the server

returns to it during resource binding. The server MUST ensure that the resulting JID

(including localpart, domainpart, resourcepart, and separator characters) conforms to the

canonical format for XMPP addresses defined in ; to meet this restriction, the

server MAY replace the JID sent by the client with the canonicalized JID as determined by the

server and communicate that JID to the client during resource binding.

For server-to-server communication, the initiating server's bare JID (<domainpart>) MUST

be the authorization identity (as defined by ), either (1) as directly communicated by

the initiating server during or (2) as derived by the receiving server from

the authentication identity if no authorization identity was specified during SASL negotiation.

In the absence of SASL negotiation, the receiving server MAY consider the authorization

identity to be an identity negotiated within the relevant verification protocol (e.g., the 'from'

attribute of the <result/> element in Server Dialback ).

Security Warning: Because it is possible for a third party to tamper with

information that is sent over the stream before a security layer such as TLS is

successfully negotiated, it is advisable for the receiving server to treat any such

unprotected information with caution; this applies especially to the 'from' and 'to'

addresses on the first initial stream header sent by the initiating entity.

4.3.7. Flow Chart

We summarize the foregoing rules in the following non-normative flow chart for the stream

negotiation process, presented from the perspective of the initiating entity.

+---------------------+

| open TCP connection |

+---------------------+

+---------------+

| send initial |<-------------------------+

Section 7

XML stanzas

Section 4.9.3.12

TLS negotiation SASL

negotiation

SASL negotiation resource binding

[SASL]

SASL negotiation

resource binding

[XMPP‑ADDR]

[SASL]

SASL negotiation

[XEP‑0220]

2020/11/7 Extensible Messaging and Presence Protocol (XMPP): Core

https://xmpp.org/rfcs/rfc6120.html 20/146

TOC

| stream header | ^

+---------------+ |

| |

v |

+------------------+ |

| receive response | |

| stream header | |

+------------------+ |

| |

v |

+----------------+ |

| receive stream | |

+------------------>| features | |

^ {OPTIONAL} +----------------+ |

| | |

| v |

| +<-----------------+ |

| | |

| {empty?} ----> {all voluntary?} ----> {some mandatory?} |

| | no | no | |

| | yes | yes | yes |

| | v v |

| | +---------------+ +----------------+ |

| | +---------------+ +----------------+ |

| v | | |

| +---------+ v | |

| | DONE |<----- {negotiate?} | |

| +---------+ no | | |

| yes | | |

| v v |

| +--------->+<---------+ |

| | |

| v |

+<-------------------------- {restart mandatory?} ------------>+

no yes

Figure3: Stream Negotiation Flow Chart

4.4. Closing a Stream

An XML stream from one entity to another can be closed at any time, either because a

specific stream error ( ) has occurred or in the absence of an error (e.g., when a

client simply ends its session).

A stream is closed by sending a closing </stream> tag.

E: </stream:stream>

If the parties are using either two streams over a single TCP connection or two streams over

two TCP connections, the entity that sends the closing stream tag MUST behave as follows:

1. Wait for the other party to also close its outbound stream before terminating the

underlying TCP connection(s); this gives the other party an opportunity to finish

transmitting any outbound data to the closing entity before the termination of

the TCP connection(s).

2. Refrain from sending any further data over its outbound stream to the other

entity, but continue to process data received from the other entity (and, if

necessary, process such data).

3. Consider both streams to be void if the other party does not send its closing

stream tag within a reasonable amount of time (where the definition of

Section 4.9

剩余145页未读，继续阅读

__承_影__

粉丝: 124
资源: 25

XMPP核心协议标准详解

Core_v5.1.pdf

Core_v5.2.pdf

XMPP协议中文版.doc

springboot xmpp

XMPP具体是什么？XMPP与Jitsi Meet有什么关系？

聊天服务 protobuf xmpp

php 的免费即时通讯技术哪个最好用

twisted-words

linux系统实现网上聊天

请给我几个不常用的端口号

最新资源