RFC 3921:Extensible Messaging and Presence Protoco...
RFC-Ref

XML


Click on the red underlined text to get to the source

... Extensible Messaging and Presence Protocol (XMPP) is a protocol for streaming XML [XML] elements in order to exchange messages and ...
... (XMPP): Core [XMPP-CORE]. These features -- mainly XML streams, use of TLS and SASL ...
... real-time applications, which may be layered on top of the core by sending application-specific data qualified by particular XML namespaces [XML-NAMES]. This memo describes extensions to and applications of the core features of XMPP ...


... Syntax of XML Stanzas ...
... The basic semantics and common attributes of XML stanzas qualified by the 'jabber:client ...
... before addressing particular "use cases" for such applications, we here further describe the syntax of XML stanzas, thereby supplementing the discussion in [XMPP-CORE ...
... subject/> element contains human-readable XML character data that specifies the topic of the message. The <subject/> element ...
... The <body/> element contains human-readable XML character data that specifies the textual contents of the message; this child element is ...
... The <thread/> element contains non-human-readable XML character data specifying an identifier that is used for tracking a conversation ...
... The OPTIONAL <show/> element contains non-human-readable XML character data that specifies the particular availability status of an entity or specific resource. A presence stanza ...
... element. The <show/> element MUST NOT possess any attributes. If provided, the XML character data value MUST be one of the following (additional availability types could be defined through a properly-namespaced child element ...
... The OPTIONAL <status/> element contains XML character data specifying a natural-language description of availability status. It is ...
... priority/> element contains non-human-readable XML character data that specifies the priority level of the resource. The value MUST be an integer ...
... instant messaging and presence applications, refer to Server Rules for Handling XML Stanzas (Section 11). ...
... While the three XML stanza kinds defined in the "jabber:client" or ...
... elements) provide a basic level of functionality for messaging and presence, XMPP uses XML namespaces to extend the stanzas for the purpose of providing additional functionality. Thus a message or ...
... stanza that contains a child element it does not understand, it SHOULD ignore that specific XML data, i.e., it SHOULD not process it or present it to a user or associated application (if any). In particular: ...
... entity receives a message or presence stanza that contains XML data qualified by a namespace it does not understand, the portion of the stanza ...
... contains a child element it does not understand, it SHOULD ignore the associated XML data by passing it on untouched to the recipient. ...


... XMPP-CORE] before attempting to establish a session or send any XML stanzas. 2. Resource Binding -- after completing stream ...
... case #1. In case #1, the server SHOULD send a <conflict/> stream error to the active resource, terminate the XML stream and underlying TCP connection for the active ...
... stanza error to the newly-requested session but maintain the XML stream for that connection so that the newly-requested session ...


... stanza that is addressed to another entity. As defined under Server Rules for Handling XML Stanzas (Section 11), the sender's server is responsible for delivering the ...
... stanza MAY (and often will) contain a child <body/> element whose XML character data specifies the primary meaning of the message (see Body (Section 2.1.2.2)). ...


... presence stanza lacks a 'type' attribute (i.e., expresses availability), the user's server MUST broadcast the full XML of that presence stanza to all contacts (1) that are in the user's roster ...
... "unavailable", the user's server MUST broadcast the full XML of that presence stanza to all entities that fit the above description, as ...
... either (1) reply to the presence probe by sending to the user the full XML of the last presence stanza of type "unavailable" ...
... server MUST reply to the presence probe by sending to the user the full XML of the last presence stanza with no 'to' attribute received by the server ...
... broadcast, the user's server MUST route or deliver the full XML of that presence stanza (subject to privacy lists ...
... broadcast, the user's server MUST route or deliver the full XML of that presence stanza to the entity but MUST NOT ...
... broadcast that subscription request to all available resources in accordance with Server Rules for Handling XML Stanzas (Section 11). (Note: If an active resource ...


... elements, for use in collecting roster items into various categories. The XML character data of the <group/> element is opaque ...


... address as the bare JID (<user@example.com>) of the user; and (3) MUST send to the contact the full XML of the last presence stanza with no 'to' attribute received by the server ...
... subscribing to a contact's presence information, a user MAY unsubscribe. While the XML that the user sends to make this happen is the same in all instances, the subsequent subscription state ...
... At any time after approving a subscription request from a user, a contact MAY cancel that subscription. While the XML that the contact sends to make this happen is the same in all instances, the subsequent subscription state ...


... stanzas SHOULD BE accepted or appropriately processed by the server on behalf of the user in accordance with the Server Rules for Handling XML Stanzas (Section 11). 4. Privacy lists ...
... routing and delivery rules specified in Server Rules for Handling XML Stanzas (Section 11), and (2) the handling of subscription-related presence stanzas (and ...
... The final representation is the simplest and SHOULD be used; here is the XML that would be sent in this case: <iq type='set' id='heuristic1'> ...


... Server Rules for Handling XML Stanzas ...


... o Generation and handling of the IM-specific semantics of XML stanzas as defined by the XML schemas, including the 'type' attribute of message and presence stanzas ...
... IM-specific semantics of XML stanzas as defined by the XML schemas, including the 'type' attribute of message and presence stanzas as well as their child ...


... hostnames, the server MUST first apply any privacy lists (Section 10) that are in force (see Server Rules for Handling XML Stanzas (Section 11)). ...


... XML Namespace Name for Session Data ...
... namespace name adheres to the format defined in The IETF XML Registry [XML-REG ...
... Specification: RFC 3921prop Description: This is the XML namespace name for session-related data in the Extensible Messaging and Presence Protocol ...


... Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>. ...
... Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C REC-xml-names, January 1999, <http://www.w3.org/TR/REC-xml-names>. ...
... Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688 ...


... telephone number or email address). An XML representation of the vCard specification defined in RFC 2426prop ...


... Appendix B. XML Schemas ...
... The following XML schemas are descriptive, not normative. For schemas defining the core features of XMPP, refer to [XMPP-CORE ...



Google
Web
RFC-Ref