XMPP XML Basic semantics

Basic semantics

9.2.1 Message semantics

The <message/> section can be seen as a "push" mechanism, where one entity pushes information to other entities, similar to what happens in an EMAIL system. All message sections should have the ' to ' attribute, specifying the intended recipient of the message; Depending on the received section, the server should route or transmit it to the intended recipient (the reference server processes the rules for the common Routing and Delivery rules XML section for the relevant XML section (Section 10)).

9.2.2 presence Semantics <presence/> elements can be viewed as basic broadcasts or "publish-subscribe" mechanisms, and multiple entities receive their

The information of the entity that has subscribed (in this case, the network can take advantage of information). In general, the publishing entity should send a presence section without the ' to ' attribute, in which case the server connected to the entity should broadcast or reuse the section to all subscribing entities. However, a publishing entity may also send a presence section with a ' to ' attribute, in which case the server should route or transmit the node to the intended recipient. Refer to the server rules for processing XML sections (Section 10) for routing rules for generic routes and related XML sections, and for the presence of instant messaging and presence applications-specific rules [Xmpp-im].

9.2.3 IQ semantics
Information/request, or IQ, is a request-response mechanism similar to [HTTP] in some respects. IQ

Semantics makes it possible for an entity to request or receive a response from another entity to another entity. The data content of the request and response is defined by the namespace declaration of the direct child element of IQ, and the interaction is tracked by the requesting entity by using the ' id ' attribute. Thus, IQ interactions follow a common pattern of structured data exchange, such as get/result or set/result (although if appropriate, a response to a request may be returned with an error):

Requestingentity----------

| <iq type= ' Get ' id= ' 1 ' > |
| ------------------------> | | | | <iq type= ' result ' id= ' 1 ' > |
| <------------------------| | | | <iq type= ' Set ' id= ' 2 ' > |
| ------------------------> | | | | <iq type= ' error ' id= ' 2 ' > |
| <------------------------| | |

To enforce these semantics, the following rules apply: 1) for IQ section, the ' id ' attribute is REQUIRED.

2) for the IQ section. The ' type ' attribute is required. The value must be one of the following: The *get--section is a request for information or requirements. *set--section for required data, set new values, or replace existing values. The *result--section is a response that successfully gets or sets the request. *error--previously sent or set related procedure or transmitted error (Reference section error (Section 9.3)). 3) An entity that receives an IQ request of type "get" or "set" must respond with an IQ response of type ' result ' or ' error ' (the response must retain the ' id ' attribute of the request).

4) Receiving a section of type "result" or "error" is not allowed to respond by sending a further IQ response section of type "result" or "error"; however, as shown above, the requesting entity may send another request (e.g., an IQ of type "set", in order to Information required for discovery by obtaining/finding).
5) An IQ section of type "get" or "set" must contain one and only one child element, specifying special request or response semantics.

6) An IQ section of type "result" must contain 0 or one child element.
7) An IQ section of type "error" should be included in the relevant "get" or "set" sub-elements, and must contain a <error/> child element;

XMPP XML Basic semantics