需要去搞清楚，XMPP中，聊天的消息类型有哪些，以及相关的基本概念。
然后找到官网的解释，足够清楚了：
Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
“
Manage items in a contact list (in XMPP this is called a "roster")
2.1.1. Types of Message
The ‘type’ attribute of a message stanza is RECOMMENDED; if included, it specifies the conversational context of the message, thus providing a hint regarding presentation (e.g., in a GUI). If included, the ‘type’ attribute MUST have one of the following values:
- chat — The message is sent in the context of a one-to-one chat conversation. A compliant client SHOULD present the message in an interface enabling one-to-one chat between the two parties, including an appropriate conversation history.
- error — An error has occurred related to a previous message sent by the sender (for details regarding stanza error syntax, refer to [XMPP‑CORE]). A compliant client SHOULD present an appropriate interface informing the sender of the nature of the error.
- groupchat — The message is sent in the context of a multi-user chat environment (similar to that of [IRC]). A compliant client SHOULD present the message in an interface enabling many-to-many chat between the parties, including a roster of parties in the chatroom and an appropriate conversation history. Full definition of XMPP-based groupchat protocols is out of scope for this memo (for details see [JEP‑0045]).
- headline — The message is probably generated by an automated service that delivers or broadcasts content (news, sports, market information, RSS feeds, etc.). No reply to the message is expected, and a compliant client SHOULD present the message in an interface that appropriately differentiates the message from standalone messages, chat sessions, or groupchat sessions (e.g., by not providing the recipient with the ability to reply).
- normal — The message is a single message that is sent outside the context of a one-to-one conversation or groupchat, and to which it is expected that the recipient will reply. A compliant client SHOULD present the message in an interface enabling the recipient to reply, but without a conversation history.
5.5. Presence Examples
The examples in this section illustrate the presence-related protocols described above. The user is [email protected], he has an available resource whose resource identifier is "orchard", and he has the following individuals in his roster:
- [email protected] (subscription="both" and she has two available resources, one whose resource is "chamber" and another whose resource is "balcony")
- [email protected] (subscription="to")
- [email protected] (subscription="from")
Example 1: User sends initial presence:
<presence/>
Example 2: User’s server sends presence probes to contacts with subscription="to" and subscription="both" on behalf of the user’s available resource:
<presence
type='probe'
from='[email protected]/orchard'
to='[email protected]'/>
<presence
type='probe'
from='[email protected]/orchard'
to='[email protected]'/>
3. Session Establishment
Most instant messaging and presence applications based on XMPP are implemented via a client-server architecture that requires a client to establish a session on a server in order to engage in the expected instant messaging and presence activities. However, there are several pre-conditions that MUST be met before a client can establish an instant messaging and presence session. These are:
- Stream Authentication — a client MUST complete stream authentication as documented in [XMPP‑CORE] before attempting to establish a session or send any XML stanzas.
- Resource Binding — after completing stream authentication, a client MUST bind a resource to the stream so that the client’s address is of the form <user@domain/resource>, after which the entity is now said to be a "connected resource" in the terminology of [XMPP‑CORE].
”
转载请注明：在路上 » ［XMPP整理］聊天消息类型＋基本概念